Передача параметров в URL при использовании HTTP POST
Допустимо ли передавать параметры на веб-страницу через URL (после знака вопроса) при использовании метода POST? Я знаю, что это работает (в большинстве случаев, во всяком случае), потому что веб-приложение моей компании делает это часто, но я не знаю, действительно ли оно поддерживается в стандарте или могу ли я положиться на это поведение. Я рассматриваю возможность реализации обработчика запросов SOAP, который использует параметр после знака вопроса, чтобы указать, что это запрос SOAP, а не обычный запрос HTTP. Причина этого в том, что веб-приложение является расширением IIS, поэтому доступ ко всему осуществляется через один и тот же URL-адрес (например, example.com/myisapi.dll?command), поэтому для получения запроса SOAP, который нужно обработать, мне нужно указать, что " Команда "Параметр. Для SOAP будет одна общая команда, а не отдельная команда для каждого действия SOAP - они будут указаны в самом запросе SOAP.
По сути, я пытаюсь интегрировать библиотеку Apache Axis2 / C в свое веб-приложение, позволяя веб-приложению обрабатывать HTTP-запрос и затем передавать входящий SOAP XML в Axis2 для обработки, если это SOAP-запрос. Интуитивно понятно, что я не вижу никакой причины, по которой это не сработает, поскольку отправляемый вами URL-адрес - это просто произвольный URL-адрес, поскольку речь идет о всех различных компонентах... именно сервер придает особое значение части после знака вопроса.
Спасибо за любую помощь / понимание, которое вы можете предоставить.
5 ответов
Давайте начнем с простых вещей. Переменные запроса HTTP GET приходят из URI. URI является запрошенным ресурсом, и поэтому любой веб-сервер должен (и Apache делает) хранить весь URI в некоторой переменной, доступной для модулей или компонентов сервера приложений, работающих в веб-сервере.
HTTP POST, который отличается от http GET, - это отдельный логический вызов веб-сервера, но он по-прежнему определяет URI, который должен обрабатывать сообщение. Хороший веб-сервер (Apache, являющийся таковым) снова сделает URI доступным для любого модуля или сервера приложений, которые в нем работают, а затем дополнительно сделает доступными переменные, которые были отправлены в заголовках POST.
В тот момент, когда ваше приложение получает контроль от apache во время POST, вы должны иметь доступ к переменным GET и POST и иметь возможность выполнять любую управляющую логику, какую пожелаете, включая ответ с помощью протокола SOAP вместо HTML.
Если вы спрашиваете, возможно ли отправить параметры через GET и POST в одном HTTP-запросе, тогда ответ "ДА". Это стандартная функциональность, которая может быть надежно использована AFAIK.
Одним из таких примеров является отправка учетных данных аутентификации в двух частях, одна через GET, а другая через POST, так что любая попытка перехватить сеанс потребует перехвата переменных GET и POST.
Таким образом, в вашем случае вы можете использовать POST, чтобы содержать фактический запрос SOAP, но проверить, является ли он запросом SOAP на основе параметра, переданного в GET (или другими словами через URL).
Я считаю, что ни один стандарт на самом деле не определяет понятие "параметры HTTP" или "переменные запроса". RFC 1738 определяет, что URL может иметь "поисковую часть", которая является подстрокой после знака вопроса. HTML указывает в протоколе отправки формы, как браузер, обрабатывающий элемент FORM, должен представить его. В любом случае, то, как серверная часть обрабатывает и часть поиска, и тело HTTP, полностью зависит от сервера - отказ от обоих будет соответствовать этим двум спецификациям (но довольно бесполезен).
Чтобы определить, можете ли вы опубликовать часть поиска в конкретной службе, вам необходимо изучить спецификацию протокола этой службы. Если сервис практически определяется с помощью HTML-формы, вы не можете использовать микс - вы даже не можете использовать POST, если FORM указывает GET (и наоборот). Если вы публикуете в веб-сервисе, вам нужно взглянуть на WSDL веб-сервиса, который обычно требует POST; со всеми данными в сообщении SOAP. И т.п.
Определенные веб-фреймворки могут иметь понятие "переменные запроса" - будут ли они извлекать эти переменные как из поисковой части, так и из тела запроса, вы должны выяснить в документации по продукту.
Допустимого? конечно, это выполнимо, но я склоняюсь к спецификации, предполагающей, что двойные методы не обязательно должны происходить или поддерживаться. RFC2616 определяет HTTP/1.1, и я бы сказал, предлагает только один метод на запрос. если вы думаете о типичной HTTP-транзакции со стороны клиента, вы также можете увидеть ограничение:
$ telnet localhost 80
POST /page.html?id=5 HTTP/1.1
host: localhost
как видите, вы можете использовать только один метод (POST/GET и т. д.), однако из-за особенностей работы различных языков они могут выбрать строку запроса и назначить ее переменной GET. в конечном счете, это запрос POST, а не GET.
так в принципе, да, эта функциональность существует, она предназначена? я бы сказал нет.
Я развернул веб-приложение с 3 (оператор мобильной сети) в Великобритании. Первоначально он использовал параметры POST, но шлюз 3 удалил их (и X-заголовки также!). Так что будьте осторожны...