Passer des paramètres dans L'URL en utilisant HTTP POST
est-il permis de passer des paramètres à une page web à travers L'URL (après le point d'interrogation) en utilisant la méthode POST? Je sais que cela fonctionne (la plupart du temps, de toute façon) parce que webapp de mon entreprise le fait souvent, mais je ne sais pas si elle est réellement prise en charge dans la norme ou si je peux compter sur ce comportement. Je pense implémenter un gestionnaire de requêtes SOAP qui utilise un paramètre après le point d'interrogation pour indiquer qu'il s'agit d'une requête SOAP et non d'une requête HTTP normale. Le raison pour cela que la webapp est une extension IIS, de sorte que tout est accessible via la même URL (ex: example.com/myisapi.dll?command), donc pour que la requête SOAP soit traitée, je dois spécifier ce paramètre" command". Il y aurait une commande générique pour SOAP, pas une commande spécifique pour chaque action SOAP -- celles-ci seraient spécifiées dans la demande SOAP elle-même.
en gros, j'essaie d'intégrer la bibliothèque Apache Axis2/C dans mon webapp en laissant le webapp gérer la requête HTTP et ensuite transmettre le XML SOAP entrant à Axis2 pour gérer s'il s'agit d'une requête SOAP. Intuitivement, Je ne vois pas pourquoi cela ne fonctionnerait pas, puisque L'URL que vous envoyez n'est qu'une URL arbitraire, en ce qui concerne tous les composants... c'est le serveur qui donne un sens particulier pour les pièces après le point d'interrogation.
Merci pour toute aide/perspicacité que vous pouvez fournir.
5 réponses
Permet de commencer avec les choses simples. Les variables de requête HTTP GET proviennent de L'URI. L'URI est une ressource demandée, et donc tout serveur web devrait (et apache) avoir la totalité de l'URI stockée dans une variable disponible pour les modules ou les composants de l'applserveur fonctionnant dans le serveur web.
un post http qui est différent d'un GET http est un appel logique séparé au serveur web, mais il définit toujours une URI qui devrait traiter le post. Un bon serveur web (apache en étant un) mettra à nouveau L'URI à la disposition de n'importe quel module ou serveur d'applications qui s'y trouve, puis mettra également à disposition les variables qui ont été envoyées dans les en-têtes de poste.
au moment où votre application prend le contrôle d'apache pendant un POST, vous devez avoir accès aux variables GET et POST et être capable de faire la logique de contrôle que vous souhaitez, y compris répondre avec un protocole SOAP au lieu de HTML.
si vous demandez s'il est possible d'envoyer des paramètres via GET et POST dans une seule requête HTTP, alors la réponse est"oui". Il s'agit d'une fonctionnalité standard qui peut être utilisée de manière fiable AFAIK.
L'un de ces exemples est l'envoi de justificatifs d'authentification en deux parties, L'une sur GET et l'autre via POST, de sorte que toute tentative de détourner une session nécessiterait de détourner à la fois les variables GET et POST.
Donc dans votre cas, vous pouvez utilisez POST pour contenir la requête SOAP réelle mais testez pour savoir si c'est une requête SOAP basée sur le paramètre passé dans GET (ou en d'autres termes à travers L'URL).
je crois qu'aucune norme ne définit réellement le concept de" paramètres HTTP "ou de"variables de requête". RFC 1738 définit qu'une URL peut avoir une" partie de recherche", qui est la sous-chaîne après le point d'interrogation. HTML spécifie dans le protocole de soumission de formulaire comment un navigateur traitant un élément de formulaire doit le soumettre. Dans un cas comme dans l'autre, la façon dont le côté serveur traite à la fois la partie de recherche et le corps HTTP dépend entièrement du serveur-rejeter les deux serait conforme à ces deux spécifications (mais assez inutile).
afin de déterminer si vous pouvez poster une partie de recherche sur un service spécifique, vous devez étudier la spécification de protocole de ce service. Si le service est pratiquement défini au moyen d'un formulaire HTML, alors vous ne pouvez pas utiliser un mix - vous ne pouvez même pas utiliser POST si le formulaire spécifie GET (et vice versa). Si vous postez à un service web, vous devez regarder WSDL du service web - qui sera généralement mandaté POST; avec toutes les données dans un message SOAP. Etc.
cadres web spécifiques peuvent avoir la notion de "variables de demande" - s'ils vont tirer ces variables à la fois d'une partie de recherche et un corps de demande, vous devez savoir dans la documentation du produit.
j'ai déployé une application web avec 3 (un opérateur de réseau mobile) au Royaume-Uni. Il utilisait à l'origine des paramètres POST, mais la passerelle 3 les a dépouillés (et des en-têtes X aussi!). Alors méfiez-vous...
admissible? bien sûr, c'est faisable, mais je penche pour le spec suggérant que les méthodes duales ne sont pas nécessairement supposées se produire, ou être soutenues. RFC2616 définit HTTP / 1.1, et je dirais suggère seulement une méthode par requête. si vous pensez à votre transaction HTTP typique du côté client, vous pouvez voir la limitation aussi bien:
$ telnet localhost 80
POST /page.html?id=5 HTTP/1.1
host: localhost
comme vous pouvez le voir, vous ne pouvez utiliser qu'une seule méthode (POST/GET, etc...), mais en raison de la nature de la façon dont les différents langages fonctionnent, ils peuvent prendre la chaîne de requête, et l'assigner à la variable GET. en fin de compte cependant, il s'agit d'une requête POST, et non D'un GET.
donc, en gros, oui cette fonctionnalité existe, est-il prévu? je dirais non .