Генерация HTTP запросов


Оглавление (нажмите, чтобы открыть):

POST и GET запросы простыми словами. Генерация HTTP запросов

HTTP — протокол транспортировки гипертекста, один из протоколов стека TCP/IP. Изначально протокол был создан для передачи и получения HTML страниц, но сейчас он отлично используется для распределенных информационных систем. Это один из самых используемых протоколов во всемирной паутине.

Основан на схема запроса/ответа. Когда клиент отправляет запрос на сервер, он может это делать с помощью 3 видов запроса: GET, PUT и POST.

GET запрос протокола HTTP

GET — это клиентский запрос информации. Веб браузер клиента отправляет сообщение GET, чтобы взять страницы из него. Запрос имеет две части:

GET запрос не имеет тело данных, однако это не значит, что он не может передавать серверу никаких данных. С помощью специальных параметров в URL строке можно передавать серверу данные. Знак ? после домена в URL значит, что дальше будут передавать параметры. На рис.2 видно какую именно информацию передает браузер серверу.

POST и PUT запрос протокола HTTP

Эти два метода реализуют для того, чтобы отправлять информацию на веб сервер. К примеру с помощью специальных веб-форм заполнив их, мы отправляем их на сервер с помощью метода POST. PUT же загружает ресурсы или данные на веб сервер (картинка, видео).

HTTP не является безопасным протоколом, и сообщения POST можно перехватить и прочитать, так как оно не зашифровано. Для безопасности передачи данных с помощью метода POST, используют протокол HTTPS. Он шифрует данные и может проводить аутентификацию. Также он реализует дополнительные требования для прохождения информации между транспортным и прикладным уровнями.

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

На рис.3 видно основные правила, которым нужно следовать при выборе метода GET или POST для реализации работы на вашем сервере.

В последнее время я все более часто наблюдаю в основном форуме РНРClub вопросы на тему создания POST и GET запросов, а так же вопросы на тему: «Как мне посредством функции header сформировать POST запрос». Я считаю, что уже давно назрела необходимость расставить точки над «и» в использовании данной технологии, поскольку начинающие программисты просто не понимают принципов работы веба, как такового. Итак, начнем наше путешествие по миру протокола HTTP.

1. Протокол HTTP. Введение

Сразу хочу уточнить одну маленькую вещь. Страшное слово протокол есть не что иное, как соглашение множества людей, просто в один прекрасный момент люди решили: «Давайте будем делать так, и тогда все будет в порядке». Бояться нечего, все просто до безобразия и это безобразие мы сейчас будем вскрывать. Итак, что же это такое протокол HTTP и с чем его едят?

1.1 Клиент и сервер

Чудес в мире, а тем более в мире программизма и интернета не бывает! Усвойте это как незыблемую истину. И, если программа не работает или работает не так как хочется, то, значит, скорее всего, она либо написана не правильно, либо содержит ошибки. Итак, как же все-таки браузер просит сервер прислать ему хоть что-нибудь? Да очень просто! Надо только немного расслабиться и начать получать удовольствие от процесса:-)

1.2. Пишем наш первый HTTP запрос

Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается:-) Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру — надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:

GET https://www.php.net/ HTTP/1.0\r\n\r\n

  • GET (В переводе с английского означает «получить») — тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
  • https://www.php.net/ — URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
  • HTTP/1.0 — тип и версия протокола, который мы будем использовать в процессе общения с сервером.
  • \r\n — конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.

Вы можете выполнить данный запрос очень просто. Запустите программу telnet.exe, введите в качестве хоста www.php.net, укажите порт 80, и просто наберите данный запрос, нажав два раза Enter в качестве \r\n\r\n. В ответ вы получите HTML код главной страницы сайта www.php.net.

1.3 Структура запроса

Рассмотрим, из чего состоит HTTP запрос. Все достаточно просто. Начнем с того, что HTTP запрос — это вполне осмысленный текст. Из чего же он состоит в общем случае? Будем рассматривать протокол HTTP 1.0. Итак:

Request-Line [ General-Header | Request-Header | Entity-Header ]\r\n[ Entity-Body ]

    Request-Line — строка запроса

Формат: «Method Request-URI HTTP-Version\r\n»

  • Method — метод, которым будет обрабатываться ресурс Request-URI, может быть GET, POST, PUT, DELETE или HEAD.
  • Request-URI — относительная или абсолютная ссылка на страницу с набором параметров, например, /index.html или https://www.myhost.ru/index.html или /index.html?a=1&b=qq. В последнем случае серверу будет передан запрос с набором переменных a и b с соответствующими значениями, а знак «&» — амперсант служит разделителем между параметрами.
  • HTTP-Version — версия HTTP протокола, в нашем случае «HTTP/1.0».
  • Нам крайне интересны методы обработки GET и POST. Методом GET можно просто передать параметры в скрипт, а методом POST можно эмулировать submit формы.

    Для метода GET, Request-URI может выглядеть, например, так: «/index.html?param1=1&param2=2».

    • General-Header — главная часть заголовка.
      Формат:
      Может иметь только два параметра: Date или Pragma. Date — дата по Гринвичу в формате «День недели, Число Месяц Год ЧЧ:ММ:СС GMT», например, «Tue, 15 Nov 1994 08:12:31 GMT» — дата создания запроса. Pragma может иметь одно значение no-cache, которое запрещает кэширование страницы.
    • Request-Header — часть заголовка, описывающая запрос.

    Request-Header может иметь следующие параметры: Allow, Authorization, From, If-Modified-Since, Referer, User-Agent .
    В данной главе мы не будем рассматривать параметр Autorization, так как он используется для доступа к закрытым ресурсам, что требуется не так уж часто. Вы можете самостоятельно изучить формирование заголовка для авторизованного доступа на сайте www.w3c.org.

  • Allow — задает допустимые методы обработки.
    Формат: «Allow: GET | HEAD\n».
    Параметр игнорируется при указании метода обработки POST в Request-Line. Задает допустимые методы обработки запроса. Прокси сервера не модифицируют параметр Allow и он в неизменном виде доходит до сервера.
  • From — e-mail адрес, пославшего запрос.
    Формат: «From: adderss\r\n».
    Например, «From: [email protected]\r\n».
  • If-Modified-Since — указывает, что запрос не модифицировался с такого-то времени.
    Формат: «If-Modified-Since: date\r\n»
    Используется только для метода обработки GET. Дата указывается по Гринвичу в таком же формате, как и для параметра Date в General-Header.
  • Referrer — абсолютная ссылка на страницу, с которой произошла инициация запроса, т. е. ссылка на страницу, с которой пользователь перешел на нашу.
    Формат: «Referrer: url\n».
    Пример: «Referrer: www.host.ru/index.html\n».
  • User-Agent — тип браузера.
    Например: «User-Agent: Mozilla/4.0\n»
  • Entity-Header — часть заголовка, описывающая данные Entity-Body.
    В данной части запроса задаются параметры, которые описывают тело страницы. Entity-Header может содержать следующие параметры: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header .
  • Allow — параметр аналогичный Allow из General-Header.
  • Content-Encoding — тип кодирования данных Entity-Body.
    Формат: «Сontent-Encoding: x-gzip | x-compress | другой тип\n».
    Пример: «Сontent-Encoding: x-gzip\n». Символ «|» означает слово «или», то есть то или то или то и.т.д.
    Другой тип может указывать на способ кодирования данных, например, для метода POST: «Сontent-Encoding: application/x-www-form-urlencoded\n».
  • Content-Length — количество байт, пересылаемых в Entity-Body. Значение Content-Length имеет совсем другой смысл для данных, пересылаемых в формате MIME, где он выступает как параметр описания части данных — «external/entity-body». Допустимыми являются целые числа от нуля и больше.
    Пример: «Content-Length: 26457\n».
  • Content-Type — тип передаваемых данных.
    Например: «Content-Type: text/html\n».
  • Expires — Время, когда страница должна быть удалена из кэша браузера.
    Формат: «Expires: date\n». Формат даты алогичен формату даты для параметра Date из General-Header.
  • Last-Modified — время последнего изменения пересылаемых данных.
    Формат: «Last-Modified: date\n». Формат даты алогичен формату даты для параметра Date из General-Header.
  • Extention-header — часть заголовка, которая может предназначаться, например, для обработки браузером, или другой программой, которая принимает документ. В данной части можно описывать свои параметры в формате «ParameterName: parametervalue\n». Данные параметры будут игнорироваться, если программа-клиент не знает, как их обработать.
    Например: «Cookie: r=1\r\n» — устанавливает всем известные печеньки для страницы.
  • А теперь после таких страшных слов давайте попробуем немного успокоиться и понять, что же нам надо? Понимать мы естественно будем на примерах.

    Давайте представим, что нам надо получить страницу с сайта, передав Cookies (Печеньки), иначе нас просто пошлют как незванных гостей, и более того, известно, что на данную страницу пускают только после того, как Вы побывали на главной странице сайта.

    2 Метод GET

    Напишем наш запрос.

    GET https://www.site.ru/news.html HTTP/1.0\r\n
    Host: www.site.ru\r\n

    Cookie: income=1\r\n
    \r\n

    Данный запрос говорит нам о том, что мы хотим получить содержимое страницы по адресу https://www.site.ru/news.html, использую метод GET. Поле Host говорит о том, что данная страница находится на сервере www.site.ru, поле Referer говорит о том, что за новостями мы пришли с главной страницы сайта, а поле Cookie говорит о том, что нам была присвоена такая-то кука. Почему так важны поля Host, Referer и Сookie? Потому что нормальные программисты при создании динамических сайтов проверяют данные поля, которые появляются в скриптах (РНР в том числе) в виде переменных. Для чего это надо? Для того, например, чтобы сайт не грабили, т.е. не натравливали на него программу для автоматического скачивания, или для того, чтобы зашедший на сайт человек всегда попадал бы на него только с главной страницы и.т.д.

    Теперь давайте представим, что нам надо заполнить поля формы на странице и отправить запрос из формы, пусть в данной форме будет два поля: login и password (логин и пароль),- и, мы естественно знаем логин и пароль.

    GET https://www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0\r\n
    Host: www.site.ru\r\n
    Referer: https://www.site.ru/index.html\r\n
    Cookie: income=1\r\n
    \r\n

    Логин у нас «Petya Vasechkin» Почему же мы должны писать Petya%20Vasechkin? Это из=за того, что специальные символы могут быть распознаны сервером, как признаки наличия нового параметра или конца запроса и.т.д. Поэтому существует алгоритм кодирования имен параметров и их значений, во избежание оштбочных ситуаций в запросе. Полное описание данного алгоритма можно найти , а в PHP есть функции rawurlencode и rawurldecode для кодирования и декодирования соответственно. Хочу отметеить, что декодирование РНР делает сам, если в запросе были переданы закодированные параметры. На этом я закону первую главу знакомства c протоколом HTTP. В следуючей главе мы рассмотрим построение запросов типа POST (в переводе с английского — «отправить»), что будет гораздо интереснее, т.к. именно данный тип запросов используется при отправке данных из HTML форм.

    3. Метод POST.

    В случае HTTP запроса типа POST существует два варианта передачи полей из HTML форм, а именно, используя алгоритм application/x-www-form-urlencoded и multipart/form-data. Различия между данными алгоритмами весьма существенные. Дело в том, что алгоритм первого типа создавался давным-давно, когда в языке HTML еще не предусматривали возможность передачи файлов через HTML формы. Итак, давайте рассмотрим эти алгоритмы на примерах.

    3.1 Content-Type: application/x-www-form-urlencoded.

    Пишем запрос, аналогичный нашему запросу GET для передачи логина и пароля, который был рассмотрен в предыдущей главе:

    Host: www.site.ru\r\n
    Referer: https://www.site.ru/index.html\r\n
    Cookie: income=1\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    Content-Length: 35\r\n
    \r\n

    Здесь мы видим пример использования Content-Type и Content-Length полей заголовка. Content-Length говорит, сколько байт будет занимать область данных, которая отделяется от заголовка еще одним переводом строки \r\n. А вот параметры, которые раньше для запроса GET помещались в Request-URI, теперь находятся в Entity-Body. Видно, что они формируются точно также, просто надо написать их после заголовка. Хочу отметить еще один важный момент, ничто не мешает, одновременно с набором параметров в Entity-Body, помещать параметры с другими именами в Request-URI, например:

    POST https://www.site.ru/news.html?type=user HTTP/1.0\r\n
    .
    \r\n
    login=Petya%20Vasechkin&password=qq

    3.2 Content-Type: multipart/form-data

    Как только интернет мир понял, что неплохо бы было через формы отсылать еще и файлы, так W3C консорциум взялся за доработку формата POST запроса. К тому времени уже достаточно широко применялся формат MIME (Multipurpose Internet Mail Extensions — многоцелевые расширения протокола для формирования Mail сообщений), поэтому, чтобы не изобретать велосипед заново, решили использовать часть данного формата формирования сообщений для создания POST запросов в протоколе HTTP.

    Каковы же основные отличия этого формата от типа application/x-www-form-urlencoded?

    Главное отличие в том, что Entity-Body теперь можно поделить на разделы, которые разделяются границами (boundary). Что самое интересное — каждый раздел может иметь свой собственный заголовок для описания данных, которые в нем хранятся, т.е. в одном запросе можно передавать данные различных типов (как в Mail письме Вы одновременно с текстом можете передавать файлы).

    Итак, приступим. Рассмотрим опять все тот же пример с передачей логина и пароля, но теперь в новом формате.

    POST https://www.site.ru/news.html HTTP/1.0\r\n
    Host: www.site.ru\r\n
    Referer: https://www.site.ru/index.html\r\n
    Cookie: income=1\r\n

    Content-Length: 209\r\n
    \r\n
    —1BEF0A57BE110FD467A\r\n
    Content-Disposition: form-data; name=»login»\r\n
    \r\n
    Petya Vasechkin\r\n
    —1BEF0A57BE110FD467A\r\n
    Content-Disposition: form-data; name=»password»\r\n
    \r\n
    qq\r\n
    —1BEF0A57BE110FD467A—\r\n

    Теперь давайте разбираться в том что написано. 🙂 Я специально выделил некоторые символы \r\n жирным, чтобы они не сливались с данными. Присмотревшись внимательно можно заметить поле boundary после Content-Type. Это поле задает разделитель разделов — границу. В качестве границы может быть использована строка, состоящая из латинских букв и цифр, а так же из еще некоторых символов (к сожалению, не помню каких еще). В теле запроса в начало границы добавляется «—«, а заканчивается запрос — границей, к которой символы «—» добавляются еще и в конец. В нашем запросе два раздела, первый описывает поле login, а второй поле password. Content-Disposition (тип данных в разделе) говорит, что это будут данные из формы, а в поле name задается имя поля. На этом заголовок раздела заканчивается и далее следует область данных раздела, в котором помещается значение поля (кодировать значение не требуется!).

    Хочу обратить Ваше внимание та то, что в заголовках разделов не надо использовать Content-Length, а вот в заголовке запроса надо и его значение является размером всего Entity-Body, стоящего после второго \r\n, следующего за Content-Length: 209\r\n. Т.е. Entity-Body отделяется от заголовка дополнительным переводом строки (что можно заметить и в разделах).

    А теперь давайте напишем запрос для передачи файла.

    POST https://www.site.ru/postnews.html HTTP/1.0\r\n
    Host: www.site.ru\r\n
    Referer: https://www.site.ru/news.html\r\n
    Cookie: income=1\r\n
    Content-Type: multipart/form-data; boundary=1BEF0A57BE110FD467A\r\n
    Content-Length: 491\r\n
    \r\n
    —1BEF0A57BE110FD467A\r\n
    Content-Disposition: form-data; name=»news_header»\r\n
    \r\n
    Пример новости\r\n
    —1BEF0A57BE110FD467A\r\n
    Content-Disposition: form-data; name=»news_file»; filename=»news.txt»\r\n
    Content-Type: application/octet-stream\r\n
    Content-Transfer-Encoding: binary\r\n
    \r\n
    А вот такая новость, которая лежит в файле news.txt\r\n
    —1BEF0A57BE110FD467A—\r\n

    В данном примере в первом разделе пересылается заголовок новости, а во втором разделе пересылается файл news.txt. Внимательный да увидит поля filename и Content-Type во втором разделе. Поле filename задает имя пересылаемого файла, а поле Content-Type — тип данного файла. Application/octet-stream говорит о том, что это стандартный поток данных, а Content-Transfer-Encoding: binary говорит на о том, что это бинарные данные, ничем не закодированные.

    Очень важный момент. Большинство CGI скриптов написано умными людьми, поэтому они любят проверять тип пришедшего файла, который стоит в Content-Type. Зачем? Чаще всего закачка файлов на сайтах используется для получения картинок от посетителя. Так вот, браузер сам пытается определить что за файл посетитель хочет отправить и вставляет соответствующий Content-Type в запрос. Скрипт его проверяет при получении, и, например, если это не gif или не jpeg игнорирует данный файл. Поэтому при «ручном» формировании запроса позаботьтесь о значении Content-Type, чтобы оно было наиболее близким к формату передаваемого файла.

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

    4. Постскриптум.

    Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники:-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.

    Из выше сказанного, надеюсь теперь понятно, почему вопрос: «Как мне сформировать POST запрос, используя функцию header?» — бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.

    Есть еще один тип запросов — Content-Type: multipart/mixed, надеюсь после прочтения данной статьи Вы легко разберетесь с данным типом сами. Подробно изучить его можно

    Сейчас наиболее часто используются всего два HTTP метода: GET и POST. Но оказалось, что даже среди этих двух «сосен» веб разработчики умудряются теряться. Этому есть объяснение: оба метода можно использовать для получения одинакового результата. Но нужно помнить, что необдуманное применение какого-либо из методов может привести к плачевным последствиям, среди которых большие нагрузки на канал и дыры в безопасности.

    Чтобы этого избежать достаточно просто детальней разобраться в назначениях и различиях этих методов.

    Если вникнуть в значение названий методов, уже многое прояснится. GET (с англ. получать), т.е. следует применять для запроса данных. POST (c англ. отправлять по почте) — применяем для отправки данных на сервер. Вроде все предельно просто и понятно. Но кто желает разрабатывать сайты чуть сложнее сайта визитки с одной формой обратной связи, лучше с вопросом познакомиться поближе.

    Безопасные и небезопасные HTTP запросы

    Спецификация HTTP 1.1 вводит два понятия: безопасный и небезопасный запрос, или если быть более точным, метод.

    Безопасные — это методы, которые могут лишь запросить информацию. Они не могут изменить запрашиваемый ресурс, не могут привести к нежелательным результатам для пользователя, других лиц или сервера. Примерами безопасных есть запрос HTML кода веб страницы или изображения. К безопасным относятся методы HEAD и GET.

    Заметка

    В реальности умельцы конечно могут нанести вред и GET запросами. Например, зацикливаниями запросов.

    Небезопасные запросы, как уже все догадались, могут потенциально привести к нехорошим последствиям, если ими воспользоваться повторно. Такие запросы могут менять содержимое ресурса, к которому обращаются. Примеры таких запросов: отправка сообщений, регистрация, онлайн платежи. К небезопасным относятся методы POST, PUT, DELETE.

    Идемпотентнные (idempotent) методы

    Идемпотентность — свойство методов, которые при многочисленном повторном обращении вернут один и тот же результат, кроме случаев когда информация устарела. Это значит, что при обращении к одному и тому же URL все пользователи будут видеть одну и туже веб страницу, изображение, видео и т.п. Таким свойством обладают GET, PUT, DELETE методы.

    А теперь подробней о самих методах GET и POST: составим каждому короткое «резюме».

    • предназначен для получения данных с сервера;
    • тело запроса пустое;
    • обрабатываются на стороне сервера быстрее и с меньшим потреблением ресурсов сервера за счет пустого тела запроса;
    • передача переменных происходит в адресной строке (так видит пользователь, технически данные предаются в строке запроса) и поэтому видна информация о переменных и их значениях (данные не защищены);
    • способен передать небольшое количество данных на сервер: есть ограничения на длину URL, которое зависит от браузера, например, IE6 = 2Kb. На это число и рекомендуют ориентироваться разработчики Yahoo!;
    • может передать только ASCII символы;
    • такой запрос можно скопировать, сохранить (например, в закладках);
    • запрос может кэшироваться (этим можно управлять);
    • для дополнительного снижения нагрузки на канал и сервер доступны условные и частичные запросы;
    • не разрывает HTTP соединение (при включенном на сервере режиме keepAlive).
    • предназначен для отправления данных на сервер;
    • передача данных происходит в теле запроса;
    • обработка на стороне сервера медленнее и «тяжелее», чем GET, потому что помимо заголовков нужно анализировать тело запроса;
    • способен передать большие объемы данных;
    • способен передать файлы;
    • страницу, сгенерированную методом POST нельзя сохранить в закладки;
    • разрывает HTTP соединение;
    • для передачи даже очень малого объема информации большинством браузеров отправляет минимум два TCP пакета: заголовок, а потом тело запроса.

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

    Современные веб-ресурсы не просто предоставляют информацию посетителю, но и взаимодействуют с ним. Для взаимодействия с пользователем нужно получать некоторую информацию от него. Для получения данных есть несколько методов, очень распространенные методы GET и POST . И соответственно в PHP есть поддержка этих методов передачи данных GET и POST . Посмотрим, как работают эти методы.
    Метод GET Данные методом GET передаются путем их добавления к URL-адресу вызываемого сценария, предназначенного для обработки полученной информации. Для пояснения данного метода наберите в адресной строке браузера URL-адрес ресурса и добавьте сначала знак вопроса (? ), а затем строчку num=10 . Например

    Если у вас локальный сервер, то обычно домен будет localhost , и тогда предыдущая запись будет выглядеть

    В этом случае мы передаем параметр num равный 10. Для добавления следующих параметров сценарию нужно использовать разделитель — амперсант (& ), например

    Simple HTTP POST and GET Requests

    Category: Web Development Tools

    Version: 1.2.2 :: Last updated: 2020-02-20 —

    Changelog:

    • v 1.2.2
    • bug fixes and performance improvements
    • v 1.2.1
    • added monitoring ability
    • fixed huge bug which was preventing post requests from working
    • v 1.2.0
    • brand new, completely revamped UI
    • added named saved requests for logged in users
    • performance improvements and bug fixes
    • v 1.1.9
    • better display and management of recent requests from local storage
    • v 1.1.8
    • added ability to send raw POST requests with JSON, XML and plain text payloads
    • v 1.1.7

    • added ability to see the IP address from which the request will be sent
    • added history of previous requests in the sidebar through localStorage
    • v 1.1.6
    • added ability to test local endpoints
    • v 1.1.5
    • added ability to keep remote session active between requests
    • v 1.1.4
    • added ability to generate markdown docs and cURL replica of the request data
    • v 1.1.3
    • bug fix in pre-selecting request method on saved requests
    • added parsed responses for all requests
    • v 1.1.2
    • performance and other statistics for all requests
    • nice charts
    • v 1.1.1
    • added the ability to save and retrieve all requests done by a user if logged in
    • removed all ads and help section when logged in
    • added the ability to filter historic requests by endpoint
    • v 1.1.0
    • added the ability to test without captcha by logging in
    • added the ability to save failed requests
    • fixed a bug which was causing subsequent requests after a failed api call to fail
    • v 1.0.4
    • Added recaptcha to avoid spammers
    • v 1.0.3
    • Added the ability to save unique url for a particular request and reload it later
    • v 1.0.2
    • Added the ability to output request headers
    • v 1.0.1
    • Various bug fixes
    • v 1.0.0
    • Initial release

    RoadMap:

    • Available in v 1.3.0 — Deadline: End of September 2020
    • rewritten front-end as SPA with React
    • Available in v 1.4.0 — Deadline: End of December 2020
    • ability to generate docs by endpoint
    • Available in v 1.5.0 — Deadline: End of December 2020
    • add teams and ability to collaborate on projects

    This tool simplifies API testing and sending requests online. The application sends GET or POST HTTP requests to a specified API end-point. The application saves request parameters and results so that you can share them. To activate your personal url, just send a request and a new url will be generated for you.

    HTTP Requests Docs

    What is this for ?

    This tool is an HTTP Client. It is useful for people who want to execute GET or POST requests against an HTTP endpoint. POST requests can be sent as key-value url encoded pairs or as a raw string. If you combine the latter with the appropriate «Content-Type» header you can send «JSON» or «XML» in the POST payload.

    Can I use this to test local endpoints ?

    Yes you can. The «local» requests will be sent directly from the browser. In order to avoid CORS (cross origin) issues you will need to accept the codepunker.com domain as an authorized sender to your local server. To do that, you can add the following headers in your application:

    Because my website runs on https your local domain will need to run on https too — otherwise your local requests will fail because of mixed content. An alternative to this would be to run your local site on 127.0.0.1 which will be considered safe by most browsers.

    How can I keep my requests organised ?

    Once logged in, your saved requests will be automatically grouped by url. This way all queries to example.com/* will be grouped and they can be named for easy access. For people that are not logged in, the most recent requests are saved using your browser local storage. People that are not logged in must pass the captcha validation to send requests.

    What else can I do with this tool ?

    After executing the request the application will parse your query and data and create a cURL command that can be copied and executed from the command line.

    Saved requests can be monitored. Every 5 minutes, my servers will hit the saved endpoint with a simple get request or with the same parameters that you’ve defined and will report back if the response status code is anything other than 200 Success.

    Your entire requests history can be accessed when logged in and you can track performance over time with charts that display response times and status codes.

    Are there any limits on the number of requests that can be sent ?

    There is a hard limit of 240 requests per day per endpoint and IP Address. In other words one IP address can only send 240 requests per day to example.com.

    There must be a catch. What are you doing with my data ?

    I value your privacy, your data will never be sold or accessed by anyone other than you. Please read the privacy policy and terms and conditions.

    Генерация HTTP запросов

    GET запрос
    В руби есть класс Net::HTTP для генерации запросов. Парачку простеньких примеров расмотрим
    Для начала нужно подключить
    require ‘net/http’
    require ‘uri’

    1. Пример GET запроса
    Краткая форма:
    #урл запроса формируем

    url = «https://www.google.com.ua/search?as_q=test&hl=ru»
    uri = URI.parse(url)

    # посылаем запрос и получаем ответ, если все пройдет хорошо придет код 200 и ОК ( )

    Генерация HTTP-запросов

    Fetch или Axios.js

    В одном из заключительных разделов курса ES6 Javascript: The Complete Developer’s Gu >Udemy Стефан Гридер рассказывает о методе fetch() и о некоторых его недостатках. Он отмечает, что реализация fetch() не идеальна и предлагает другие варианты для выполнения HTTP-запросов. Один из таких вариантов — Axios. Раньше я даже не слышал об Axios и подумал, что подвернулась отличная возможность, чтобы немного покопаться и изучить его. Поскольку это ссылка на материал из курса Стивена, я использую похожие примеры.

    Мастер Йода рекомендует:  10 способов эффективно справиться с Null в Java

    Axios — это JavaScript-библиотека для выполнения либо HTTP-запросов в Node.js, либо XMLHttpRequests в браузере. Она поддерживает промисы — новинку ES6. Одна из особенностей, которая делает её лучше fetch() — автоматические преобразования JSON-данных.

    При использовании fetch() для передачи данных в JSON, необходимо выполнить процесс в два этапа. Сначала сделать фактический запрос, а затем вызвать метод json() для полученных данных с сервера.

    Обновление: по состоянию на 29 мая, Spotify теперь требует проверки подлинности для всех запросов к их API, поэтому примеры ниже не будут работать корректно.

    Вот простой пример c использованием API Spotify. Установим URL в качестве переменной и передадим её в fetch() . Затем установим колбэк, выводящий в консоль данные в качестве аргумента then() .

    Это конечно здорово, но это не те данные, которые мы бы хотели увидеть. Этот ответ сервера сообщил нам, что наш запрос прошел просто отлично. Круто, но мы больше не можем ничего с этим сделать.

    Чтобы получить данные, сперва нужно передать их в метод json() .

    Теперь это те данные, которые мы хотели получить. Попробуем реализовать это через Axios. Первый шаг — установка. Существует несколько вариантов установки:

    Либо npm, либо bower:

    Либо прямо с CDN:

    Затем, прямо в консоли, устанавливаем URL в качестве переменной и передаем его в метод axios.get() .

    Таким образом, с помощью Axios можно обойтись без передачи результатов HTTP-запроса в метод json() . Axios возвращает именно тот объект с данными, который мы ожидаем.

    Второй вопрос, который Стивен поднимает: как fetch() обрабатывает ответы на ошибки. Логически можно предположить, что если метод fetch() возвращает сообщение об ошибке, то управление переходит в блок catch() и ошибка обрабатывается там, верно? Не совсем. Вот пример.

    Изменим переменную url из предыдущих примеров на некорректную. Ожидается, что ошибка 400 из метода then() перейдёт в блок сatch() , но этого не происходит.

    Для наглядности выведем в консоль BAD в случае, если ошибка обрабатывается в блоке catch() , в противном случае выведем GOOD .

    Получаем код ответа 400 , но, как вы можете видеть по строке GOOD в консоли, выполнился then() . Как же Axios справляется с этим? Так, как мы и ожидали: выполняется блок сatch() и мы получаем необходимый нам вид ошибки.

    Строка BAD и ошибка выводятся в консоль.

    Метод fetch() — огромный шаг в развитии нативного JS в сторону взаимодействия с сервером. Но он имеет свои недостатки, которых можно избежать, используя сторонние библиотеками, такие как Axios.

    Примечания переводчика

    Метод fetch() по умолчанию не работает с куками. Для этого необходимо выставить значение credentials

    HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

    Тема 4: HTTP запрос: заголовки HTTP запроса, методы HTTP запроса, строка HTTP запроса, ресурсы HTTP запроса, примеры запросов

    Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи ты узнаешь всё что можно про запросы HTTP протокола. Для начала мы с тобой разберем структуру HTTP запроса, затем мы посмотрим, что собой представляет строка HTTP запроса, потом мы поговорим с тобой о методах HTTP запроса и ты узнаешь, собственно, что такое метод. Потом мы плавно перейдем к идентификаторам ресурса в HTTP запросе (Request-URI, если не совсем понятно), после чего мы с тобой разберем поля заголовков HTTP запроса и в конце этой записи мы с тобой разберем пару примеров HTTP запросов, которые, для закрепления прочитанного, ты можешь написать самостоятельно, как делает твой браузер, через который ты зашел на этот сайт.

    HTTP запрос: заголовки HTTP запроса, методы HTTP запроса, строка HTTP запроса, ресурсы HTTP запроса, примеры запросов

    Структура HTTP запроса

    Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. HTTP запрос – это HTTP сообщение, которое клиент посылает HTTP серверу. Обычно HTTP запрос содержит:

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

    Вот так выглядит общий синтаксис (общая структура HTTP запроса):

    В первой строке HTTP сообщения обычно содержится HTTP метод, который нужно применить к ресурсу, который запрашивает клиент, идентификатор ресурса (читай URI в HTTP) и версию HTTP протокола. Далее мы рассмотрим каждую часть HTTP запроса в отдельности и приведем пример HTTP запроса.

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

    Строка HTTP запроса начинается с маркера/метки метода, после которой следует URI запрашиваемого ресурса (если не понятно, читай про параметры HTTP протокола), версия HTTP протокола и символ CRLF, который означает конец строки HTTP запроса. Синтаксис строки HTTP запроса:

    Предлагаю рассмотреть в отдельности каждую часть строки HTTP запроса в отдельности.

    HTTP метод запроса

    Метод HTTP запроса указывает серверу, как нужно обращаться к запрашиваемому ресурсу, который указан в URI. Метод HTTP запроса чувствителен к регистру и его имя следует указывать только в верхнем регистре. Давайте перечислим все метода HTTP запроса, я сведу их в одну таблицу:

    Номер HTTP метод запроса и его описание
    1 GET

    Метод HTTP запроса GET используется для получения информации с сервера по указанному URI. HTTP запросы, использующие метод GET должны получать только данные и не должны оказывать никакого влияния на эти данные.

    2 HEAD

    Принцип работы метода HEAD в HTTP запросе аналогичен методу GET, но метод HEAD не передает тело сообщения (HTTP объект).

    3 POST

    HTTP запрос POST используется для отправки данных на HTTP сервер, например, когда вы заполняете HTML форму на сайте.

    4 PUT

    HTTP запросы с методом PUT сохраняются под запрашиваемым URI. То есть метод PUT используется для замены контента.

    5 DELETE

    Метод DELETE при HTTP запросе позволяет запросить сервер удалить данные ресурса, указанного в URI.

    6 CONNECT

    HTTP запрос с методом CONNECT позволяет установить туннель к серверу, который указан в URI.

    7 OPTIONS

    HTTP запрос с методом OPTION позволяет получить параметры для связи с ресурсом.

    8 TRACE

    При HTTP запросе с методом TRACE можно отследить то, что происходит с вашими запросами.

    Список методов, которые можно применить к ресурсу, может быть указан в поле заголовка Allow. HTTP сервер всегда должен возвращать код состояния ответа, чтобы сообщить клиенту: допустим метод или нет.

    URI HTTP запроса (Request-URI). Запрашиваемый URI

    URI HTTP запроса (Request-URI) или запрашиваемый URI для нас в большинстве случаев это обычный URL, который дает однозначное понимание HTTP серверу к какому ресурсу мы хотим обратиться:

    У URI, когда мы делаем HTTP запрос, есть три опции, которые зависят от характера запроса. Звездочка в предыдущем примере означает, что мы хотим обратиться не к какому-то ресурсу, а непосредственно к HTTP серверу. Такой способ допустим только в том случае, когда используемый метод HTTP запроса не обязательно обращается к ресурсу, например:

    absoluteURI URI необходим при HTTP запросе в том случае, когда HTTP запрос производится при помощи прокси-сервера. Прокси-сервер может передать этот запрос HTTP серверу, а может дать ответ из своего кэша, пример absoluteURI в HTTP запросе:

    Обращу ваше внимание на то, что в версии HTTP протокола 1.1 клиенты должны использовать absoluteURI только для обращений к прокси-серверам.

    Рассмотрим третий вид URI в HTTP запросе, наиболее общую и часто встречаемую форму Request-URI, данную форму Request-URI используют для идентификации ресурса на конечном HTTP сервере, при этом абсолютный путь URI передается в HTTP запросе, как Request-URI, а вот сетевое расположение ресурса передается в поле Host HTTP заголовка. Пример:

    Обратите внимание, что абсолютный путь не может быть пустым; если оригинальный URI пуст, то он должен запрашиваться как «/» (корневой каталог сервера). Первоначальный сервер должен декодировать Request-URI (кодирование в HTTP), чтобы правильно интерпретировать запрос. Серверам следует отвечать на недопустимые Request-URI соответствующим кодом состояния.

    В запросах, которые передаются далее, прокси-сервера никогда не должны перезаписывать часть «abs_path» запрашиваемого URI (Request-URI), за исключением случая, отмеченного выше, когда пустой abs_path заменяется на «*», независимо от внутренней реализации прокси-сервера.

    Первоначальные HTTP/1.1 сервера должны учитывать, что точный ресурс, идентифицированный интернет-запросом определяется как Request-URI, так и полем заголовка Host. Первоначальный сервер, который различает ресурсы, основанные на запрошенном хосте (иногда называемые виртуальными хостами или vanity hostnames) должен использовать следующие правила для определения запрошенного в HTTP/1.1 запросе ресурса:

    1. Если Request-URI — это absoluteURI, то хост — это часть Request-URI. Любое значение поля заголовка Host в запросе ДОЛЖНО игнорироваться (напомню про требования HTTP).
    2. Если Request-URI — не absoluteURI, а запрос содержит поле заголовка Host, то хост определяется значением поля заголовка Host.
    3. Если хоста, определенного правилами 1 или 2 не существует на сервере, код состояния ответа должен быть 400 (Испорченный Запрос, Bad Request).

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

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

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

    XMLHttpRequest POST, формы и кодировка


    Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

    Более новая информация по этой теме находится на странице https://learn.javascript.ru/xmlhttprequest.

    Во время обычной отправки формы

    Здесь есть два поля: name=Ivan и surname=Ivanov .

    Браузер перечисляет такие пары «имя=значение» через символ амперсанда & и, так как метод GET, итоговый запрос выглядит как /submit?name=Ivan&surname=Ivanov .

    Все символы, кроме английских букв, цифр и — _ . !

    * ‘ ( ) заменяются на их цифровой код в UTF-8 со знаком %.

    Например, пробел заменяется на %20 , символ / на %2F , русские буквы кодируются двумя байтами в UTF-8, поэтому, к примеру, Ц заменится на %D0%A6 .

    Будет отправлена так: /submit?name=%D0%92%D0%B8%D0%BA%D1%82%D0%BE%D1%80&surname=%D0%A6%D0%BE%D0%B9 .

    в JavaScript есть функция encodeURIComponent для получения такой кодировки «вручную»:

    Эта кодировка используется в основном для метода GET, то есть для передачи параметра в строке запроса. По стандарту строка запроса не может содержать произвольные Unicode-символы, поэтому они кодируются как показано выше.

    GET-запрос

    Формируя XMLHttpRequest, мы должны формировать запрос «руками», кодируя поля функцией encodeURIComponent .

    Например, для посылки GET-запроса с параметрами name и surname , аналогично форме выше, их необходимо закодировать так:

    Браузер автоматически добавит к запросу важнейшие HTTP-заголовки, такие как Content-Length и Connection .

    По спецификации браузер запрещает их явную установку, как и некоторых других низкоуровневых HTTP-заголовков, которые могли бы ввести в заблуждение сервер относительно того, кто и сколько данных ему прислал, например Referer . Это сделано в целях контроля правильности запроса и для безопасности.

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

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

    POST с urlencoded

    В методе POST параметры передаются не в URL, а в теле запроса. Оно указывается в вызове send(body) .

    В стандартных HTTP-формах для метода POST доступны три кодировки, задаваемые через атрибут enctype :

    • application/x-www-form-urlencoded
    • multipart/form-data
    • text-plain

    В зависимости от enctype браузер кодирует данные соответствующим способом перед отправкой на сервер.

    В случае с XMLHttpRequest мы, вообще говоря, не обязаны использовать ни один из этих способов. Главное, чтобы сервер наш запрос понял. Но обычно проще всего выбрать какой-то из стандартных.

    В частности, при POST обязателен заголовок Content-Type , содержащий кодировку. Это указание для сервера – как обрабатывать (раскодировать) пришедший запрос.

    Для примера отправим запрос в кодировке application/x-www-form-urlencoded :

    Всегда используется только кодировка UTF-8, независимо от языка и кодировки страницы.

    Если сервер вдруг ожидает данные в другой кодировке, к примеру windows-1251, то их нужно будет перекодировать.

    Кодировка multipart/form-data

    Кодировка urlencoded за счёт замены символов на %код может сильно «раздуть» общий объём пересылаемых данных. Поэтому для пересылки файлов используется другая кодировка: multipart/form-data.

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

    Чтобы использовать этот способ, нужно указать его в атрибуте enctype и метод должен быть POST:

    Форма при такой кодировке будет выглядеть примерно так:

    …То есть, поля передаются одно за другим, значения не кодируются, а чтобы было чётко понятно, какое значение где – поля разделены случайно сгенерированной строкой, которую называют «boundary» (англ. граница), в примере выше это RaNdOmDeLiMiTeR :

    Сервер видит заголовок Content-Type: multipart/form-data , читает из него границу и раскодирует поля формы.

    Такой способ используется в первую очередь при пересылке файлов, так перекодировка мегабайтов через urlencoded существенно загрузила бы браузер. Да и объём данных после неё сильно вырос бы.

    Однако, никто не мешает использовать эту кодировку всегда для POST запросов. Для GET доступна только urlencoded.

    POST с multipart/form-data

    Сделать POST-запрос в кодировке multipart/form-data можно и через XMLHttpRequest.

    Достаточно указать в заголовке Content-Type кодировку и границу, и далее сформировать тело запроса, удовлетворяющее требованиям кодировки.

    Пример кода для того же запроса, что и раньше, теперь в кодировке multipart/form-data :

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

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

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

    FormData

    Современные браузеры, исключая IE9- (впрочем, есть полифил), поддерживают встроенный объект FormData, который кодирует формы для отправки на сервер.

    Это очень удобно. Например:

    Этот код отправит на сервер форму с полями name , surname и patronym .

    • Конструктор new FormData([form]) вызывается либо без аргументов, либо с DOM-элементом формы.
    • Метод formData.append(name, value) добавляет данные к форме.

    Объект formData можно сразу отсылать, интеграция FormData с XMLHttpRequest встроена в браузер. Кодировка при этом будет multipart/form-data .

    Другие кодировки

    XMLHttpRequest сам по себе не ограничивает кодировку и формат пересылаемых данных.

    Поэтому для обмена данными часто используется формат JSON:

    Итого

    • У форм есть две основные кодировки: application/x-www-form-urlencoded – по умолчанию и multipart/form-data – для POST запросов, если явно указана в enctype . Вторая кодировка обычно используется для больших данных и только для тела запроса.
    • Для составления запроса в application/x-www-form-urlencoded используется функция encodeURIComponent .
    • Для отправки запроса в multipart/form-data – объект FormData .
    • Для обмена данными JS ↔ сервер можно использовать и просто JSON, желательно с указанием кодировки в заголовке Content-Type .

    В XMLHttpRequest можно использовать и другие HTTP-методы, например PUT, DELETE, TRACE. К ним применимы все те же принципы, что описаны выше.

    Как работает браузер: HTTP запрос

    В предыдущей статье рассмотрели схемы обмена данными между браузером и сервером с помощью HTTP протокола и его запросов. Теперь познакомимся ближе с самим HTTP запросом.

    Структура HTTP запроса

    Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

    1. строка запроса — указан метод запроса (HTTP-метод), URI, версия протокола;
    2. заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;
    3. тело сообщения — данные сообщения.

    Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом. Например, строка запроса может выглядеть так:

    Остановимся более подробно на методах запроса.

    Методы HTTP

    Метод указывает какая операция будет производится над ресурсом, представляет собой короткое английское слово, записанное заглавными буквами. Название метода чувствительно к регистру. В спецификации HTTP 1.1 определены следующие методы: OPTIONS, GET, HEAD, POST, PUT, PATCH, DELETE, TRACE, LINK, UNLINK. Чтобы не перегружать мозг избыточной информацией рассмотрим используемые чаще всего.

    Метод GET

    GET — используется для запроса содержимого указанного ресурса. Это с его помощью браузер получает HTML код конкретной страницы и все ее объекты (изображения, CSS и т.п). Тело такого запроса является пустым. Ответ может кэшироваться. GET запрос может передать параметры на сервер для уточнения запрашиваемых данных. Параметры запроса содержаться в адресе запроса, отделяются от URI знаком «?», пары параметр-значение разделяются символом « & ». Подобный адрес запроса может выглядеть так:

    Кроме обычных GET запросов, есть еще условные и частичные.

    Условный GET

    Условный GET запрос (conditional GET) предназначен для уменьшения ненужной загрузки сети, и позволяет обновлять кэшированные объекты без пересылки данных, уже сохраненных клиентом. Условный GET содержит в своем заголовке определенные условия и данные получает от сервера, только если ответ удовлетворяет запрашиваемым условиям. Спецификацией HTTP 1.1 определены условия: If-Modified-Since, If-Match, If-None-Match, If-Range. Наиболее часто ныне используется If-Modified-Since, которым задается дата и время последнего изменения объекта. При последующем обращении к данному ресурсу, браузер проверит значение этого заголовка, если он не изменился, объект возьмется из кэша клиента.

    Частичный GET

    Частичный GET запрос (partial GET) предназначен для уменьшения ненужной загрузки сети. Позволяет собирать объект из частей без передачи данных уже имеющихся на стороне клиента и потому запрашивает передачу только части объекта. Используется заголовок Range.

    Метод POST

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

    Заметка

    HTTP запросы можно разделить на безопасные (когда пользователь просто запрашивает данные и не может повлиять на работу сервера) и небезопасные (когда пользователь отправляет серверу определенные данные и потенциально может повлиять на его работу).

    URI и версия протокола

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

    Версия протокола служит для указания, с какой версией протокола способен работать клиент/сервер и выглядит в виде HTTP/[версия]. Сейчас большинство поддерживают версию 1.1.

    Заголовки HTTP

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

    Такой заголовок имеет вес равный 956b.

    Каждый ответ состоит из трех частей: строка состояния (содержит три поля: версию HTTP, код состояния и описание), заголовок ответа (информация о сервере и передаваемых данных) и сами данные. Первые две части представлены тоже в текстовом виде и выглядит это примерно так:

    Только первые две части в особо тяжелых случаях могут весить 0.5 килобайт.

    Это все к тому, что твой дополнительный однопиксельный gif на веб странице весом всего лишь 43 байта может вылиться в 130 с лишним мегабайт трафика при всего лишь 100 000 посетителях. Это еще одна причина для чего лучше сокращать число отдельных запросов к серверу.

    Заметка

    Вес передаваемых данных не влияет на размер заголовка.

    Установка HTTP заголовков

    Добраться до этих заголовков можно только с помощью настроек сервера и/или серверными скриптами.

    При первом запросе браузером объекта (HTML страницы, картинки или любого другого) сервер присылает ответ, содержащий HTTP заголовки. Клиент их сохраняет вместе с адресом запроса. При повтором обращении по этому адресу браузер уже будет снабжен необходимыми заголовками.

    Тело HTTP заголовка

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

    HTTP запросы GET, POST, PUT, DELETE, HEAD

    Запрос — это сообщение, посылаемое клиентом серверу.

    Существует два формата HTTP запроса:

    Запрос = Простой-Запрос | Полный-Запрос

    Простой-Запрос = «GET» SP Запрашиваемый-URI CRLF

    *(Общий-Заголовок | Заголовок-Запроса | Заголовок-Содержания ) CRLF

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

    Строка-Статус = Метод SP URI-Запроса SP Версия-HTTP CRLF

    поле Метод указывается метод, который должен быть применен к ресурсу, идентифицируемому URI-Запроса. Названия методов чувствительны к регистру. Существующий список методов может быть расширен.

    Метод = «GET» | «HEAD» | «PUT» | «POST» | «DELETE» | «LINK» | «UNLINK» | дополнительный-метод

    HEAD.

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

    28. Интерфейс servlet, класс HttpServlet

    Пакеты сервлетов определяют два абстрактных класса, которые реализуют интерфейс Servlet: класс GenericServlet (из пакета javax.servlet) и класс HttpServlet (из пакета javax.servlet.http). Эти классы предоставляют реализацию по умолчанию для всех методов интерфейса Servlet. Большинство разработчиков используют либо класс GenericServlet, либо класс HttpServlet, и замещают некоторые или все методы.

    Метод service, как правило, переопределяется, чтобы иметь возможность различать стандартные методы запросов, получаемые от Web-браузера клиента. Двумя наиболее распространенными типами запросов HTTP (их также называют методами запросов) являются get и post. Запрос get получает (или извлекает) информацию. Запрос post помещает (или отправляет) данные на сервер. Типичное применение метода post — отправка на сервер информации для аутентификации, или данных из формы, в которую пользователь ввел информацию.

    В классе HttpServlet определены методы doGet и doPost для реакции на запросы типа get и post клиента. Эти методы вызываются методом service класса HttpServlet, который, в свою очередь, вызывается при поступлении запроса на сервер. Методы doGet и doPost принимают в качестве параметров объекты HttpServletRequest и HttpServletResponse, которые дают возможность осуществлять взаимодействие между клиентом и сервером.

    · String getParameter(String name) Получение из запроса значения параметра. Наименование параметра определено значением name.

    · Enumeration getParameterNames() Получение из запроса имен всех параметров.

    · String[ ] getParameterValues(String name) Для параметра с несколькими значениями данный метод возвращает строковый массив.

    · Cookie[ ] getCookies () Получение массива объектов Cookie, сохраненных на компьютере клиента. Cookie могут быть использованы для уникальной идентификации клиента сервером.

    · HttpSession getSession(boolean create) Возвращает объект HttpSession текущего сеанса клиента. Если параметр create равен true и объект HttpSession не существует, то создается новый объект HttpSession.

    · void addCookie (Cookie cookie) Метод используется для добавления Cookie в заголовок ответа клинту. Установленный максимальный возвраст Cookie, а также разрешение клиентом хранения Cookie определяют, будут ли Cookies сохранены на клиенте и время их хранения.

    · ServletOutputStream getOutputStream() Получение бинарного потока вывода для отправления бинарных данных клиенту.

    · PrintWriter getWriter Получение символьного потока вывода для отправления текстовых данных клиенту.

    · void setContentType(String type) Определение MIME-типа ответа браузеру. MIME-тип помогает браузеру определить, как отображать данные. Например, MIME-тип «text/html» указывает, что ответ является HTML-документом, поэтому браузер отображает HTML-страницу.

    doDelete(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a DELETE request.

    doGet(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a GET request.

    doHead(HttpServletRequest req, HttpServletResponse resp)

    Receives an HTTP HEAD request from the protected service method and handles the request.

    doOptions(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a OPTIONS request.

    doPost(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a POST request.

    doPut(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a PUT request.

    doTrace(HttpServletRequest req, HttpServletResponse resp)

    Called by the server (via the service method) to allow a servlet to handle a TRACE request.

    Returns the time the HttpServletRequest object was last modified, in milliseconds since midnight January 1, 1970 GMT.

    service(HttpServletRequest req, HttpServletResponse resp)

    Receives standard HTTP requests from the public service method and dispatches them to the doXXX methods defined in this class.

    service(ServletRequest req, ServletResponse res)

    Dispatches client requests to the protected service method.

    29. Создание REST сервисов, JAX RS

    REST это архитектура, которая базируется на стандартах Web и на Http протоколе.

    Restfull сервисы основаны на методах HTTP (GET, PUT, POST, DELETE) и концепции REST.

    Шаг № 1 — Предварительный.

    Установите контейнер сервлетов (например, Tomcat 6), Maven и вашу любимую IDE.

    Шаг № 2 – Создание проекта.

    Надо создать Dynamic Web Project

    Шаг № 3 – Создать класс

    Создать Java-класс, который бы описывал методы Get, Put и т.д. для различных типов данных, чтобы обслуживать запросы к сервису.

    Затем надо зарегистрировать Jersy в качестве распределителя запросов для REST-запросов (для этого надо модифицировать файл web.xml).


    Шаг № 5 – Запустить службу.

    Шаг № 6 – Создать клиента.

    JAX-RS поддерживает автоматическое создание XML и JSON посредством JAXB.

    30. Связка JAXB и JAX RS, переключение типов возвращаемого контента (xml, json)

    JAX-RS поддерживает автоматическое создание XML и JSON посредством JAXB.

    // Get XML for application

    // Get JSON for application

    JSP

    JSP (JavaServer Pages) — технология, позволяющая веб-разработчикам легко создавать содержимое, которое имеет как статические, так и динамические компоненты. По сути, страница JSP является текстовым документом, который содержит текст двух типов: статические исходные данные, которые могут быть оформлены в одном из текстовых форматов HTML, SVG, WML, или XML, и JSP элементы, которые конструируют динамическое содержимое. Кроме этого могут использоваться библиотеки JSP тегов, а также EL (Expression Language), для внедрения Java-кода в статичное содержимое JSP-страниц.

    JSP — одна из высокопроизводительных технологий, так как весь код страницы транслируется в java-код сервлета с помощью компилятора JSP страниц Jasper, и затем компилируется в байт-код виртуальной машины java (JVM). Сервлет-контейнеры (Apache Tomcat), способные исполнять JSP страницы, написаны на платформонезависимом языке Java, который может работать под различными операционными системами и платформами. JSP страницы загружаются на сервере и управляются из структуры специального Java server packet, который называется Java EE Web Application, в большинстве своём упакованная в файловые архивы .war и .ear.

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

    JavaServer Pages (JSP) позволяют отделить динамическую часть страниц от статического HTML. Процедура довольно проста, создаёте обычный код HTML (статический), а динамическую часть заключаете в специальные теги » «.

    Имя вашего хоста:

    JSP страницы имеют расширение .jsp и размещаются там же, где и обычные Web страницы. Структура таких страниц может состоять из пяти конструкций: HTML, комментарии, скриптовые элементы, директивы и действия. JSP страница при компиляции преобразуется в обычный сервлет со статическим содержимым, которое направляется в поток вывода, связанный с методом service. Поэтому при первом запросе этот процесс может вызвать некую задержку, но в большинстве своём незаметную первому пользователю. Комментарии в документе или программе служат к объяснению содержимого. Они не являются причиной замедления программы, так как транслятор и исполнитель их игнорируют. Скриптовые элементы позволяют вам указать код на языке Java, который впоследствии станет частью конечного сервлета, директивы дадут вам возможность управлять всей структурой сервлета, а действия служат для задания существующих используемых компонентов, а также для контроля над поведением движка JSP. Для упрощения работы со скриптами имеются заранее определённые переменные, такие как request, response, pageContext, session, out, application, config, page, exception. Пример JSP страницы с использованием всех составляющих JSP конструкции:

    Cпецификация JSP различает три типа скриптовых элементов:

    Объявления обычно используются для определения переменных, методов, внутренних классов и остальных действующих Java конструкций на уровне класса. В выражения вкладываются любые действующие выражения Java. С помощью скриплетов в JSP страницы вкладываются работающие части кода Java. Все эти элементы начинаются знаками .

    JSP страница может послать сообщение соответствующему контейнеру с указаниями какие действия необходимо провести. Эти сообщения называются директивами. Все директивы начинаются с . Директивы в JSP странице приводят к тому, что контейнер пошлёт заявку на исполнение определённой службы, которая в генерированном документе не объявляется.

    Действия JSP используют конструкции с синтаксисом XML для управления работой движка сервлета. Вы можете динамически подключать файл, многократно использовать компоненты JavaBeans, направить пользователя на другую страницу или сгенерировать HTML для Java plugin.

    JSF

    JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE приложений. В отличие от прочих MVC фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP

    Технология JavaServer Faces включает:

    · Набор API для представления компонент пользовательского интерфейса (UI) и управления их состоянием, обработкой событий и валидацией вводимой информации, определения навигации, а также поддержку интернационализации (i18n) и доступности (accessibility).

    · Специальная библиотека JSP тегов для выражения интерфейса JSF на JSP странице.

    Призванная быть гибкой, технология JavaServer Faces усиливает существующие, стандартные концепции пользовательского интерфейса (UI) и концепции Web-уровня без привязки разработчика к конкретному языку разметки, протоколу или клиентскому устройству. Классы компонентов пользовательского интерфейса, поставляемые вместе с технологией JavaServer Faces, содержат функциональность компонент, а не специфичное для клиента отображение, открывая тем самым возможность рендеринга JSF-компонент на различных клиентских устройствах.

    33. Оптимизация JVM

    Оптимизация производительности Java

    Ниже перечислены основные особенности, влияющие на производительность программ на Java:

    · Для того чтобы при выполнении большого числа операций со строками избежать создания ненужных объектов, которые потом будет необходимо удалять, вместо конкатенации строк можно использовать StringBuffer.

    · Ограничтье число операций записи в консоль Java для снижения нагрузки при выполнении операций со строками, форматировнии текста и выводе данных.

    · По возможности создавайте объекты простых типов; это позволит ограничить использование системных ресурсов.

    · Заносите часто используемые объекты в кэш; это позволит уменьшить нагрузку на функцию сбора мусора и избежать многократного создания этих объектов.

    · Объединяйте в группы внутренние операции для снижения числа вызовов Java Native Interface (JNI), когда это возможно.

    · Для снижения числа процессов в JVM и операционной системе не применяйте синхронизированные методы без необходимости.

    · Инициируйте функцию сбора мусора только при необходимости. Запускать эту функцию рекомендуется только во время простоя или невысокой загруженности системы.

    · Используйте переменные типа int, а не long всегда, когда это возможно, потому что 32-разрядные операции выполняются быстрее, чем 64-разрядные.

    · Объявляйте методы как окончательные всегда, когда это возможно. В JVM такие методы обрабатываются быстрее.

    · Для снижения числа операций по объявлению переменных создавайте константы с ключевым словом static final.

    · Постарайтесь снизить число ссылок «cast» и «instanceof», поскольку соответствующие действия выполняются не при компиляции, а во время выполнения.

    · Во всех возможных ситуациях используйте массивы вместо векторов.

    · Для повышения производительсности добавляйте и удаляйте элементы из конца вектора.

    · Компилируйте программы на Java с опцией -O.

    JIT typically causes a slight delay in initial execution of an application, due to the time taken to load and compile the bytecode. Sometimes this delay is called «startup time delay». In general, the more optimization JIT performs, the better the code it will generate, but the initial delay will also increase. A JIT compiler therefore has to make a trade-off between the compilation time and the quality of the code it hopes to generate. However, it seems that much of the startup time is sometimes due to IO-bound operations rather than JIT compilation

    One possible optimization, used by Sun’s HotSpot Java Virtual Machine, is to combine interpretation and JIT compilation. The application code is initially interpreted, but the JVM monitors which sequences of bytecode are frequently executed and translates them to machine code for direct execution on the hardware. For bytecode which is executed only a few times, this saves the compilation time and reduces the initial latency; for frequently executed bytecode, JIT compilation is used to run at high speed, after an initial phase of slow interpretation. Additionally, since a program spends most time executing a minority of its code, the reduced compilation time is significant. Finally, during the initial code interpretation, execution statistics can be collected before compilation, which helps to perform better optimization.[2]

    The correct tradeoff can vary due to circumstances. For example, Sun’s Java Virtual Machine has two major modes—client and server. In client mode, minimal compilation and optimization is performed, to reduce startup time. In server mode, extensive compilation and optimization is performed, to maximize performance once the application is running by sacrificing startup time. Other Java just-in-time compilers have used a runtime measurement of the number of times a method has executed combined with the bytecode size of a method as a heuristic to decide when to compile.[3] Still another uses the number of times executed combined with the detection of loops.[4] In general, it is much harder to accurately predict which methods to optimize in short-running applications than in long-running ones.[5]

    Native Image Generator (Ngen) by Microsoft is another approach at reducing the initial delay.[6] Ngen pre-compiles (or «pre-jits») bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen on all of the Microsoft library DLLs right after the installation. Pre-jitting provides a way to improve the startup time. However, the quality of code it generates might not be as good as the one that is jitted, for the same reasons why code compiled statically, without profile-guided optimization, cannot be as good as JIT compiled code in the extreme case: the lack of profiling data to drive, for instance, inline caching.[7]

    There also exist Java implementations that combine an AOT (ahead-of-time) compiler with either a JIT compiler (Excelsior JET) or interpreter (GNU Compiler for Java.)

    Генерация HTTP запросов. Использование методов GET и POST

    Сегодня мне немного захотелось ударится в примитивные вещи и описать то, что можно найти во всемирной сети в большом количестве и без особых трудов. Речь пойдет практически о святая святых протокола HTTP: POST и GET запросах.

    Многие спросят зачем? Отвечу коротко и ясно: что это и зачем это нужно — знают далеко не все, а те кто хочет узнать об этом (при этом мало что понимая в it сфере) часто не могут понять то что пишут во многих и многих статьях посвященных данной теме. Я же постараюсь на пальцах объяснить что такое POST и GET запросы и с чем их едят.
    Итак, начнем наше путешествие в сказку…
    Если вы читаете данное сообщение, то Вы как минимум знаете как выглядит Интернет и что такое Интернет сайт. Опустив все тонкости работы всемирной паутины, будем оперироваться такими понятиями как пользователь и сайт. Как ни крути но эти два субъекта должны как-то взаимодействовать друг с другом. Вот люди, например, общаются между собой благодаря жестам, эмоциям и речи, животные издают какие-то звуки, а что же происходит при «общении» человека и Интернет ресурса? Здесь мы имеем случай обмена информацией, который можно перенести и на человеческий разговор плана «Вопрос-Ответ». Причем и вопросы и ответы могут задавать как и пользователь, так и сайт. Когда мы говорим о сайте, то его вопросы и ответы, как правило, всегда выражаются в виде Интернет страницы с тем или иным текстом. Когда же речь идет о пользователе, то тут все происходит благодаря GET и POST запросам (конечно не только, но мы говорим о них).

    Таким образом мы выяснили, что объекты нашей темы необходимы для «общения» с сайтами. Причем как и GET, так и POST запросы могут использоваться и для «задания вопросов» сайту и для «ответов». Чем же они отличаются? Все достаточно просто. Однако для объяснения различий, придется рассмотреть пример, в качестве которого возьмем сайт плана Интернет магазин.
    Наверное Вы часто обращали внимание, когда искали что-нибудь в онлайн магазинах, что прибегая к поиску по фильтрам, адрес сайта превращался из красивого «https://magaazin.ru» в страшный «https://magaazin.ru/?category=shoes&size=38». Так вот, все что идет после символа ‘?’ и есть Ваш GET запрос сайту, а если быть совсем точным, то в данном случае Вы как бы спрашиваете сайт, о том что у него есть в категории «Обувь» с размеров «38» (данный пример взят из головы, на деле все может выглядеть не так очевидно). В итоге мы имеем что вопросы мы можем задавать сами, путем указания их в строке адреса сайта. Очевидно, что данный метод имеет несколько недостатков. Во-первых, любой кто находится рядом с пользователем за компьютером, может спокойно подсмотреть все данные, поэтому использовать данный вид запросов для передачи паролей крайне не желательно. Во-вторых, есть ограничение на длину строки, которая может быть передана из поля адреса сайта, а значит особо много данных передать не получится. Однако несомненным плюсом использования GET запросов является его простота использования и возможность быстро спрашивать сайт, что особенно бывает полезно при разработке, но это уже другая история…
    Теперь поговорим о POST запросах. Догадливые читатели, возможно, смекнули, что главным отличаем данного запроса от его собрата — скрытность передаваемых данных. Если рассматривать Интернет магазин, то ярким примером где используется запрос POST — регистрация на сайте. Сайт спрашивает Ваши данные, Вы эти данные заполняете и при нажатии на кнопку «Регистрация» посылаете свой ответ. Причем никак внешне эти данные не отобразятся. Так же стоит отметить, что запрашивать могут достаточно большое количество информации — а значим ограничений POST запрос не имеет. Ну и если затронуть минус, то такой запрос быстро не сгенерируешь. Без специальных навыков, тут уже не обойтись. Хотя на самом деле все не так уж и сложно, но это опять же — другая история.
    Подведем небольшой итог. POST и GET запросы нужны для «общения» пользователя и сайта. Они по сути практически являются противоположностью друг друга. Использование тех или иных видов запросов зависит от конкретной ситуации и пользоваться только одним видом запроса крайне неудобно.

    Сейчас наиболее часто используются всего два HTTP метода: GET и POST. Но оказалось, что даже среди этих двух «сосен» веб разработчики умудряются теряться. Этому есть объяснение: оба метода можно использовать для получения одинакового результата. Но нужно помнить, что необдуманное применение какого-либо из методов может привести к плачевным последствиям, среди которых большие нагрузки на канал и дыры в безопасности.

    Чтобы этого избежать достаточно просто детальней разобраться в назначениях и различиях этих методов.

    Если вникнуть в значение названий методов, уже многое прояснится. GET (с англ. получать), т.е. следует применять для запроса данных. POST (c англ. отправлять по почте) — применяем для отправки данных на сервер. Вроде все предельно просто и понятно. Но кто желает разрабатывать сайты чуть сложнее сайта визитки с одной формой обратной связи, лучше с вопросом познакомиться поближе.

    Безопасные и небезопасные HTTP запросы

    Спецификация HTTP 1.1 вводит два понятия: безопасный и небезопасный запрос, или если быть более точным, метод.

    Безопасные — это методы, которые могут лишь запросить информацию. Они не могут изменить запрашиваемый ресурс, не могут привести к нежелательным результатам для пользователя, других лиц или сервера. Примерами безопасных есть запрос HTML кода веб страницы или изображения. К безопасным относятся методы HEAD и GET.

    Заметка

    В реальности умельцы конечно могут нанести вред и GET запросами. Например, зацикливаниями запросов.

    Небезопасные запросы, как уже все догадались, могут потенциально привести к нехорошим последствиям, если ими воспользоваться повторно. Такие запросы могут менять содержимое ресурса, к которому обращаются. Примеры таких запросов: отправка сообщений, регистрация, онлайн платежи. К небезопасным относятся методы POST, PUT, DELETE.

    Идемпотентнные (idempotent) методы

    Идемпотентность — свойство методов, которые при многочисленном повторном обращении вернут один и тот же результат, кроме случаев когда информация устарела. Это значит, что при обращении к одному и тому же URL все пользователи будут видеть одну и туже веб страницу, изображение, видео и т.п. Таким свойством обладают GET, PUT, DELETE методы.

    А теперь подробней о самих методах GET и POST: составим каждому короткое «резюме».

    • предназначен для получения данных с сервера;
    • тело запроса пустое;
    • обрабатываются на стороне сервера быстрее и с меньшим потреблением ресурсов сервера за счет пустого тела запроса;
    • передача переменных происходит в адресной строке (так видит пользователь, технически данные предаются в строке запроса) и поэтому видна информация о переменных и их значениях (данные не защищены);
    • способен передать небольшое количество данных на сервер: есть ограничения на длину URL, которое зависит от браузера, например, IE6 = 2Kb. На это число и рекомендуют ориентироваться разработчики Yahoo!;
    • может передать только ASCII символы;
    • такой запрос можно скопировать, сохранить (например, в закладках);
    • запрос может кэшироваться (этим можно управлять);
    • для дополнительного снижения нагрузки на канал и сервер доступны условные и частичные запросы;
    • не разрывает HTTP соединение (при включенном на сервере режиме keepAlive).
    • предназначен для отправления данных на сервер;
    • передача данных происходит в теле запроса;
    • обработка на стороне сервера медленнее и «тяжелее», чем GET, потому что помимо заголовков нужно анализировать тело запроса;
    • способен передать большие объемы данных;
    • способен передать файлы;
    • страницу, сгенерированную методом POST нельзя сохранить в закладки;
    • разрывает HTTP соединение;
    • для передачи даже очень малого объема информации большинством браузеров отправляет минимум два TCP пакета: заголовок, а потом тело запроса.

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

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

    Перейдите по следующему адресу (это для наглядного объяснения): https://calendarin.net/calendar.php?year=2020 Обратите внимание на адресную строку браузера: calendarin.net/calendar.php?year=2020 Основной файл называется, за ним следует вопросительный знак (?) и параметр «year» со значением «2020». Так вот, всё, что следует за вопросительным знаком, это и есть GET-запрос. Всё просто. Чтобы передать не один параметр, а несколько, то их нужно разделить амперсандом (&). Пример: calendarin.net/calendar.php?year=2020&display=work-days-and-days-off

    Основной файл всё также называется, за ним следует вопросительный знак (?), затем — параметр «year» со значением «2020», затем — амперсанд (&), затем — параметр «display» со значением «work-days-and-days-off».

    GET-параметры могут изменяться прямо в адресной строке браузера. Например, изменив значение «2020» на «2020» и нажав клавишу, вы перейдёте к календарю на 2020 год.

    Это передача данных скрытым способом (адрес страницы не изменяется); то есть увидеть, что было передано, можно только с помощью программы (скрипта). Например, в следующем инструменте для подсчёта символов в тексте исходные данные передаются методом POST: https://usefulonlinetools.com/free/character-counter.php

    Если остались вопросы, комментарии и мой E-mail к вашим услугам.

    Кроме метода GET, который мы рассмотрели в предыдущей заметке, существует еще один метод отправки запроса по протоколу HTTP – метод POST. Метод POST тоже очень часто используется на практике.

    Если, для того, чтобы обратиться к серверу методом GET, нам достаточно было набрать запрос в URL-адрес, то в методе POST все работает по другому принципу.

    Для того, чтобы выполнить этот вид запроса, нам необходимо нажать на кнопку с атрибутом type=»submit», которая расположена на веб-странице. Обратите внимание, что эта кнопка расположена в элементе

    Если пользователь введет в текстовое поле какой-либо текст и нажмет на кнопку «Отправить», то на сервер будет отправлена переменная text со значением того содержимого, которое ввел пользователь.

    POST и GET запросы простыми словами

    Эта переменная будет отправлена методом POST.

    Если в форме написать так:

    То данные будут отправляться методом GET.

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

    Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).

    Вот пример запроса, выполненного методом POST:

    POST / HTTP/1.0\r\n
    Host: www.site.ru\r\n
    Referer: https://www.site.ru/index.html\r\n
    Cookie: income=1\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    Content-Length: 35\r\n
    \r\n
    login=Dima&password=12345

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

    Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.

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

    Вот пример обработки на языке PHP:

    В прошлой заметке, мы определились с тем, что браузер (клиент) отправляет серверу HTTP запросы, а сервер отправляет клиенту HTTP ответы. Эти запросы и ответы оформляются по определенным правилам. Есть, что-то вроде синтаксиса, как и в какой последовательности, должно быть написано. Должна быть строго определенная структура.

    Давайте более подробно рассмотрим эту структуру, по которой строятся запросы и ответы в протоколе HTTP.

    HTTP запрос состоит из трех основных частей, которые идут в нем именно в том порядке, который указан ниже. Между заголовками и телом сообщения находится пустая строка (в качестве разделителя), она представляет собой символ перевода строки.

    Пустая строка (разделитель)

    Post и Get запросы, какая между ними разница и что лучше и для каких целей?

    тело сообщения (Entity Body) – необязательный параметр

    Строка запроса – указывает метод передачи, URL-адрес, к которому нужно обратиться и версию протокола HTTP.

    Заголовки – описывают тело сообщений, передают различные параметры и др. сведения и информацию.

    тело сообщения — это сами данные, которые передаются в запросе. Тело сообщения – это необязательный параметр и может отсутствовать.

    Когда мы получаем ответный запрос от сервера, тело сообщения, чаще всего представляет собой содержимое веб-страницы. Но, при запросах к серверу, оно тоже может иногда присутствовать, например, когда мы передаем данные, которые заполнили в форме обратной связи на сервер.

    Более подробно, каждый элемент запроса, мы рассмотрим в следующих заметках.

    Давайте, для примера, рассмотрим один реальный запрос к серверу. Я выделил каждую часть запроса своим цветом: строка запроса — зеленый, заголовки — оранжевый, тело сообщения- голубой.

    Запрос от браузера:

    В следующем примере уже присутствует тело сообщения.

    Content-Type: text/html; charset=UTF-8

    Документ без названия

    Вот такими сообщениями обмениваются клиент и сервер по протоколу HTTP.

    Кстати, хотите узнать есть ли смысл в каком-то элементе на вашем сайте с помощью «целей» Яндекс Метрики и Google Analytics?

    Уберите то, что НЕ работает, добавьте то, что работает и удвойте вашу выручку.

    Курс по настройке целей Яндекс Метрики..

    Курс по настройке целей Google Analytics..

    HTTP клиент посылает запрос на сервер в форме cсообщения-запроса, которое имеет следующий формат:

    • Строка запроса (обязательный элемент)
    • Заголовок (опционалный элемент)
    • Пустая строка (обязательный элемент)
    • Тело сообщения (опциональный элемент)

    Рассмотрим каждый из этих элементов по отдельности.

    Строка запроса начинается с токена метода, после которого следует URI запроса и версия протокола. Элементы отедляются друг от друга пробелами:

    Расмотрим данный элемент более подробно

    Данный элемент указывает метод, который должен быть вызван на стороне сервера по указанному индентификатору URI.

    В HTTP существует восемь методов:

    • HEAD
      Используется для получения строки статуса и заголовка от сервера по URI. Не изменяет данные.
    • GET
      Используется для получения данных от сервера по указанному URI. Не изменяет данные.
    • POST
      Используется для отправки данных на сервер (например информации о разработчике и т.д.) с помощью форм HTML.
    • PUT
      Замещает все предыдущие данные на ресурсе новыми загруженными данными.
    • DELETE
      Удаляет все текущие данные на ресурсе, определённом URI.
    • CONNECT
      Устанавливает туннельное соединение с сервером по указанному URI.
    • OPTIONS
      Описывает свойства соединения для указанного ресурса.
    • TRACE
      Предоставляет сообщение, содержащее обратный трейс расположения указанного в URI ресурса.

    URI (Uniform Resource Identifier) – это идентификатор ресурса на который отправляется запрос. Ниже приведён наиболее часто встречающийся формат URI:

    ‘*’ используется когда HTTP запрос не относится к конкретному ресурсу, но к серверу. Используется только в случае, когда метод не обязательно применять к ресурсу. Например,

    абсолютныйURI используется, когда HTTP запрос выполняется на прокси. Прокси запрашивается для передачи запроса из доступного кэша и возвращает ответ. Например:

    асболютный_путь | источник используется наиболее чатсо.

    Учимся работать с GET и POST запросами

    Запрашивается конкретный ресурс определённого сервера. Например, клиент хочет получить ресурс с сервера через 80-й порт. Адрес ресурса “www.proselyte.net” и отправляет следующий запрос:

    Запрос полей заголовка

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

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

    • Accept-Charset
    • Accept-Encoding
    • Accept-Language
    • Authorization
    • Expect
    • If-Match
    • If-Modified-Since
    • If-None-Match
    • If-Range
    • If-Unmodified-Since
    • Range
    • Referer
    • User-Agent

    Если мы заотим реализовать своего собственного клиента и свой собственный веб-сервер, то мы можем создавать собственные поля заголовка.

    Пример HTTP запроса

    На этом мы заканчиваем изучение запросов HTTP.
    В следующей статье мы рассмотрим HTTP ответы.

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


    Самый простой способ, как можно создать запрос методом GET- это набрать URL-адрес в адресную строку браузера.

    Браузер передаст серверу примерно следующую информацию:

    GET / HTTP/1.1
    Host: webgyry.info
    User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
    Accept-Encoding: gzip, deflate
    Cookie: wp-settings
    Connection: keep-alive

    Запрос состоит из двух частей:

    1. строка запроса (Request Line)

    2. заголовки (Message Headers)

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

    Различие между методами GET и POST

    Это можно делать с помощью специальных GET параметров.

    Чтобы добавить GET параметры к запросу, нужно в конце URL-адреса поставить знак «?» и после него начинать задавать их по следующему правилу:

    Разделителем между параметрами служит знак «&».

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

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

    Вот пример, как это можно сделать на PHP.

    Конструкция $_GET[«имя_параметра»] позволяет выводить значение переданного параметра.

    В результате выполнения этого кода в браузере выведется:

    Ваше имя: dima
    Ваш возраст: 27

    мы тоже выполняем запрос к серверу методом GET.

    Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

    Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницам а PHP просто расширяет возможности и того и другого.

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

    Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
    1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
    2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате «ключ»=»значение» и в качестве разделителя используется знак амперсанда (&)
    Пример:
    GET /index.php?name=Андрей&surname=Галкин
    это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
    3. $_POST заполняется другим способом. содержимое этого массива заполняется из «заголовков запроса». То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

    Чаще всего пост запрос используется в формах (для отправки данных).

    Например у нас есть форма для входа 2 поля логин и пароль.

    Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

    А вот если бы мы указали методом POST то мы бы получили следующий запрос:
    POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

    В общем подводя итог:
    GET — это чтобы получить определенную страницу в определенном виде (сортировка, текущая страница в блоге, строка поиска и т.п.).
    POST — для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта (логины, пароли, номера кредиток, сообщения и т.п.).

    Генерация HTTP запросов. Что такое HTTP запрос (HTTP сообщение)

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

    Все статьи из цикла:

    • Что такое Http заголовки. Общая теория.

    HTTP расшифровывается как HyperText Transfer Protocol (протокол передачи гипертекста). Протокол — это набор правил, по которым разные устройства обмениваются данными. Он был создан в 1990-х годах. Сейчас он используется в сети интернет практически повсеместно. Всё, что вы видите в окне браузера, было получено посредством этого протокола. http заголовки — пожалуй главная вещь в общении между устройствами. Они передают основную информацию об устанавливающемся соединении и о передаваемой информации через это соединение.
    Взглянем на схему общения двух устройств. Пусть этими устройствами будут ваш компьютер и какой-нибудь сервер в интернете:

    Как видно, браузер отослал http-запрос. Он может выглядеть примерно так:

    GET /other-19 HTTP/1.1 Host: www.scriptsite.ru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive

    При этом первая строка является строкой запроса, все остальные строки — это и есть http-заголовки, несущие в себе дополнительную информацию о запросе, о клиенте, который эту инфомрацию запрашивает, о многих других вещах.
    В ответ на наш запрос сервер может отослать такие заголовки:

    Server: Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.8k mod_dp20/0.99.2 PHP/5.2.5 mod_python/3.3.1 Python/2.5.1 mod_ruby/1.2.6 Ruby/1.8.6(2007-09-24)

    Cache-Control: no-store, no-cache, must-reval >

    Keep-Alive: timeout=10, max=1024

    Первая строка — строка статуса. Остальные строки — заголовки. В схеме было показано, что подгружается ещё и содержимое страницы. Но это содержимое обычно не принято отображать в плагинах, просматривающих заголовки. Да и содержимое страницы — это только частный случай. По протоколу же не обязательно страница должна передаваться. Вместо неё могут быть переданы и картинка, и звуковой файл, и видео. И у всех них заголовки будут сильно отличаться.

    Как увидеть http-заголовки?

    Для того, чтобы увидеть http-заголовки, я рекомендую следующие плагины для браузера firefox:

    Если вы пользуетесь браузером Chrome, просмотреть всю информацию можно, нажав на кнопку настройки — инструменты — инструменты разработчика. Вкладка networks.
    Пользователям браузера opera ничего посоветовать не могу, так как не дружу с этим браузером. Установив плагины и запустив их, попробуйте обновить страницу. Вы сразу же увидите огромные списки запросов и ответов, посредством которых ваш браузер общался с сервером.

    Http-заголовки и доступ к ним в php

    Если вы являетесь php-разработчиком, вы можете получить доступ к заголовкам запроса с помощью функции getallheaders() . Для понимания её работы выполним такой код:

    И мы получаем распечатку массива заголовков.

    Но чаще к ним обращаются через глобальную переменную $_SERVER. Почти для каждого http заголовка есть аналогичное название элемента в этой переменной, образуемого по принципу HTTP_имя_заголовка. Так для того же ‘User_Agent’ есть переменная $_SERVER[‘HTTP_USER_AGENT’];

    Для получения заголовков, которые сервер собирается отправить пользователю, используется функция headers_list() . Как правило, сервер составляет недостающие обязательные заголовки уже в конце работы всех скриптов. Поэтому этот массив будет содержать заголовки либо те, которые сервер создал перед началом выполнения скрипта (и они не будут изменены), либо те, которые мы установили вручную. Вручную их можно установить с помощью функции header(«текст заголовка»);
    Выполним такой код:

    Увидим распечатку готовых к отправке на момент вызова функции заголовков:

    Первый заголовок был установлен автоматически, и он несёт в себе название сервера, на котором выполняется скрипт. Второй — установленный нами вручную. Если бы браузеру нужен был заголовок «Фрукт», он бы взял его из http-ответа сервра и использовал. Но так как наш браузер не нуждается в нём, то он просто игнорирует непонятную ему строку.

    Структура http запроса

    Наш запрос выглядит следующим образом:

    Первая строка в нём, как уже было сказано раньше, является строкой запроса. Она состоит из трёх частей:

    • method (метод) — указывает, какого рода запрос. Самые распространённые методы: GET, POST, HEAD. О них будет написано в следующем параграфе.
    • path (путь) — как правило, это часть URL, идущая после домена. Например, если вы вводите в адресную строку https://www.scriptsite.ru/about/, значение path будет /about/.
    • protocol (протокол) — используемый протокол. Как правило, состоит из «HTTP» и версии протокола. Обычно, в современных браузерах используется версия 1.1

    Дальше идут заголовки в виде строк формата «Имя: значение».
    Кстати, данные о cookies также передаются в этом запросе в виде одного из заголовков. Большинство из этих строк не являются обязательными. Запрос может быть сокращён вообще до двух строк:

    GET /article/show/4/ HTTP/1.1

    Методы запроса

    get-запрос обычно используется для запроса документа с передачей некоторых параметров.
    Это основной метод, используемый для получения html-страниц, изображений, CSS и JavaScript файлов, и т.д.
    Из-за того, что параметры могут быть любыми, а на сервере нет ограничений по способам их обработки, часто метод для запросов данных используют для передачи информации. Например, у нас будет такая форма

    При этом эти параметры будут видны в адресной строке браузера.

    Post — метод, используемый для отправки данных на сервер. Несмотря на то, что вы можете отправлять данные серверу методом GET через адресную строку браузера, в большинстве случаев предпочтительнее использовать POST. Отправлять большие объёмы данных через GET непрактично. К тому же GET имеет некоторые ограничения, не позволяющие, например, опубликовать эту статью на моём сайте через одну лишь строку браузера. POST запросы чаще всего используются для передачи web-форм. Давайте изменим форму из предыдущего примера, задав ей метод POST

    Заголовки Content-Type и Content-Lenght добавлены автоматически. Они содержат информацию о типе и размере данных.
    Все данные передаются после отправки заголовков в таком же виде, как в строке запроса GET

    Метод POST повсеместно используется в AJAX, cURL, и т.д.
    Формы загрузки файлов работают только через метод POST

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

    Структура http ответа

    Сервер отвечает на каждый запрос такими ответами:

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

    К информации о статусах можно ещё добавить факт об ошибке 404. Её название пошло именно из кода 404, который отсылает сервер, когда не может найти файл на своих дисках.
    Более подробно о статусах сервера написано в следующей статье.

    Обратите также внимание

    При этом возможны два способа организации работы компьютера-клиента:

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

    Прежде чем перейти к конкретным клиент-серверным веб-технологиям, рассмотрим основные принципы и структуру базового протокола HTTP .

    Протокол HTTP

    HTTP (HyperText Transfer Protocol — RFC 1945, RFC 2616) — протокол прикладного уровня для передачи гипертекста.

    Центральным объектом в HTTP является ресурс , на который указывает URL в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя изначально данный протокол предназначен для передачи символьной информации. На первый взгляд это может показаться излишней тратой ресурсов. Действительно, данные в символьном виде занимают больше памяти, сообщения создают дополнительную нагрузку на каналы связи, однако подобный формат имеет много преимуществ. Сообщения, передаваемые по сети, удобочитаемы, и, проанализировав полученные данные, системный администратор может легко найти ошибку и устранить ее. При необходимости роль одного из взаимодействующих приложений может выполнять человек, вручную вводя сообщения в требуемом формате.

    В отличие от многих других протоколов, HTTP является протоколом без памяти. Это означает, что протокол не хранит информацию о предыдущих запросах клиентов и ответах сервера. Компоненты, использующие HTTP , могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Например, клиентское веб- приложение , посылающее запросы, может отслеживать задержки ответов, а веб- сервер может хранить IP-адреса и заголовки запросов последних клиентов.

    Все программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:

    • Серверы — поставщики услуг хранения и обработки информации (обработка запросов).
    • Клиенты — конечные потребители услуг сервера (отправка запросов).
    • Прокси-серверы для поддержки работы транспортных служб.

    Основными клиентами являются браузеры , например: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator и другие. Наиболее популярными реализациями веб-серверов являются: Internet Information Services ( IIS ), Apache, lighttpd, nginx. Наиболее известные реализации прокси-серверов: Squid, UserGate, Multiproxy, Naviscope.

    «Классическая» схема HTTP -сеанса выглядит так.

    1. Установление TCP-соединения.
    2. Запрос клиента.
    3. Ответ сервера.
    4. Разрыв TCP-соединения.

    Таким образом, клиент посылает серверу запрос , получает от него ответ, после чего взаимодействие прекращается. Обычно запрос клиента представляет собой требование передать HTML -документ или какой-нибудь другой ресурс , а ответ сервера содержит код этого ресурса.

    В состав HTTP -запроса, передаваемого клиентом серверу, входят следующие компоненты.

    • Строка состояния (иногда для ее обозначения используют также термины строка-статус, или строка запроса).
    • Поля заголовка.
    • Пустая строка.
    • Тело запроса.

    Строку состояния вместе с полями заголовка иногда называют также заголовком запроса .

    Строка состояния имеет следующий формат:

    метод_запроса URL_pecypca версия_протокола_НТТР

    Рассмотрим компоненты строки состояния, при этом особое внимание уделим методам запроса.

    Метод , указанный в строке состояния, определяет способ воздействия на ресурс , URL которого задан в той же строке. Метод может принимать значения GET , POST , HEAD , PUT , DELETE и т.д. Несмотря на обилие методов, для веб-программиста по-настоящему важны лишь два из них: GET и POST .

    • GET . Согласно формальному определению, метод GET предназначается для получения ресурса с указанным URL. Получив запрос GET , сервер должен прочитать указанный ресурс и включить код ресурса в состав ответа клиенту. Ресурс, URL которого передается в составе запроса, не обязательно должен представлять собой HTML-страницу, файл с изображением или другие данные. URL ресурса может указывать на исполняемый код программы, который, при соблюдении определенных условий, должен быть запущен на сервере. В этом случае клиенту возвращается не код программы, а данные, сгенерированные в процессе ее выполнения. Несмотря на то что, по определению, метод GET предназначен для получения информации, он может применяться и в других целях. Метод GET вполне подходит для передачи небольших фрагментов данных на сервер.
    • POST . Согласно тому же формальному определению, основное назначение метода POST — передача данных на сервер. Однако, подобно методу GET , метод POST может применяться по-разному и нередко используется для получения информации с сервера. Как и в случае с методом GET , URL, заданный в строке состояния, указывает на конкретный ресурс. Метод POST также может использоваться для запуска процесса.
    • Методы HEAD и PUT являются модификациями методов GET и POST.

    Версия протокола HTTP , как правило, задается в следующем формате:

    Поля заголовка , следующие за строкой состояния, позволяют уточнять запрос , т.е. передавать серверу дополнительную информацию. Поле заголовка имеет следующий формат:

    Назначение поля определяется его именем, которое отделяется от значения двоеточием.

    Имена некоторых наиболее часто встречающихся в запросе клиента полей заголовка и их назначение приведены в таблице 2.1 .

    Таблица 2.1. Поля заголовка запроса HTTP.

    Поля заголовка HTTP -запроса Значение
    Host Доменное имя или IP-адрес узла, к которому обращается клиент
    Referer URL документа, который ссылается на ресурс, указанный в строке состояния
    From Адрес электронной почты пользователя, работающего с клиентом
    Accept MIME-типы данных, обрабатываемых клиентом. Это поле может иметь несколько значений, отделяемых одно от другого запятыми. Часто поле заголовка Accept используется для того, чтобы сообщить серверу о том, какие типы графических файлов поддерживает клиент
    Accept-Language Набор двухсимвольных идентификаторов, разделенных запятыми, которые обозначают языки, поддерживаемые клиентом
    Accept-Charset Перечень поддерживаемых наборов символов
    Content-Type MIME-тип данных, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Content-Length Число символов, содержащихся в теле запроса (если запрос не состоит из одного заголовка)
    Range Присутствует в том случае, если клиент запрашивает не весь документ, а лишь его часть
    Connection Используется для управления TCP-соединением. Если в поле содержится Close, это означает, что после обработки запроса сервер должен закрыть соединение. Значение Keep-Alive предлагает не закрывать TCP-соединение, чтобы оно могло быть использовано для последующих запросов
    User-Agent Информация о клиенте

    Во многих случаях при работе в Веб тело запроса отсутствует. При запуске CGI-сценариев данные, передаваемые для них в запросе, могут размещаться в теле запроса.

    HTTP (англ. Hyper Text Transfer Protocol – «протокол передачи гипертекста») — протокол передачи данных прикладного уровня, разработанный специально для обмена информацией между веб-сайтом и пользовательским агентом (браузером). Это один из тех стандартов, на которых основан весь World Wide Web. Взаимодействие поисковых систем с сайтами также проходит в рамках протокола HTTP .

    Бессмысленно полностью и в деталях пересказывать здесь содержание RFC — ниже даны ссылки для подробного ознакомления. Здесь изложен только минимум, необходимый для понимания процесса обмена информацией в рамках протокола.

    О терминах

    Многие термины могут пониматься в разных смыслах. Необходимо сразу договориться, в каком смысле употребляется в этой статье тот или другой термин.

    Веб-сервер (сервер) — не компьютер, стоящий в датацентре, а исполняемая на этом компьютере программа, которая принимает запросы и отправляет запрошенные документы.
    Пользовательский агент (клиент, User-agent) — программа, посылающая запросы веб-серверу и получающая от него документы. Это может быть ваш браузер, а может быть и сканирующий бот поисковой системы.
    Документ — любая отдельная единица информации, имеющая свой адрес в домене. По умолчанию подразумевается HTML -страница, но документами также считаются файлы рисунков, CSS , Java-скриптов и т.п.

    Порядок обмена информацией

    В HTTP предусмотрено всего два типа сообщений: запрос клиента и ответ сервера. Клиент шлет серверу запрос, указывая имя домена и адрес внутри домена, по которому должен находиться нужный документ. Сервер принимает сообщение, ищет документ (или запускает скрипт, которым этот документ генерируется) и при успешном завершении отправляет ответное сообщение.
    Структура этих сообщений одинакова:

    Стартовую строку и строки заголовков часто называют вместе «заголовком запроса» (или ответа).
    Пример стартовой строки запроса:

    GET /index.php HTTP/1.1

    Передан метод запроса (GET), адрес документа внутри домена и версия протокола, которая используется.
    Пример стартовой строки ответа:

    Передана версия протокола, числовой код статуса (200) и расшифровка статуса (OK).

    Заголовки

    В заголовках запроса передается дополнительная информация, которая может влиять на дальнейший обмен сообщениями. Обязательно передается имя домена, из которого запрашивается документ. Также может передаваться ожидаемый медиатип документа, возможность приема в сжатом формате, ожидаемый язык для текстовых документов, название пользовательского агента, отправившего запрос. В заголовке могут также передаваться условия запроса. Например, If-Modified-Since: [метка времени] — запрашивается документ при условии, что его содержание изменилсь со времени, указанного в заголовке.

    В заголовке ответа также передается дополнительная информация — название сервера, текущее время, медиатип и кодировка передаваемого документа, возможно и другие данные (язык для текстовых документов, дата модификации, размер в байтах и т.д.). Все это — сопроводительная информация к документу, который будет передан после заголовков (в теле сообщения), если запрос выполнен успешно.

    При невозможности передачи документа код статуса в сообщении сервера соответствует характеру ошибки, а вместо тела документа передается специальная HTML -страница с текстом сообщения об ошибке. Обратите внимание, что статус ошибки не мешает браузеру отобразить эту страницу.

    Методы запроса

    Протоколом в редакции RFC 2616 описано восемь методов для обращения к серверу. Но на сегодняшний день не все они реализованы для большинства веб-серверов, а обязательными к реализации признаны только два. Основные методы, которые нас интересуют и поддерживаются практически всеми веб-серверами — это GET, HEAD и POST.

    Метод GET

    Это самый обычный метод запроса для получения веб-страницы или другого документа. В ответ на этот запрос сервер должен отыскать (или сформировать) документ и при успешном завершении отправить его клиенту.
    Формат запроса:

    GET HTTP[версия протокола]

    Метод HEAD

    Этот метод аналогичен GET, но с одним отличием: в ответ на запрос HEAD сервер выполняет поиск (или формирование документа), но отправляет только заголовки ответа, не передавая тело сообщения. Таким способом можно проверить существование или доступность документа по данному адресу, получить всю информацию о документе, передаваемую в заголовках, не получая сам документ.
    Формат запроса:

    HEAD HTTP[версия протокола]

    Тело сообщения в запросе отсутствует.

    Метод POST

    Этот метод предназначен для передачи данных на сервер — например, данные, введенные в форму, обычно передаются методом POST.
    Формат запроса:

    POST HTTP[версия протокола]

    Поле [ URI ] содержит адрес скрипта-обработчика формы, который принимает и обрабатывает данные. В теле сообщения передаются данные, введенные в поля формы в виде [имя_поля=введенное_значение].

    Коды статуса

    Коды статуса (состояния) отображают результат обработки запроса сервером. Код представлен трехзначным десятичным числом, старший разряд которого указывает на класс ответа. Таким образом, под каждый класс ответов зарезервировано до ста разных кодов статуса. Всего определено пять классов:

    1xx: Informational — информационный

    Коды от 100 до 199, входящие в этот класс, информируют клиента, что запрос получен. Сообщения с такими статусами содержат только стартовую строку и (если нужно) заголовки, но не содержат тело сообщения. Отправлять что-либо в ответ на это клиент не должен.

    2xx: Success — успешно

    Сообщения этого класса означают, что запрос успешно получен, интерпретирован и обработан. Из этих кодов статуса нас интересует только 200 «OK» — признак нормального завершения, после которого в теле сообщения клиенту пересылается запрошенный документ.

    HTTP — это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

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

    Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol — HTTP/1.1.

    Основы HTTP

    HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

    В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

    Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

    Текущая версия протокола HTTP — 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

    Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

    Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию — 80. Далее следует путь к ресурсу на сервере и цепочка параметров.

    Методы

    С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.

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

    POST : используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

    PUT : обновить текущий ресурс. PUT запрос содержит обновляемые данные.

    DELETE : служит для удаления существующего ресурса.

    Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

    Также HTTP поддерживает и другие методы:

    HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

    TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

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

    Коды состояния

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

    1xx: Информационные сообщения

    Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

    2xx: Сообщения об успехе

    Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

    • 202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
    • 204 No Content : в теле ответа нет сообщения.
    • 205 Reset Content : указание серверу о сбросе представления документа.
    • 206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

    Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.

    • 301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
    • 303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
    • 304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Enttity Tag);

    4xx: Клиентские ошибки

    Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

    • 400 Bad Request : вопрос был сформирован неверно.
    • 401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
    • 403 Forbidden : сервер не открыл доступ к ресурсу.
    • 405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
    • 409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

    5xx: Ошибки сервера

    Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

    • 501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
    • 503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

    Форматы сообщений запроса/ответа

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

    Давайте посмотрим на структуру передаваемого сообщения через HTTP:

    Message = *( ) CRLF [ ] = Request-Line | Status-Line = Field-Name «:» Field-Value

    Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

    Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

    Общие заголовки

    Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

    General-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

    Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

    Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

    Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

    Заголовок Date используется для хранения даты и времени запроса/ответа.

    Заголовок Upgrade используется для изменения протокола.

    Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

    Заголовки сущностей

    В заголовках сущностей передаётся мета-информация контента:

    Entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified

    Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

    Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

    С помощью данных заголовков, можно задать нужную для ваших задач информацию.

    Формат запроса

    Запрос выглядит примерно так:

    Request-Line = Method SP URI SP HTTP-Version CRLF Method = «OPTIONS» | «HEAD» | «GET» | «POST» | «PUT» | «DELETE» | «TRACE»

    SP — это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

    GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

    Список возможных заголовков запроса:

    Request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent

    В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

    Формат ответа

    Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

    • HTTP версия
    • Код статуса
    • Сообщение статуса, понятное для человека

    Обычный статус выглядит примерно так:

    Заголовки ответа могут быть следующими:

    Response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate

    • Age время в секундах, когда сообщение было создано на сервере.
    • ETag MD5 сущности для проверки изменений и модификаций ответа.
    • Location используется для перенаправления и содержит новый URL адрес.
    • Server определяет сервер, где было сформирован ответ.

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

    Инструменты для определения HTTP трафика

    Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

    Наиболее часто используемый — это Chrome Developers Tools:

    Если говорить об отладчике, можно воспользоваться Fiddler :

    Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

    Библиотеки для работы с HTTP — jQuery AJAX

    Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

    Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

    Если хотите обработать статус запроса, то это можно сделать так:

    Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.

    HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) был разработан как основа World Wide Web.

    Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

    Структура HTTP-запроса

    HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.

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

    Запрос в главной строке состоит из трех частей, разделенных пробелами:

    Метод (иначе говоря, команда HTTP):

    GET — запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

    HEAD — запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

    POST — этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

    PUT — разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

    Ресурс — это путь к определенному файлу на сервере, который клиент хочет получить (или разместить — для метода PUT). Если ресурс — просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

    Версия протокола -версия протокола HTTP, с которой работает клиентская программа.

    Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

    Здесь запрашивается корневой файл из корневой директории web-сервера.

    Строки после главной строки запроса имеют следующий формат:

    Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Keep-Alive).

    Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

    Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive («оставить в живых») означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером «скачать» html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
    close («закрыть») — соединение закрывается после ответа на данный запрос.

    User-Agent — значением является «кодовое обозначение» браузера, например:

    Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

    Accept — список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

    Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

    Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

    Referer — URL, с которого перешли на этот ресурс.

    Host — имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

    Accept-Language — поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

    Формат HTTP-ответа

    Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

    Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

    Основная строка запроса состоит из 3-х полей, разделенных пробелами:

    Версия протокола — аналогичен соответствующему параметру запроса.

    Код ошибки — кодовое обозначение «успешности» выполнения запроса. Код 200 означает «все нормально» (OK).

    Словесное описание ошибки — «расшифровка» предыдущего кода. Например для 200 это OK, для 500 — Internal Server Error.

    Наиболее употребительные параметры http-ответа:

    Connection — аналогичен соответствующему параметру запроса.
    Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

    Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
    1. выдать в запросе Connection: Keep-Alive;
    2. о состоянии соединения судить по полю Connection в ответе.

    Content-Type («тип содержимого») — содержит обозначение типа содержимого ответа.

    В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

    Некоторые типы содержимого:

    text/html — текст в формате HTML (веб-страница);
    text/plain — простой текст (аналогичен «блокнотовскому»);
    image/jpeg — картинка в формате JPEG;
    image/gif — то же, в формате GIF;
    application/octet-stream — поток «октетов» (т.е. просто байт) для записи на диск.

    На самом деле типов содержимого гораздо больше.

    Content-Length («длина содержимого») — длина содержимого ответа в байтах.

    Last-Modified («Модифицирован в последний раз») — дата последнего изменения документа.

    Мастер Йода рекомендует:  Знакомимся с командой Ping
    Добавить комментарий