Обсуждение:HTTP

Википедия не поддерживает HEAD

Любопытен факт. Казалось бы, стандарт, но нееееет...

$ HEAD ru.wikipedia.org
403 Forbidden
Connection: close
Date: Fri, 17 Jul 2009 08:15:06 GMT
Via: 1.0 knsq24.knams.wikimedia.org:80 (squid/2.7.STABLE6)
Server: squid/2.7.STABLE6
Content-Length: 59742
Content-Type: text/html
Client-Date: Fri, 17 Jul 2009 08:15:06 GMT
Client-Peer: 91.198.174.2:80
Client-Response-Num: 1
X-Cache: MISS from knsq24.knams.wikimedia.org
X-Cache-Lookup: NONE from knsq24.knams.wikimedia.org:80
X-Squid-Error: ERR_ACCESS_DENIED 0

78.107.176.130 08:17, 17 июля 2009 (UTC)

Википедия использует движок MediaWiki, работающий на PHP. А в мане PHP сказано, что если был метод HEAD, то запрос выполняется как обычный GET-запрос, но после того как будет произведена первая запись в буфер вывода (с помощью echo, print и т.п.), то будут посланы все заголовки и выполнение завершится, т.е. получится поведение по спецификации.

То есть даже примитивный скрипт типа этого: <?php echo "Hello World"; ?> поддерживает метод HEAD.

А у вас тут вообще ответ от прокси-сервера Squid, а не от веб-сервера. Все притензии к нему или к тем, кто его конфигурировал. Callidus 14:54, 20 июля 2009 (UTC)

Навигация в статьях по HTTP

Для того чтобы удобней было пользоваться материалами статей по HTTP желательно делать внутренние ссылки на методы, коды состояния и заголовки. Так как по многим элементам протокола отдельные статьи создавать избыточно, их описание располагается в соответствующих списках. Поэтому в основном используются ссылки с указанием фрагментов: [[Статья#Фрагмент]].

Можете ссылаться сразу на отдельную статью, но убедитесь что она не будет удалена или объединена с соответствующим списком из-за своей микроскопичности. Фрагментарная ссылка предпочтительней, так как она гарантировано приведёт читателя к нужному материалу. Если что, то в описании есть ссылка на полную статью если таковая имеется.

Желательно названия заголовка, метод и код состояния включать в тэг <TT> (технический термин): <tt>Content-Range</tt>, <tt>PUT</tt>, <tt>404</tt>.

Методы живут в основной статье по HTTP. Их перенос в отдельную статью не предвидется. Поэтому ссылайтесь через основную статью по HTTP указав после решётки метод заглавными буквами:

[[HTTP#POST|<tt>POST</tt>]] — ссылка на метод POST.

На коды состояния ссылайтесь через «Список кодов состояния HTTP» указав после решётки только числовой код без пояснительной фразы:

[[Список кодов состояния HTTP#307|<tt>307</tt>]] — ссылка на код состояния 307.

Заголовки находятся в статье «Список заголовков HTTP», но там сейчас не все есть. Поэтому сперва убедитесь что он там присутствует — парсер Википедии не подсветит красным если его нет, а если пользователь перейдёт по несуществующей фрагментальной ссылке, то он попадёт на самую макушку статьи.

[[Список заголовков HTTP#Allow|<tt>Allow</tt>]] — ссылка на заголовок Allow.

Callidus 11:21, 18 сентября 2008 (UTC)

Заголовки и методы

Практически нету описания заголовка HTTP-пакета. И соответственно описания его параметров и тд. Было-бы полезно разработчикам. Ссылки также не дают ёмкой информации про это

В Википедии самообслуживание ;). --A.I. 23:53, 20 апреля 2007 (UTC)

Я планирую этим заняться. Область обширная и требует большой работы. Думаю логичней создать отдельную статью. Callidus 18:05, 6 ноября 2007 (UTC)

В своё время перелопатив все RFC по протоколу составил огромный полезный черновик. Пожалуйста, используйте, его как захотите ато жалко что простаивает (я до него не скоро доберусь). Потом часть готовых таблиц можно будет перенести в статьи. Callidus 13:23, 3 июля 2008 (UTC)

Структура

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

• Применение — коротко о том кем, зачем и почему используется. За это может сойти и вступление, но оно какое-то никозистое и его думаю стоит переписать. В итоге переделал вступительную часть. Думаю всё очевидно. Callidus 03:41, 7 ноября 2007 (UTC)
• Достоинства — видел в RFC (в самом начале расписаны). Начало заложил. Callidus 03:41, 7 ноября 2007 (UTC)
• Недостатки — этот пункт должен быть по-любому раз есть достоинства (для нейтральности). Добавил два недостатка. Думаю закончено. Callidus 03:41, 7 ноября 2007 (UTC)
• ПО — виды использующих протокол программ.
  • Сервер — короткое описание о программах-серверах. Перечисление популярных.
  • Клиент — короткое описание. Перечислять думаю не стоит, так как понятие включает в себя всё что ниже.
    • Агент — короткое описание. Перечисление популярных.
      • Браузер — короткое описание. Перечисление популярных, желательно и для мобильных устройств.
    • Пауки — короткое описание. Перечисление поисковиков и софта для выкачки сайтов.
  • Прокси — короткое описание. Перечисление популярных.
• История развития — можно подробней расписать.
  • HTTP/0.9
  • HTTP/1.0
  • HTTP/1.1
• Перспективы развития (HTTP/1.2) В английской Википедии уже есть про него упоминание и RFCшку видел с его зачатками.
• HTTP для разработчиков — структура пакетов.
  • Стартовая строка — я уже расписал.
  • Методы — переработать то что есть.
  • Коды состояния — сам переписал. В случае необходимости можно написать более кратко, так как есть целая статья по этой теме.
  • Заголовки — вот это уже обширная тема. Логично будет создать отдельную статью по этой теме, а здесь написать основное по ним. Отдельная статья. Callidus 20:58, 28 августа 2008 (UTC)
  • Тело сообщения — коротко описать в каком виде передаётся. Есть ли особенности кодирования или запрещённые символы.
  • Примеры — привести один примитивный и парочку с особенными случаями. Оформить, думаю, лучше в виде диалога.
• Основные механизмы
  • Частичные GET
  • Множественное содержимое
  • Условные GET
  • Обсуждение содержимого (Content Negotiation).
  • Кэширование
  • ETag
  • Авторизация
• Протоколы на основе HTTP — хорошо бы написать почему пришлось их разработать
  • WebDAV
  • WAP
• Ссылки по теме, источники и прочая лабуда.

В таком виде думаю статья будет очень хорошей и полезной для многих. Просьба ставить галочки напротив уже полностью готовых пунктов. Callidus 18:05, 6 ноября 2007 (UTC)

Иллюстрации

Из иллюстраций пока в голову приходит только фотка стойки HTTP-серверов из какого-нить дата-центра или самого первого сервера.Callidus 18:05, 6 ноября 2007 (UTC)

Есть такой дайнлоан менеджер ReGet. В нём хорошо и наглядно виден HTTP-диалог между клиентом и сервером. В качестве иллюстрации скрин оттуда нелишним был бы. Callidus 03:47, 7 ноября 2007 (UTC)

HTTP-NG

Случайно наткнулся на его упоминание в какой-то новости за 1998 год. W3C даже какие-то телодвижения активные производила по поводу его внедрения и альтернативы HTTP. Думаю про него стоит упомянуть в статье. Callidus 03:36, 7 ноября 2007 (UTC)

Собственно сам и впендюрил его в статью среди недостатков. Протокол малоизвестен и сейчас разрабатывается (хоть и последние телодвижения в 1999 году). Желающие могут про него целую статью создать если есть силы лопатить RFC (в Рунете инфы по нему очень мало). Callidus 05:16, 7 ноября 2007 (UTC)

dfb

хай братоны я новенкий £ 79.120.121.8 07:13, 6 декабря 2008 (UTC)

Семейство

HTTP никаким боком не относится к семейству TCP/IP.

это ошибка

HTTP/1.2.... Не стыдно?

HTTP/1.2
Первоначально 1995 работая проектов документа PEP - механизм выдвижения для HTTP
(предложил протокол выдвижения протокола, сокращенный PEP)
подготовил Консорциум world wide web и представлено к Internet engineering task force.
PEP первоначально был предназначен стать различая характеристикой HTTP/1.2.[4]
В более поздно Проекты PEP работая, однако, справка к HTTP/1.2 извлеклась.
Экспериментально RFC 2774, Рамки выдвижения HTTP, больше subsumed PEP.
Оно было опубликовано в феврале 2000.

84.23.49.87 19:05, 25 июня 2011 (UTC)

Вам что-то не понятно?

Удаляю параграф "Большой размер сообщений", ибо...

1) он уже давно не актуален, да и никогда таковым особенно и не был: собственно текст как сейчас составляет, так и раньше составлял очень малую долю контента, а все остальное - картинки, аудио, видео, софт и прочая - все равно передается уже в сжатом виде.

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

Статья требует серьезной переработки

На мой взгляд, статья ещё в очень и очень сыром виде. В первую очередь, в глаза бросается раздел "Преимущества и недостатки". Не знаю, откуда их взял автор, но не из RFC явно. Неясна и сама формулировка: преимущества и недостатки перед чем? Перед gopher'ом? Почти каждый пункт в этом разделе, как минимум, крайне спорен: о каком обилии документации по протоколу идет речь? RFC уже более чем исчерпывающая документация, тем более не могу сказать, что протокол очень сложен и требует какого-то обилия документации. Какие средства разработки для популярных IDE? О чем это? Весь раздел нуждается либо в переработке, либо вообще удалении как ОРИСС. Пока просто поставил запрос на источники. Раздел с примерами, на мой взгляд стоит вынести в самый низ, в середине содержания он смотрится достаточно странно. Разделы "Основные механизмы протокола" и "Особенности протокола" стоит переработать и совместить. Крайне избыточные примеры, написанные в несколько странном стиле какого-то руководства. На мой взгляд, этому здесь не место (и очень напоминает ОРИСС). Да и в целом, текст стоит привести к более энциклопедичному стилю, все-таки техническая статья: "Привет, Василий! Твой ручной лев, которого ты оставил у меня на прошлой неделе, разодрал весь мой диван. Пожалуйста, забери его скорее! Во вложении две фотки с последствиями."

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

P.S. Ну и непонятно, зачем постоянно в тексте упоминать "арабские цифры". Имхо, это и так стандарт в современном мире, читатель в состоянии догадаться, что имелись ввиду не римские. Убрал. --Kvaleev 15:02, 10 июня 2013 (UTC)

Откуда столько методов?

Никаких PATCH или LINK в RFC 2616 не упоминается. Ссылки пожалуйста! И что, это где-нибудь используется практически? --178.158.194.61 09:09, 23 мая 2014 (UTC)

Методы LINK и UNKINK есть в RFC1945 (ранней). Метод PATCH я брал видимо из другой (не помню какой, возможно есть отдельная RFC по этому). Люди в спецификации их упомянули и видимо надеялись что их применят. На практике почему-то не использовались. Поэтому сюда включил (полнота изложения и все дела). Callidus 21:06, 30 апреля 2016 (UTC)