Скрытые возможности HTTP

Какие скрытые функции HTTP, по вашему мнению, стоит упомянуть?

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

Только одна функция на ответ, пожалуйста.

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

2.3.2 418 Я чайник

Любая попытка заварить кофе с помощью чайника должна приводить к появлению кода ошибки «418 Я чайник». Полученное тело объекта МОЖЕТ быть коротким и крепким.

Тот факт, что реферер был написан с ошибкой, и было решено сохранить эту ошибку.

Очевидный ответ: методы PUT, DELETE, TRACE, OPTIONS, CONNECT.

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

Кто-нибудь когда-нибудь видел 402 Требуется оплата ?

204 Нет содержимого

Я думал, что 204 было просто, если у вас нет контента для отображения, но спецификация выглядит так, как будто есть дополнительное поведение, при котором пользовательский агент «не меняет свой вид документа».

Согласно HOWTO: настройка Apache для возврата HTTP 204 (без содержимого) для AJAX

FWIW, Google действительно делает нечто подобное. Каждый раз, когда пользователь нажимает ссылку в своих результатах поиска, Google проверяет сам себя, чтобы записать клик; код ответа на пинг - HTTP 204.

Кроме того, 204 No Content предлагает, что это хороший метод для устранения «веб-ошибок» или «маяков», если вы хотите сэкономить на каждом последнем байте сетевого трафика, который вы можете.

Код ответа410 Gone :

(...) владельцы серверов желают, чтобы удаленные ссылки на этот ресурс были удалены. (...)

Веб-пауки (в первую очередь Google) деиндексируют (обычно при следующем сканировании) страницу, которая начинает возвращать 410.

В динамическом контенте используйте заголовок Last_Modified или ETag

Иногда у вас есть динамический контент, который может быть большим и / или дорогостоящим для создания и который может не меняться от запроса к запросу. Вы можете добавить заголовок Last_Modified или ETag к сгенерированному ответу.

В верхней части вашего дорогостоящего динамического кода вы можете использовать If_Modified_Since или If_None_Match, чтобы определить, есть ли у инициатора запроса контента все еще текущий. Если это так, измените статус ответа на «304 без изменений» и завершите запрос.

Некоторые серверные технологии формально предоставляют такие возможности, но вы можете сделать это даже в простом ASP-Classic.

Обратите внимание, что это отличается от настройки заголовков Cache-Control, Expires тем, что он гарантирует, что у клиента всегда будет самая последняя информация по запросу.

Вы можете запросить возобновление (большого) HTTP-ответа (например, загрузки файла), используя Rangeи If-Rangeзапросить заголовки с соответствующим диапазоном байтов и уникальным идентификатором файла или меткой времени изменения файла. Это возможно, если сервер отправил заголовки ответа Accept-Ranges: bytesи ETagили Last-Modifiedв начальном ответе с соответствующим уведомлением о том, что сервер поддерживает запросы диапазона байтов, уникальным идентификатором файла и меткой времени изменения файла.

Первоначальный ответ может выглядеть так ( ETagобычно состоит из имени файла, размера и отметки времени последней модификации):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

Когда загрузка прерывается, например, на 1 КБ (1024 байта), клиент может возобновить ее следующим образом:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Что должно вернуть этот ответ с соответствующими байтами в теле:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

ReST пытается максимально использовать HTTP как протокол интерфейса.

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

Трейлер (в отличие от заголовка)

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

HTTP 100 (Продолжить) Статус

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

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

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

Однако для полноценного использования этой функции существуют некоторые критерии для клиента, серверов и прокси HTTP1.1. См. HTTP / 1.1 RFC 2616 для дальнейшего чтения о HTTP-соединениях.

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

• Когда вызывается URI http://www.domain.invalid/index.php?id=44 , если query ( id=44) не может вернуть ресурс, почему бы не вернуть код состояния 404?
• Когда вызывается URI, http://www.domain.invalid/index.php?id=foo а idпринимаются только целые числа, почему бы не вернуть код состояния 400?
• Почему, когда вы вводите неправильный логин / пароль, почти все веб-приложения возвращают сообщение типа «Ошибка аутентификации» с кодом состояния 200(хорошо, нет проблем, вы делаете это хорошо) вместо401 ?

Да, коды состояния кажутся некоторым веб-разработчикам своего рода секретной функцией HTTP ... Но мне интересно, не является ли самая оккультная из всех «функций» этого протокола его RFC !