Get запрос: Чем отличаются HTTP-методы GET и POST — Блог HTML Academy

Методы GET и POST. Использование и отличия

Рейтинг: 5 из 5, голосов 155

28 декабря 2019 г.

HTTP методы GET и POST используются для отправки данных на сервер.

Чаще всего методы используются в HTML формах, гиперссылках и AJAX запросах.

POST и GET запросы можно отправить на сервер с помощью любого программного обеспечения, работающего с протоколом HTTP.

Обработка запросов может отличаться в зависимости от типа сервера.

Большинство действующих сайтов работают с языком программирования PHP. В этом случае передаваемые данные попадают в суперглобальные массивы $_GET и $_POST.

Массивы $_GET и $_POST являются ассоциативными. Таким образом, переданный на сервер параметр с именем «user_name», будет доступен как $_GET[‘user_name’] или $_POST[‘user_name’] в зависимости от используемого метода.

Какой метод использовать GET или POST, чем отличаются методы

Основное отличие метода GET от POST в способе передачи данных.

Запрос GET передает данные в URL в виде пар «имя-значение» (другими словами, через ссылку), а запрос POST передает данные в теле запроса (подробно показано в примерах ниже). Это различие определяет свойства методов и ситуации, подходящие для использования того или иного HTTP метода.

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

Например, можно использовать метод GET в HTML форме фильтра товаров: когда нужно, исходя из данных введенных пользователем, переправить его на страницу с отфильтрованными товарами, соответствующими его выбору.

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

HTTP метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы.

Также следует заметить, что методы можно комбинировать. То есть, при необходимости вы можете отправить POST запрос на URL, имеющий GET параметры.

В каких случаях использовать POST и когда нужно использовать GET

В таблице ниже показаны распространенные варианты использования HTTP запросов с объяснением в чем разница между GET и POST запросами в конкретной ситуации.

Сравнительная таблица HTTP методов GET и POST

В таблице ниже приведены основные свойства и отличия GET и POST методов.

Пример использования GET запроса

В примере показана простая HTML форма фильтра по нескольким параметрам.

HTML код формы, генерирующей GET запрос:

<form method="GET" name="filter" action="http://example.com/catalog/">
<p>Диагональ экрана</p>
<label><input type="radio" name="screen" value="4" checked> 4</label><br>
<label><input type="radio" name="screen" value="4.5"> 4.5</label><br>
<label><input type="radio" name="screen" value="5"> 5</label>
<p>Цвет</p>
<label><input type="checkbox" name="color_black" checked> Черный</label><br>
<label><input type="checkbox" name="color_white" checked> Белый</label><br>
<label><input type="checkbox" name="color_golden"> Золотой</label><br>
<input type="submit" value="Применить фильтр">
</form>

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

http://example.com/catalog/?screen=4&color_black=on&color_white=on

Ссылка содержит URL документа, отвечающего за обработку и блок параметров. Знак «?» отмечает начало блока параметров GET запроса. Далее находятся пары «имя-значение», разделенные знаком «&». Имена параметров отделены от значений знаком «=».

Переход по ссылке, приведенной выше, будет равнозначен отправке формы с указанными параметрами.

Пример использования POST запроса

В примере показана простая HTML форма авторизации.

HTML код формы, генерирующей POST запрос:

<form method="POST" name="authorization" action="http://example.com/profile.php">
Логин: <input type="text" name="username"><br>
Пароль: <input type="password" name="user_password"><br>
<input type="submit" value="Войти">
</form>

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

http://example.com/profile.php

Для того, чтобы увидеть переданные параметры, воспользуемся инструментами разработчика.

Запрос состоит из области заголовков и тела запроса.

В заголовках указана служебная информация: URL обработчика, тип кодирования, параметры браузера и т. д.

В теле запроса содержатся передаваемые параметры. Формат тела запроса может отличаться в зависимости от выбранного типа кодирования.

by Lebedev

GET-запрос | База знаний

8 800 550–89–39+7 (499) 647–79–38

Включить защиту

Личный кабинет

Ru

Защита от DDoS

Защита сайтаХостинг с защитойЗащита сервисов TCP/UDPЗащита сети по BGPIP-транзит

Как это работает

Как работает StormWallТехнологииКак подключитьсяAPIБаза знаний

Партнерам

Для реселлеров и сервис-провайдеровWhite LabelПриведи друга

О компании

Почему StormWallМы защитилиБлогВакансииПресса о насО StormWall

Категории

Атака

Протокол

Термин

Команда

Дата-центрColocationWAFDDoSSmurf-атакаХостингВыделенный серверСервер VDS/VPSIP-туннелированиеDDoS-атаки «нулевого» дня (Zero Day DDoS attack, 0day DDoS attack)Домен, или доменное имяРоутер или маршрутизаторСерверСетевой трафик (Traffic)Куки (Cookie)Сеть доставки контента (Content Delivery Network, CDN)Атаки на сайты95-й перцентильTLS fingerprintingTCP-рукопожатиеDNSBLMAC-адрес (Media Access Control) или физический адресDoSIP-адресПрокси-серверFirewall

Популярные новости

Количество и мощность DDoS-атак в России в 2021 году значительно возрастет

StormWall стал участником пиринговой сети по обмену трафиком Equinix IX (Франкфурт)

Доступен новый личный кабинет управления защитой от DDoS

Мы используем cookie, чтобы сделать сайт быстрее и удобнее. Продолжая пользоваться сайтом, Вы соглашаетесь с нашей Политикой конфиденциальности

Защита от DDoSЗащита сайтаХостинг с защитойЗащита сервисов TCP/UDPЗащита сети по BGPIP-транзит

CDN & WAFСеть доставки контента (CDN)Облачный WAF

Серверы и VPSVDS/VPS

Как это работаетКак работает StormWallТехнологииКак подключитьсяAPIБаза знаний

ПартнерамДля реселлеров и сервис-провайдеровWhite LabelПриведи друга

КомпанияПочему StormWallМы защитилиБлогВакансииПресса о насО StormWall

Защита от DDoS

Защита сайта

Хостинг с защитой

Защита сервисов TCP/UDP

Защита сети по BGP

IP-транзит

CDN & WAF

Сеть доставки контента (CDN)

Облачный WAF

Серверы и VPS

VDS/VPS

Как это работает

Как работает StormWall

Технологии

Как подключиться

API

База знаний

Партнерам

Для реселлеров и сервис-провайдеров

White Label

Приведи друга

Компания

Почему StormWall

Мы защитили

Блог

Вакансии

Пресса о нас

О StormWall

Ru

Способы оплаты

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

© 2013-

2022

StormWall.pro. All rights reserved Privacy Policy

Введение в REST-запросы и тестирование GET-запросов

Быстрый старт — Запросы документации 2.28.1

Хотите начать? Эта страница дает хорошее представление о том, как начать работу с запросами.

Во-первых, убедитесь, что:

Давайте начнем с нескольких простых примеров.

Сделать запрос

Сделать запрос с помощью Requests очень просто.

Начните с импорта модуля «Запросы»:

 >>> запросы на импорт
 

Теперь давайте попробуем получить веб-страницу. Для этого примера давайте получим общедоступный GitHub временная шкала:

 >>> r = request.get('https://api.github.com/events')
 

Теперь у нас есть объект Response с именем r . Мы можем получить всю необходимую нам информацию от этого объекта.

Requests означает, что все формы HTTP-запросов очевидны. За например, вот как вы делаете запрос HTTP POST:

 >>> r = request.post('https://httpbin.org/post', data={'key': 'value'})
 

Красиво, правда? А как насчет других типов HTTP-запросов: PUT, DELETE, HEAD и ОПЦИИ? Все так же просто:

 >>> r = request.put('https://httpbin.org/put', data={'key': 'value'})
>>> r = request.delete('https://httpbin.org/delete')
>>> r = request.head('https://httpbin.org/get')
>>> r = request.options('https://httpbin.org/get')
 

Это все хорошо, но это только начало того, что могут сделать Запросы. делать.

Передача параметров в URL-адресах

Вы часто хотите отправить какие-то данные в строке запроса URL. Если вы создавали URL-адрес вручную, эти данные будут представлены как ключ/значение пары в URL-адресе после вопросительного знака, например. httpbin.org/get?key=val . Запросы позволяют вам предоставлять эти аргументы в виде словаря строк, используя аргумент ключевого слова params . Например, если вы хотите пройти key1=value1 и key2=value2 to httpbin.org/get , вы должны использовать следующий код:

 >>> полезная нагрузка = {'key1': 'value1', 'key2': 'value2'}
>>> r = request.get('https://httpbin.org/get', params=payload)
 

Вы можете убедиться, что URL-адрес был правильно закодирован, распечатав URL-адрес:

 >>> print(r.url)
https://httpbin.org/get?key2=value2&key1=value1
 

Обратите внимание, что любой ключ словаря, значение которого равно None , не будет добавлен в Строка запроса URL.

Вы также можете передать список элементов как значение:

 >>> полезная нагрузка = {'ключ1': 'значение1', 'ключ2': ['значение2', 'значение3']}
>>> r = request.get('https://httpbin.org/get', params=payload)
>>> напечатать(r.url)
https://httpbin. org/get?key1=value1&key2=value2&key2=value3
 

Содержание ответа

Мы можем прочитать содержимое ответа сервера. Рассмотрите временную шкалу GitHub еще раз:

 >>> запросы на импорт
>>> r = request.get('https://api.github.com/events')
>>> р.текст
'[{"репозиторий":{"open_issues":0,"url":"https://github.com/...
 

Запросы будут автоматически декодировать контент с сервера. Самый юникод кодировки легко декодируются.

Когда вы делаете запрос, Requests делает обоснованные предположения о кодировке ответ на основе заголовков HTTP. Кодировка текста, угадываемая Requests используется при доступе к р.текст . Вы можете узнать, что такое кодировка Requests using и измените его, используя свойство r.encoding :

 >>> р.кодировка
'утф-8'
>>> r.encoding = 'ISO-8859-1'
 

Если вы измените кодировку, запросы будут использовать новое значение r.encoding всякий раз, когда вы звоните r.text . Вы можете сделать это в любой ситуации, когда вы можете применить специальную логику, чтобы выяснить, какая кодировка контента будет быть. Например, HTML и XML имеют возможность указать свою кодировку в их тело. В таких ситуациях вы должны использовать r.content найти кодировку, а затем установите r.encoding . Это позволит вам использовать r.text с правильная кодировка.

также будут использовать пользовательские кодировки, если они вам нужны. Если вы создали свою собственную кодировку и зарегистрировали ее с кодеками модуль, вы можете просто использовать имя кодека в качестве значения r.encoding и Запросы будут обрабатывать декодирование для вас.

Содержимое двоичного ответа

Вы также можете получить доступ к телу ответа в виде байтов для нетекстовых запросов:

 >>> р.содержимое
b'[{"репозиторий":{"open_issues":0,"url":"https://github.com/...
 

Кодирование передачи gzip и deflate автоматически декодируется для вас.

Кодирование передачи br автоматически декодируется для вас, если библиотека Brotli например, brotli или brotlicffi.

Например, чтобы создать образ из бинарных данных, возвращаемых запросом, вы можете используйте следующий код:

 >>> из изображения импорта PIL
>>> из io импортировать BytesIO
>>> i = Image.open(BytesIO(r.content))
 

Содержимое ответа JSON

Также имеется встроенный декодер JSON, если вы имеете дело с данными JSON:

 >>> запросы на импорт
>>> r = request.get('https://api.github.com/events')
>>> р.json()
[{'репозиторий': {'open_issues': 0, 'url': 'https://github.com/...
 

В случае сбоя декодирования JSON r.json() вызывает исключение. Например, если ответ получает 204 (нет содержимого), или если ответ содержит недопустимый JSON, попытка r.json() вызывает request.exceptions.JSONDecodeError . Это исключение оболочки обеспечивает взаимодействие для нескольких исключений, которые могут быть вызваны разными версии python и библиотеки сериализации json.

Следует отметить, что успех вызова r.json() делает не указать успешность ответа. Некоторые серверы могут возвращать объект JSON в неудачный ответ (например, сведения об ошибке с HTTP 500). Такой JSON будет декодирован и вернулся. Чтобы проверить успешность запроса, используйте r.raise_for_status() или проверка r.status_code — это то, что вы ожидаете.

Необработанное содержимое ответа

В редких случаях, когда вы хотите получить необработанный ответ сокета от сервер, вы можете получить доступ к r.raw . Если вы хотите сделать это, убедитесь, что вы установили stream = True в вашем первоначальном запросе. Как только вы это сделаете, вы можете сделать это:

 >>> r = request.get('https://api.github.com/events', stream=True)
>>> r.raw

>>> r.raw.read(10)
'\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03'
 

В целом, однако, вы должны использовать подобный шаблон, чтобы сохранить то, что передано в файл:

 с открытым (имя файла, 'wb') как fd:
    для чанка в r. iter_content(chunk_size=128):
        fd.write(чанк)
 

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

Note

Важное примечание об использовании Response.iter_content по сравнению с Response.raw . Response.iter_content автоматически декодирует gzip и deflate трансфер-кодировки. Response.raw — необработанный поток байтов. преобразовать содержимое ответа. Если вам действительно нужен доступ к байтам, поскольку они были возвращены, используйте Ответ. raw .

Более сложные запросы POST

Как правило, вы хотите отправить некоторые данные, закодированные в форме — очень похоже на HTML-форму. Для этого просто передайте словарь в аргумент data . Ваш словарь данных будет автоматически закодирован в форме при запросе:

 >>> полезная нагрузка = {'key1': 'value1', 'key2': 'value2'}
>>> r = request.post("https://httpbin.org/post", data=payload)
>>> печать (р.текст)
{
  ...
  "форма": {
    "ключ2": "значение2",
    "ключ1": "значение1"
  },
  ...
}
 

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

 >>> payload_tuples = [('ключ1', 'значение1'), ('ключ1', 'значение2')]
>>> r1 = request.post('https://httpbin.org/post', data=payload_tuples)
>>> payload_dict = {'key1': ['value1', 'value2']}
>>> r2 = request. post('https://httpbin.org/post', data=payload_dict)
>>> печать(r1.текст)
{
  ...
  "форма": {
    "ключ1": [
      "значение1",
      "значение2"
    ]
  },
  ...
}
>>> r1.текст == r2.текст
Истинный
 

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

Например, GitHub API v3 принимает данные POST/PATCH в формате JSON:

 >>> импортировать json
>>> url = 'https://api.github.com/some/endpoint'
>>> полезная нагрузка = {'некоторые': 'данные'}
>>> r = request.post(url, data=json.dumps(полезная нагрузка))
 

Обратите внимание, что приведенный выше код НЕ добавит Заголовок Content-Type (поэтому, в частности, он НЕ будет устанавливать его на application/json ).

Если вам нужен этот набор заголовков и вы не хотите самостоятельно кодировать dict , вы также можете передать его напрямую, используя параметр json (добавлен в версии 2. 4.2) и он будет закодирован автоматически:

 >>> url = 'https://api.github.com/some/endpoint'
>>> полезная нагрузка = {'некоторые': 'данные'}
 

 >>> r = request.post(url, json=полезная нагрузка)
 

Обратите внимание, что параметр json игнорируется, если передается либо данные , либо файлы .

POST файл, закодированный из нескольких частей

Запросы упрощают загрузку файлов с кодировкой Multipart:

 >>> URL = 'https://httpbin.org/post'
>>> files = {'файл': open('report.xls', 'rb')}
>>> r = request.post(url, files=файлы)
>>> р.текст
{
  ...
  "файлы": {
    "file": "<цензурированные...бинарные...данные>"
  },
  ...
}
 

Вы можете указать имя файла, тип содержимого и заголовки явно:

 >>> URL = 'https://httpbin.org/post'
>>> files = {'file': ('report.xls', open('report.xls', 'rb'), 'application/vnd.ms-excel', {'Expires': '0'}) }
>>> r = request.post(url, files=файлы)
>>> р. текст
{
  ...
  "файлы": {
    "file": "<цензурированные...бинарные...данные>"
  },
  ...
}
 

При желании вы можете отправить строки для получения в виде файлов:

 >>> URL = 'https://httpbin.org/post'
>>> files = {'file': ('report.csv', 'some,data,to,send\nanother,row,to,send\n')}
>>> r = request.post(url, files=файлы)
>>> р.текст
{
  ...
  "файлы": {
    "file": "некоторые,данные,кому,отправить\\nanother,строка,кому,отправить\\n"
  },
  ...
}
 

Если вы публикуете очень большой файл как multipart/form-data запрос, вы можете захотеть передать запрос. По умолчанию запрашивает не поддерживают это, но есть отдельный пакет, который делает — запрашивает пояс с инструментами . Вы должны прочитать документацию по поясу инструментов для получения более подробной информации о том, как его использовать.

Для отправки нескольких файлов в одном запросе обратитесь к расширенным раздел.

Предупреждение

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

Коды состояния ответа

Мы можем проверить код состояния ответа:

 >>> r = request.get('https://httpbin.org/get')
>>> r.status_code
200
 

Requests также поставляется со встроенным объектом поиска кода состояния для легкого ссылка:

 >>> r.status_code == request.codes.ok
Истинный
 

Если мы сделали неверный запрос (ошибка клиента 4XX или ответ об ошибке сервера 5XX), мы может поднять его с Ответ.raise_for_status() :

 >>> bad_r = request.get('https://httpbin.org/status/404')
>>> bad_r.status_code
404
>>> bad_r.raise_for_status()
Traceback (последний последний вызов):
  Файл "requests/models.py", строка 832, в raise_for_status
    поднять http_error
запросы. исключения.HTTPError: 404 Ошибка клиента
 

Но, так как наши status_code для r было 200 , когда мы звоним raise_for_status() получаем:

 >>> r.raise_for_status()
Никто
 

Все хорошо.

Печенье

Если ответ содержит несколько файлов cookie, вы можете быстро получить к ним доступ:

 >>> url = 'http://example.com/some/cookie/setting/url'
>>> r = запросы.get(url)
>>> r.cookies['example_cookie_name']
'example_cookie_value'
 

Чтобы отправить собственные файлы cookie на сервер, вы можете использовать печенье параметр:

 >>> URL = 'https://httpbin.org/cookies'
>>> cookies = dict(cookies_are='working')
>>> r = request.get(url, cookies=cookies)
>>> р.текст
'{"cookies": {"cookies_are": "рабочие"}}'
 

куки возвращаются в RequestsCookieJar , который действует как dict , но также предлагает более полный интерфейс, подходит для использования в нескольких доменах или путях. Баночки для печенья могут также передаваться в запросы:

 >>> jar = запросы.cookies.RequestsCookieJar()
>>> jar.set('tasty_cookie', 'ням', domain='httpbin.org', path='/cookies')
>>> jar.set('gross_cookie', 'blech', domain='httpbin.org', path='/в другом месте')
>>> URL = 'https://httpbin.org/cookies'
>>> r = request.get(url, cookies=jar)
>>> р.текст
'{"cookies": {"tasty_cookie": "ням"}}'
 

Перенаправление и история

По умолчанию запросы будут выполнять перенаправление местоположения для всех команд, кроме ГЛАВА.

Мы можем использовать свойство history объекта Response для отслеживания перенаправления.

Список Response.history содержит Ответ объектов, созданных для завершить запрос. Список отсортирован от самого старого к самому последнему отклик.

Например, GitHub перенаправляет все HTTP-запросы на HTTPS:

 >>> r = request.get('http://github.com/')
>>> р.url
'https://github. com/'
>>> r.status_code
200
>>> р.история
[<Ответ [301]>]
 

Если вы используете GET, OPTIONS, POST, PUT, PATCH или DELETE, вы можете отключить обработка перенаправления с параметром allow_redirects :

 >>> r = request.get('http://github.com/', allow_redirects=False)
>>> r.status_code
301
>>> р.история
[]
 

Если вы используете HEAD, вы также можете включить перенаправление:

 >>> r = request.head('http://github.com/', allow_redirects=True)
>>> р.url
'https://github.com/'
>>> р.история
[<Ответ [301]>]
 

Тайм-ауты

Вы можете указать Requests прекратить ожидание ответа после заданного количества секунд с параметром timeout . Почти весь производственный код должен использовать этот параметр почти во всех запросах. Невыполнение этого требования может привести к тому, что ваша программа висеть на неопределенный срок:

 >>> request.get('https://github.com/', timeout=0.001)
Traceback (последний последний вызов):
  Файл "", строка 1, в 
request. exceptions.Timeout: HTTPConnectionPool (host = 'github.com', port = 80): время ожидания запроса истекло. (время ожидания = 0,001)
 

Примечание

тайм-аут не является ограничением по времени на загрузку всего ответа; скорее, исключение возникает, если сервер не выдал ответ на тайм-аут секунды (точнее, если ни один байт не был получено на базовом сокете в течение тайм-аута секунд). Если тайм-аут не указан явно, запросы не тайм-аут.

Ошибки и исключения

В случае проблемы с сетью (например, сбой DNS, отказ в подключении и т. д.) Запросы поднимут Исключение ConnectionError .

Response.raise_for_status() будет поднять HTTPError , если HTTP-запрос вернул неудачный код состояния.

Если время ожидания запроса истекает, возникает исключение Timeout . поднятый.

Если запрос превышает настроенное максимальное количество перенаправлений, Возникает исключение TooManyRedirects .

Все исключения, явно вызываемые Requests, наследуются от запросы.исключения.RequestException .

Готовы к большему? Загляните в расширенный раздел.

Если вы находитесь на рынке труда, подумайте над тем, чтобы пройти этот тест по программированию. Существенное пожертвование будет сделано этому проекту, если вы найдете работу через эту платформу.

GET и POST — разница и сравнение

Различия в отправке форм

Фундаментальное различие между METHOD=»GET» и METHOD=»POST» заключается в том, что они соответствуют различным HTTP-запросам , как определено в спецификациях HTTP. Процесс отправки для обоих методов начинается одинаково — набор данных формы создается браузером, а затем кодируется способом, указанным атрибутом enctype . Для METHOD=»POST атрибут enctype может быть multipart/form-data или application/x-www-form-urlencoded , тогда как для METHOD=»GET» только application/x- Допускается www-form-urlencoded . Этот набор данных формы затем передается на сервер.

Для отправки формы с METHOD=»GET» браузер создает URL-адрес, принимая значение атрибута action , добавляя ? , а затем добавить набор данных формы (закодированный с использованием типа содержимого application/x-www-form-urlencoded). Затем браузер обрабатывает этот URL-адрес, как если бы он перешел по ссылке (или как если бы пользователь ввел URL-адрес напрямую). Браузер делит URL-адрес на части и распознает хост, а затем отправляет этому хосту запрос GET с остальной частью URL-адреса в качестве аргумента. Сервер берет его оттуда. Обратите внимание, что этот процесс означает, что данные формы ограничены кодами ASCII. Особое внимание следует уделить кодированию и декодированию других типов символов при их передаче через URL-адрес в формате ASCII.

Отправка формы с параметром METHOD=»POST» приводит к отправке запроса POST с использованием значения атрибута action и сообщения, созданного в соответствии с типом содержимого, указанным атрибутом enctype .

 ПОЛУЧИТЬ https://www.example.com/login.php?user=mickey&passwd=mini
 

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

Ссылки

• wikipedia:POST (HTTP)
• Методы HTTP-запроса
• Сообщение HTTP — W3. org
• Получение HTTP — W3.org
• Скрывает ли HTTPS доступ к URL-адресам? — Обмен стека

HTTP/1.1: запрос

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

 Запрос = Строка Запроса ; Раздел 5.1
                        *(( общий заголовок ; Раздел 4.5
                         | заголовок запроса; Раздел 5.3
                         | заголовок объекта ) CRLF) ; Раздел 7.1
                        CRLF
                        [тело сообщения]; Раздел 4.3
 

5.1 Строка запроса

Строка запроса начинается с маркера метода, за которым следует Request-URI и версия протокола, заканчивающаяся на CRLF. элементы разделяются символами SP. CR или LF не допускаются за исключением последней последовательности CRLF.

 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
 

5.1.1 Метод

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

 Метод = "ВАРИАНТЫ" ; Раздел 9.2
                      | "ПОЛУЧИТЬ"                    ; Раздел 9.3
                      | "ГЛАВА"                   ; Раздел 9.4
                      | "ПОЧТА"                   ; Раздел 9.5
                      | "ПОМЕЩАТЬ"                    ; Раздел 9.6
                      | "УДАЛИТЬ"                 ; Раздел 9.7
                      | "СЛЕД"                  ; Раздел 9.8
                      | "СОЕДИНЯТЬ"                ; Раздел 9.9
                      | метод расширения
       метод расширения = токен
 

Список методов, разрешенных ресурсом, можно указать в Разрешить поле заголовка (раздел 14. 7). Код возврата ответа всегда уведомляет клиента, разрешен ли метод в настоящее время для ресурс, так как набор разрешенных методов может динамически меняться. Ан Исходный сервер ДОЛЖЕН возвращать код состояния 405 (метод не разрешен) если метод известен исходному серверу, но не разрешен для запрошенный ресурс и 501 (не реализовано), если метод не распознан или не реализован исходным сервером. Методы ПОЛУЧИТЬ и HEAD ДОЛЖЕН поддерживаться всеми серверами общего назначения. Все остальные методы НЕОБЯЗАТЕЛЬНЫ; однако, если вышеуказанные методы реализованы, они ДОЛЖНЫ быть реализованы с той же семантикой, что и указанные в разделе 9.

5.1.2 URI запроса

Request-URI является универсальным идентификатором ресурса (раздел 3.2) и идентифицирует ресурс, к которому применяется запрос.

 Request-URI = "*" | абсолютныйURI | абс_путь | орган власти
 

Четыре варианта Request-URI зависят от характера запрос. Звездочка «*» означает, что запрос не относится к конкретному ресурсу, а самому серверу и разрешено только когда используемый метод не обязательно относится к ресурсу. Один пример был бы

 ВАРИАНТЫ * HTTP/1.1
 

Форма absoluteURI НЕОБХОДИМА при отправке запроса прокси. Прокси запрашивается для пересылки запроса или его обслуживания из допустимого кеша и вернуть ответ. Обратите внимание, что прокси МОЖЕТ перенаправить запрос на другой прокси или напрямую на сервер

определяется абсолютнымURI. Чтобы избежать циклов запросов, прокси-сервер ДОЛЖЕН уметь распознавать все имена своих серверов, включая любые псевдонимы, локальные варианты и числовой IP-адрес. Пример Строка запроса будет:

 ПОЛУЧИТЬ http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
 

Чтобы разрешить переход на absoluteURI во всех запросах в будущем версии HTTP, все серверы HTTP/1.1 ДОЛЖНЫ принимать абсолютный URI формы в запросах, хотя клиенты HTTP/1. 1 будут генерировать только их в запросах к прокси.

Форма полномочий используется только методом CONNECT (раздел 9.9).

Наиболее распространенная форма Request-URI используется для идентификации ресурс на исходном сервере или шлюзе. В этом случае абсолютный путь URI ДОЛЖЕН быть передан (см. раздел 3.2.1, abs_path) как Request-URI и сетевое расположение URI (авторитета) ДОЛЖНЫ передаваться в поле заголовка Host. Например, клиент, желающий чтобы получить указанный выше ресурс непосредственно с исходного сервера, создайте TCP-соединение с портом 80 хоста «www.w3.org» и отправьте линии:

 ПОЛУЧИТЬ /pub/WWW/TheProject.html HTTP/1.1
       Хост: www.w3.org
 

за которым следует оставшаяся часть запроса. Обратите внимание, что абсолютный путь не может быть пустым; если его нет в исходном URI, он ДОЛЖЕН быть указывается как «/» (корневой каталог сервера).

Request-URI передается в формате, указанном в разделе 3. 2.1. Если Request-URI закодирован с использованием кодировки «% HEX HEX» [42], исходный сервер ДОЛЖЕН декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверы ДОЛЖНЫ отвечать на недопустимые Request-URI с соответствующим кодом состояния.

Прозрачный прокси НЕ ДОЛЖЕН перезаписывать часть «abs_path» полученный Request-URI при пересылке на следующий входящий сервер, кроме как указано выше, чтобы заменить null abs_path на «/».

 Примечание. Правило «без перезаписи» запрещает прокси-серверу изменять
      значение запроса, когда исходный сервер неправильно использует
      незарезервированный символ URI для зарезервированных целей. Разработчики
      следует знать, что некоторые прокси до HTTP/1.1, как известно,
      перепишите Request-URI.
 

5.2 Ресурс, идентифицируемый запросом

Точный ресурс, идентифицируемый интернет-запросом, определяется проверка как Request-URI, так и поля заголовка Host.

Исходный сервер, который не позволяет ресурсам различаться запрошенный хост МОЖЕТ игнорировать значение поля заголовка Host, когда определение ресурса, идентифицированного запросом HTTP/1.1. (Но см. раздел 19.6.1.1 для других требований к поддержке хоста в HTTP/1.1.)

Исходный сервер, который различает ресурсы в зависимости от хоста. запрошенный (иногда называемый виртуальным хостом или тщеславным хостом имена) ДОЛЖНЫ использоваться следующие правила для определения запрошенного ресурс по запросу HTTP/1.1:

1. Если Request-URI является absoluteURI, хост является частью Запрос-URI. Любое значение поля заголовка Host в запросе ДОЛЖНО быть игнорируется.

2. Если Request-URI не является absoluteURI и запрос включает поле заголовка Host, хост определяется заголовком Host значение поля.

3. Если хост, как определено правилом 1 или 2, не является допустимым хостом на сервер, ответ ДОЛЖЕН быть сообщением об ошибке 400 (Bad Request).

Получатели запроса HTTP/1.0, в котором отсутствует поле заголовка узла, МОГУТ попытка использовать эвристику (например, проверка пути URI для что-то уникальное для конкретного хоста), чтобы определить, что запрашивается точный ресурс.

5.3 Поля заголовка запроса

Поля заголовка запроса позволяют клиенту передавать дополнительные информацию о запросе и о самом клиенте сервер. Эти поля действуют как модификаторы запроса с семантикой. эквивалентно параметрам метода языка программирования призыв.

 заголовок запроса = Принять ; Раздел 14.1
 | Принять кодировку; Раздел 14.2
 | Принять кодировку ; Раздел 14.3
 | Принять-Язык ; Раздел 14.4
 | Авторизация ; Раздел 14.8
 | Ожидать                   ; Раздел 14.20
 | Из                     ; Раздел 14.22
 | Хозяин                     ; Раздел 14.
No related posts.