Метод post html: Отправка данных формы — Изучение веб-разработки — Вебджем.рф

Содержание

POST — HTTP | MDN

HTTP-метод POST предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке Content-Type.

Разница между PUT и POST состоит в том, что PUT является идемпотентным: повторное его применение даёт тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.

Запрос POST обычно отправляется через форму HTML и приводит к изменению на сервере. element or the formenctype attribute of the <input> or <button> elements:»>В этом случае тип содержимого выбирается путём размещения соответствующей строки в атрибуте enctype элемента <form> или formenctype атрибута элементов <input> или

<button>:

application/x-www-form-urlencoded: значения кодируются в кортежах с ключом, разделённых символом '&', с '=' между ключом и значением. Не буквенно-цифровые символы — percent encoded: это причина, по которой этот тип не подходит для использования с двоичными данными (вместо этого используйте multipart/form-data)
multipart/form-data: каждое значение посылается как блок данных («body part»), с заданными пользовательским клиентом разделителем («boundary»), разделяющим каждую часть. Эти ключи даются в заголовки Content-Disposition каждой части
text/plain

Когда запрос POST отправляется с помощью метода, отличного от HTML-формы, — например, через XMLHttpRequest — тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST предназначен для обеспечения единообразного метода для покрытия следующих функций:

Аннотация существующих ресурсов
Публикация сообщения на доске объявлений, в новостной группе, в списке рассылки или в аналогичной группе статей;
Добавление нового пользователя посредством модальности регистрации;
Предоставление блока данных, например, результата отправки формы, процессу обработки данных;
Расширение базы данных с помощью операции добавления.

Запрос имеет тело	Да
Успешный ответ имеет тело	Да
Безопасный	Нет
Идемпотентный	Нет
Кешируемый	Только если включена информация о свежести сообщения
Допускается в HTML-формах	Да

POST /index.html

Простая форма запроса, используя стандартный application/x-www-form-urlencoded content type:

POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
say=Hi&to=Mom

Форма запроса, используя multipart/form-data content type:

POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"
--boundary
Content-Disposition: form-data; name="field1"
value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example. txt"
value2
--boundary--

Specification
HTTP Semantics # POST

BCD tables only load in the browser

with JavaScript enabled. Enable JavaScript to view data.

Content-Type
Content-Disposition
GET

Last modified: 26 окт. 2022 г., by MDN contributors

Использование методов Get и Post

Главная » PHP

22.11.2020Рубрика: PHPАвтор: w-admin

Опытный читатель наверняка заметил, что мы коечто пропустили в открыва ющем тэге

, а именно атрибут METHOD.

Этот атрибут указывает серверу, как передавать данные из формы в обрабатывающий сценарий. Я не упоминал об этом раньше, так как данная тема заслуживает отдельного обсуждения.

ля атрибута METHOD имеется два варианта: GET и POST. Я подозреваю, что многие программисты на HTML не совсем ясно понимают разницу между ними и не всегда знают, когда какой использовать. По сути, между этими вариантами нет большой разницы, особенно если вы начинаете их использовать впервые, так как оба приведут к желаемому результату.

Разница между вариантами GET и POST состоит только в том, как информа ция передается из формы в обрабатывающий сценарий. Метод GET посылает всю собранную информацию как часть адреса URL. Метод POST передает ин формацию так, что пользователь этого не видит. Например, при использова нии метода GET, после передачи информации URL примет следующий вид:

http://www.DMCinsights.com/php/HandleForm.php?FirstName=Larry&Las Name=Ullman.

При использовании метода POST конечный пользователь увидит только та кую запись:

http://www. DMCinsights.com/php/HandleForm.php.

При выборе метода следует учитывать три фактора:

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

Для обработки форм мы будем использовать метод POST. Там, где метод GET предлагает дополнительные возможности вашему Webсайту, мы обратимся к этому способу (см. раздел «Ввод данных вручную»). Оба метода успешно пе редают данные из формы, и, принимая окончательное решение о применении того или другого варианта, вы обязательно должны учитывать три вышеупо мянутых фактора.

Добавление метода в сценарий

Откройте страницу form. html в текстовом редакторе.
В открывающий тэг вставьте METHOD=POST (строка 6, листинг 3.3). Листинг 3.3 т Вам решать, какой метод GET или POST использовать. Глав ное, вообще не забывать обращаться к одному из них. Когда вы наберетесь опы та, то сможете легко определять, в какой ситуации удобней тот или иной ме тод, но это больше вопрос эстетический, чем функциональный.

1.

2.
3. <title:>HTML Form
4.
5.
6. </title:>
7. First Name <input name=»FirstName» size=»20″ type=»text»>

Сохраните сценарий и загрузите его на сервер.

Просмотрите исходный текст страницы и убедитесь, что там есть все не обходимые элементы.

0 16 844 просмотров

Понравилась статья? Поделиться с друзьями:

Ключевая разница между методами HTTP

АвторLawrence Williams

Часы

Обновлено 12 ноября 2022 г.

Что такое ПОЛУЧИТЬ?

Метод GET используется для добавления данных формы к URL-адресу в паре имени или значения. Если вы используете GET, длина URL останется ограниченной. Это помогает пользователям представить результат в закладки. GET лучше подходит для данных, которые не требуют какой-либо защиты или имеют изображения или текстовые документы.

В этом GET Vs. Учебник POST, вы узнаете:

Что такое GET?
Что такое POST?
Особенности GET
Особенности POST
Пример метода GET
Пример метода POST
Разница между GET и POST
Преимущества GET
Преимущества POST
Недостатки GET
Недостатки POST

Что такое POST?

POST — это метод, который поддерживается HTTP и показывает, что веб-сервер принимает данные, включенные в тело сообщения. POST часто используется World Wide Web для отправки сгенерированных пользователем данных на веб-сервер или при загрузке файла.

Особенности GET

Вот важные особенности GET:

С помощью метода GET очень легко добавлять данные в закладки.

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

Особенности POST

Вот важные особенности POST:

Запрос метода POST получает входные данные из тела запроса и строки запроса.
Данные, переданные методом POST, не будут отображаться в параметрах запроса в URL-адресе браузера.
параметры методов POST не сохраняются в истории браузера.
Нет ограничений на длину передаваемых данных.
Помогает вам безопасно передавать конфиденциальную информацию, такую как данные для входа, на сервер.

Пример метода GET

Вот пример метода GET:

 GET/RegisterStudent.asp?user=value1&pass=value2

Пример метода POST

Вот пример метода POST:

 POST/RegisterStudent.asp HTTP/1.1
Хост: www.guru99.com
пользователь=значение1&пароль=значение2

Форма, использующая тип содержимого application/x-www-form-urlencoded по умолчанию:

Разница между GET и POST

Вот основные различия между GET и POST:

GET

ПОЧТ
В методе GET значения отображаются в URL-адресе.	В методе POST значения не отображаются в URL-адресе.
GET имеет ограничение на длину значений, обычно 255 символов.	POST не имеет ограничений на длину значений, поскольку они передаются через тело HTTP.
GET выполняет лучше по сравнению с POST из-за простого характера добавления значений в URL.	Он имеет более низкую производительность по сравнению с методом GET из-за времени, затрачиваемого на включение значений POST в тело HTTP.
Этот метод поддерживает только строковые типы данных.	Этот метод поддерживает различные типы данных, такие как строковые, числовые, двоичные и т. д.
Результаты GET можно добавить в закладки.	Результаты POST не могут быть добавлены в закладки.
Запрос GET часто кэшируется.	Запрос POST с трудом поддается кэшированию.
GET Параметры остаются в истории веб-браузера.	Параметры не сохраняются в истории веб-браузера.

Ознакомьтесь с нашим руководством по разнице между HTTP и HTTPS: — Нажмите здесь

Преимущества GET

Вот преимущества / плюсы использования GET:

Метод GET может извлекать информацию, идентифицированную URL-адресом запроса ( Единый идентификатор ресурса).
запросов GET можно просмотреть в истории браузера.
Позволяет сохранять результаты формы HTML.
Вы можете легко использовать метод GET для запроса необходимых данных.

Преимущества POST

Вот преимущества и плюсы использования POST:

Этот метод помогает определить URI ресурса.
Задать новый заголовок местоположения ресурса очень просто, используя заголовок местоположения.
Вы можете отправить запрос на принятие объекта в качестве нового ресурса, который идентифицируется URI.
Вы можете отправлять пользовательские данные на веб-сервер.
Это очень полезно, когда вы не имеете ни малейшего представления о ресурсе, который вы должны сохранить в URL-адресе.
Используйте POST, если вам нужен сервер, который контролирует создание URL-адресов ваших ресурсов.
POST — это безопасный метод, поскольку его запросы не сохраняются в истории браузера.
С помощью почты можно легко передавать большие объемы данных.
Вы можете сохранить данные в тайне.
Этот метод можно использовать для отправки двоичных данных, а также данных ASCII.

Недостатки GET

Вот недостатки/недостатки использования GET:

GET нельзя использовать для отправки текстовых документов или изображений.
Запросы GET можно использовать только для получения данных
Метод GET нельзя использовать для передачи конфиденциальной информации, такой как имена пользователей и пароли.
Длина URL-адреса ограничена.
Если вы используете метод GET, браузер добавляет данные к URL-адресу.
Вы можете легко добавить значение строки запроса в закладки в GET

Недостатки POST

Вот минусы/недостаток использования POST:

Невозможно сохранить данные, так как данные, отправленные методом POST, не видны в URL-адресе.
Вы не видите запросы POST в истории браузера.
Этот метод несовместим со многими настройками брандмауэра.
Вы не можете использовать пробелы, табуляцию, резню и т. д.
Этот метод несовместим с некоторыми настройками брандмауэра.
Метод POST занимает много времени при загрузке большого двоичного файла.

КЛЮЧЕВАЯ РАЗНИЦА:

В методе GET значения отображаются в URL-адресе, а в методе POST значения НЕ отображаются в URL-адресе.
GET имеет ограничение на длину значений, обычно 255 символов, тогда как POST не имеет ограничений на длину значений, поскольку они передаются через тело HTTP.
Метод GET поддерживает только строковые типы данных, тогда как метод POST поддерживает различные типы данных, такие как строковые, числовые, двоичные и т. д.
Запрос GET часто кэшируется, в то время как запрос POST практически не кэшируется.
GET работает лучше, чем POST.

HTTP/1.1: определения методов

HTTP/1.1: Определения методов

часть протокола передачи гипертекста — HTTP/1.1
RFC 2616 Филдинг и др.

Набор общих методов для HTTP/1.1 определен ниже. Хотя этот набор можно расширить, нельзя предполагать, что дополнительные методы используют одну и ту же семантику для отдельно расширенных клиентов и серверов.

Поле заголовка запроса хоста (раздел 14.23) ДОЛЖНО сопровождать все Запросы HTTP/1.1.

9.1 Безопасные и идемпотентные методы

9.1.1 Безопасные методы

Разработчики должны знать, что программное обеспечение представляет пользователя в их взаимодействие через Интернет, и следует быть осторожным, чтобы разрешить пользователю быть в курсе любых действий, которые они могут предпринять, которые могут иметь неожиданное значение для себя или других.

В частности, было установлено соглашение о том, что GET и Методы HEAD НЕ ДОЛЖНЫ иметь значение выполнения действия кроме поиска. Эти методы следует считать «безопасными». Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT. и УДАЛИТЬ, особым образом, чтобы пользователь знал о тот факт, что запрашивается возможно небезопасное действие.

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

9.1.2 Идемпотентные методы

Методы также могут обладать свойством «идемпотентности» в том, что (кроме из-за ошибок или проблем с истечением срока действия) побочные эффекты N > 0 идентичны запросы такие же, как и для одного запроса. Методы GET, HEAD, PUT и DELETE разделяют это свойство. Кроме того, методы OPTIONS и TRACE НЕ ДОЛЖЕН иметь побочных эффектов, поэтому они по своей сути идемпотентны.

Однако возможно, что последовательность из нескольких запросов не идемпотент, даже если все методы, выполняемые в этой последовательности, идемпотент. (Последовательность является идемпотентной, если одно выполнение вся последовательность всегда дает результат, который не изменяется повторного выполнения всей или части этой последовательности.) Например, последовательность неидемпотентна, если ее результат зависит от значения, которое позже изменены в той же последовательности.

Последовательность, которая никогда не имеет побочных эффектов, является идемпотентной по определению. (при условии, что на один и тот же набор ресурсов).

9.2 ОПЦИИ

Метод OPTIONS представляет собой запрос информации о варианты связи, доступные в цепочке запросов/ответов определяется Request-URI. Этот метод позволяет клиенту определить варианты и/или требования, связанные с ресурсом, или возможности сервера, не подразумевая действие ресурса или инициирование поиска ресурсов.

Ответы на этот метод не кэшируются.

Если запрос OPTIONS включает тело объекта (как указано наличие Content-Length или Transfer-Encoding), то тип носителя ДОЛЖЕН указываться полем Content-Type. Хотя это спецификация не определяет какое-либо использование такого кузова в будущем расширения для HTTP могут использовать тело OPTIONS, чтобы сделать более подробными запросы на сервере. Сервер, который не поддерживает такой расширение МОЖЕТ отбросить тело запроса.

Если Request-URI представляет собой звездочку («*»), запрос OPTIONS предназначен для применения к серверу в целом, а не к конкретному ресурс. Поскольку параметры связи сервера обычно зависят от ресурс, запрос «*» полезен только как «ping» или «no-op» тип метода; он ничего не делает, кроме как позволяет клиенту протестировать возможности сервера. Например, это можно использовать для проверки прокси для соответствия HTTP/1.1 (или его отсутствия).

Если Request-URI не является звездочкой, применяется запрос OPTIONS. только к тем вариантам, которые доступны при общении с этим ресурс.

Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к этому ресурс (например, Разрешить), возможно, включая расширения, не определенные эта спецификация. Тело ответа, если таковое имеется, СЛЕДУЕТ также включать информация о возможностях связи. Формат для такого

body не определяется этой спецификацией, но может быть определено будущие расширения HTTP. Согласование содержимого МОЖЕТ использоваться для выбора соответствующий формат ответа. Если тело ответа не включено, ответ ДОЛЖЕН включать поле Content-Length со значением поля «0».

Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для конкретный прокси в цепочке запросов. Когда прокси получает OPTIONS запрос на absoluteURI, для которого разрешена переадресация запроса, прокси-сервер ДОЛЖЕН проверять наличие поля Max-Forwards. Если Макс-Форвардс значение поля равно нулю («0»), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение; вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом больше нуля, прокси ДОЛЖЕН уменьшать значение поля при пересылке запроса. Если поле Max-Forwards отсутствует в запросе, то перенаправленный запрос НЕ ДОЛЖЕН включать поле Max-Forwards. Частичные GET-запросы что только часть объекта будет передана, как описано в разделе 14.35. Частичный метод GET предназначен для сокращения ненужных использования сети, позволяя частично извлеченным объектам быть завершена без передачи данных, уже имеющихся у клиента.

Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует требования к кэшированию HTTP, описанные в разделе 13.

См. раздел 15.1.3 по соображениям безопасности при использовании для форм.

ГОЛОВКА 9,4

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН вернуть тело сообщения в ответ. Метаинформация содержала в заголовках HTTP в ответ на запрос HEAD ДОЛЖЕН быть идентичным к информации, отправленной в ответ на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, подразумеваемом запрос без передачи самого тела сущности. Этот метод часто используется для проверки гипертекстовых ссылок на достоверность, доступность, и недавняя модификация.

Ответ на запрос HEAD МОЖЕТ кэшироваться в том смысле, что информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления ранее кэшированный объект из этого ресурса. Если новые значения поля указать, что кэшированный объект отличается от текущего объекта (как будет указано изменением Content-Length, Content-MD5, ETag или Last-Modified), то кэш ДОЛЖЕН обрабатывать запись кэша как несвежий.

9.5 ПОСТ

Метод POST используется для запроса того, чтобы исходный сервер принял сущность, заключенная в запросе в качестве нового подчиненного ресурса определяется Request-URI в строке запроса. ПОСТ предназначен чтобы позволить единому методу охватить следующие функции:

 - Аннотация существующих ресурсов;

 - Публикация сообщения на доске объявлений, в группе новостей, в списке рассылки,
        или аналогичная группа статей;

 - Предоставление блока данных, например, в результате отправки
        форма для процесса обработки данных;

 - Расширение базы данных с помощью операции добавления.

Фактическая функция, выполняемая методом POST, определяется server и обычно зависит от Request-URI. Размещенный объект является подчиненным этому URI так же, как файл является подчиненным к каталогу, содержащему его, новостная статья подчинена группа новостей, в которую она отправлена, или запись подчинена база данных.

Действие, выполняемое методом POST, может не привести к ресурс, который можно идентифицировать по URI. В этом случае либо 200 (ОК) или 204 (Нет содержимого) — соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.

Если ресурс был создан на исходном сервере, ответ ДОЛЖЕН иметь значение 201 (Создано) и содержать сущность, описывающую статус запроса и относится к новому ресурсу, а местоположение заголовок (см. раздел 14.30).

Ответы на этот метод не кэшируются, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. Другое) может использоваться для направления пользовательского агента к получить кешируемый ресурс.

Запросы POST ДОЛЖНЫ соответствовать требованиям к передаче сообщений, изложенным в разделе 8.2.

См. раздел 15.1.3 по соображениям безопасности.

9.6 ПУТ

Метод PUT запрашивает, чтобы вложенный объект был сохранен в предоставленный Request-URI. Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированная версия той, что находится на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользователем агент, исходный сервер может создать ресурс с этим URI. Если создается новый ресурс, исходный сервер ДОЛЖЕН информировать пользовательский агент через ответ 201 (Создано). Если существующий ресурс изменен, ДОЛЖНЫ быть отправлены коды ответов 200 (ОК) или 204 (Нет контента). чтобы указать на успешное выполнение запроса. Если ресурс не может быть создан или изменен с помощью Request-URI, соответствующий СЛЕДУЕТ давать ответ об ошибке, отражающий природу ошибки. проблема. Получатель объекта НЕ ДОЛЖЕН игнорировать любой Контент-* (например, Content-Range) заголовки, которые он не понимает или не реализует и ДОЛЖЕН возвращать ответ 501 (не реализовано) в таких случаях.

Если запрос проходит через кеш и Request-URI идентифицирует один или несколько кэшированных объектов, эти записи ДОЛЖНЫ быть рассматривается как устаревший. Ответы на этот метод не кэшируются.

Фундаментальное различие между запросами POST и PUT заключается в следующем. отражается в различном значении Request-URI. URI в Запрос POST идентифицирует ресурс, который будет обрабатывать вложенный юридическое лицо. Этот ресурс может быть процессом приема данных, шлюзом к какой-то другой протокол или отдельный объект, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом — пользовательский агент знает, какой URI предназначен, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу. Если сервер желает, чтобы запрос был применен к другому URI,

он ДОЛЖЕН отправить ответ 301 (перемещен навсегда); пользовательский агент МОЖЕТ затем принять собственное решение относительно того, следует ли перенаправлять запрос.

Один ресурс МОЖЕТ быть идентифицирован многими различными URI. За например, статья может иметь URI для идентификации «текущего версия», которая отделена от URI, идентифицирующего каждую конкретную версия. В этом случае запрос PUT на общий URI может привести к несколько других URI определяются исходным сервером.

HTTP/1.1 не определяет, как метод PUT влияет на состояние исходный сервер.

Запросы PUT ДОЛЖНЫ соответствовать требованиям к передаче сообщений, изложенным в разделе 8. 2.

Если иное не указано для конкретного заголовка сущности, заголовки объектов в запросе PUT ДОЛЖНЫ применяться к ресурсу созданный или измененный PUT.

9.7 УДАЛИТЬ

Метод DELETE запрашивает, чтобы исходный сервер удалил ресурс. определяется Request-URI. Этот метод МОЖЕТ быть переопределен человеком вмешательство (или другие средства) на исходном сервере. клиент не может гарантировать, что операция была выполнена, даже если код состояния, возвращенный исходным сервером, указывает, что действие был успешно завершен. Однако сервер НЕ ДОЛЖЕН указывают на успех, если только в момент ответа намеревается удалить ресурс или переместить его в недоступное место расположения.

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответ включает в себя объект, описывающий статус, 202 (Принято), если действие не было еще не было выполнено, или 204 (Нет контента), если действие было выполнено. но ответ не включает сущность.

9.8 ТРАССА

Метод TRACE используется для вызова удаленного цикла прикладного уровня. обратная сторона сообщения запроса. Конечный получатель запроса СЛЕДУЕТ отражать сообщение, полученное обратно клиенту, как сущность-тело ответа 200 (ОК). Конечным получателем является либо

исходный сервер или первый прокси или шлюз, получивший Max-Forwards значение нуля (0) в запросе (см. раздел 14.31). TRACE-запрос НЕ ДОЛЖЕН включать сущность.

TRACE позволяет клиенту видеть, что принимается на другом конец цепочки запросов и использовать эти данные для тестирования или диагностики Информация. Значение поля заголовка Via (раздел 14.45) равно особый интерес, так как он действует как трассировка цепочки запросов.

Метод post html: Отправка данных формы — Изучение веб-разработки