Должен ли я принять метод POST на всех ресурсах?

Question

В этом вопросе я говорю о методах HTTP-запроса. Для подробного объяснения методов HTTP-запроса см. RFC 2616 , особенно Раздел 5.1.1 и Раздел 9.

Обычным способом запроса ресурса (URI, URL, веб-страница) является метод GET (или HEAD, если вам нужны только заголовки).

Обычно метод POST используется только в том случае, если данные, отправляемые клиентом на сервер, не должны отображаться в URI. Имена учетных записей и пароли или другие конфиденциальные данные часто передаются таким образом. (Конечно, вам все еще нужен SSL, так как он сам по себе не обеспечивает шифрование.)

Большинству моих ресурсов (URI) не нужен метод POST. Например, страницы, содержащие мои статьи, должны быть получены с помощью GET. Примеры правильных строк запроса:

GET /myarticles HTTP/1.1
GET /copyrightnotice HTTP/1.1
GET /blog/2011/03/14/something.html HTTP/1.1

Единственными, кому требуется POST, являются страницы входа (где учетная запись и пароль, введенные в форму, отправляются в теле POST) и некоторые другие специальные страницы. Примеры:

POST /performlogin HTTP/1.1
POST /formtarget HTTP/1.1
POST /savevote HTTP/1.1

У меня вопрос, должен ли я запретить метод POST на страницах, которые ему не нужны (например, / myarticles, / copyrightnotice и т. Д.)?

Другими словами, если я получу эту строку запроса:

POST /blog/2011/03/14/something.html HTTP/1.1

я должен

a) отправить код ошибки 405 (метод не разрешен) вместе с заголовком Allow:, например:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Date: ...

b) -ИЛИ- мне следует просто обработать запрос POST, как если бы это был запрос GET?

HTTP/1.1 200 OK
Date: ...

HTML-content-here

Имеет ли это значение или полностью зависит от меня? Есть ли какие-либо предостережения / угрозы безопасности при использовании варианта б)? Я стараюсь соблюдать как можно больше стандартов.

Answer 1

Это не имеет значения вообще.Существует (очень маленький) аргумент, что он может сделать ваш сайт менее взломанным, чтобы ограничить допустимые методы запроса, но не в реальном смысле.Единственное, с чем вам следует быть осторожным, это ограничить (и, возможно, полностью запретить) использование PUT и DELETE, поскольку они внесут прямое изменение в файловую систему вашего сервера.

Если получен запрос POSTна страницу, которая ожидает GET, есть вероятность, что кто-то играет, чтобы увидеть, что примет ваш сайт, возможно, попытаться найти дыру в безопасности.Сказав это, маловероятно, что будут какие-то потенциальные дыры, которые также нельзя было бы использовать с помощью запроса GET.

Может быть полезно разрешить и то и другое, если вы случайно поставили method="post" на <form>, который вы не имели в виду, но в равной степени, если вы сделаете это, это может затруднить поиск проблемы, которая проявляется в дальнейшем.Если у вас есть сценарий, который обрабатывает отправку форм из более чем одной формы на вашем сайте, вероятно, было бы целесообразно принять обе, но для обычных страниц в этом не должно быть необходимости.

Одна вещь, которую вы забыли упомянутьвопрос (не в том, что это имеет значение) заключается в том, что POST-запросы также требуются при загрузке файла через HTML-форму - смысл POST-запроса заключается не просто в том, чтобы скрыть данные из URL (хотя это полезный побочный эффект), но разрешить клиенту отправлять объект на сервер.Этот объект может быть данными формы, или это может быть файл, документ XML и т. Д. И т. Д. Например, многие API-интерфейсы XML-HTTP используют POST (и они должны это делать - я встречал тот, который использовал GET в прошлом, и онработать с ним было кошмаром, поскольку это означало, что в документе не могло быть пробелов, или это нарушало запрос, вам приходилось кодировать XML-документ, который требует много времени и ресурсов и не имеет смысла).

Это действительно что-то, чтобы определить на ваше усмотрение.

Answer 2

Одна из причин, по которой это имеет значение, заключается в том, что спецификация протокола предполагает, что вещи, обслуживаемые запросами GET, являются идемпотентными, а вещи, обслуживаемые POST, - нет.Это важно для клиентов, выполняющих, например, конвейерную обработку запросов HTTP / 1.1, и прокси-серверы могут вести себя по-разному, используя глагол в качестве подсказки.

Мы далеки от мира, в котором вышеуказанное правило действует 100% времени, но я бы посоветовал вам внести свой вклад - используйте GET для случаев, когда вы просто извлекаетедокумент и использовать POST, когда вы изменяете ресурс, меняете состояние и т. д.

Да, и, кстати, не случайно отправлять строку запроса вместе с запросом POST.На рынке есть основные приложения, которые делают это.

Answer 3

а.

Хотя я сомневаюсь, что это вообще имеет значение, и б не причинит вреда.Вы должны быть строгими в этом, только если вы создаете веб-сервис RESTful, чтобы он работал согласованно.Если вы создаете веб-сайт, как кто-то может случайно завершить POSTing?

Просто чтобы вы знали, все предложение начинается с начала Обычно метод POST используется только если ... неправильно.

Это определенно не относится к POST, и оно отражает неверное понимание HTTP.GET и POST, согласно протоколу, очень разные.Один должен ничего не делать кроме извлечения данных, другой должен привести к выполнению действия.

Правда в истории веб-страниц и сетиНа серверах эти правила часто игнорировались и только недавно вошли в моду при разработке веб-API RESTful.