Какие скрытые функции HTTP, на ваш взгляд, стоит упомянуть?
По скрытым функциям я имею в виду функции, которые уже являются частью стандарта, но широко неизвестны или не используются.
Только одна функция для каждого ответа.
Какие скрытые функции HTTP, на ваш взгляд, стоит упомянуть?
По скрытым функциям я имею в виду функции, которые уже являются частью стандарта, но широко неизвестны или не используются.
Только одна функция для каждого ответа.
Это должен быть код статуса 418 Я - чайник, входящий в Протокол управления электронным протоколом Hyper Text (расширение для HTTP). Заставляет меня смеяться каждый раз.
2.3.2 418 Я чайник #/p >
Любая попытка кофе brew с чайником должна привести к ошибке код "418 Я чайник". Результирующий объект тела МОЖЕТ быть коротким и Толстый.
Тот факт, что referrer был опечатан, и было решено, что орфографическое письмо должно быть сохранено.
Очевидный ответ: PUT, DELETE, TRACE, OPTIONS, CONNECT
Большинство людей знают о методах GET и POST, потому что это то, что они используют при создании форм. Браузеры также используют HEAD. Другие методы гораздо менее известны; они в основном используются более конкретными приложениями.
Кто-нибудь видел 402 Требуется оплата?
Я думал, что 204 просто, если у вас нет контента для показа, но spec выглядит так, что существует дополнительное поведение, которое пользовательский агент "не измените его вид документа."
Согласно HOWTO: настройте Apache для возврата HTTP 204 (без содержимого) для AJAX
FWIW, Google действительно что-то делает аналогичный. Каждый раз, когда пользователь нажимает на ссылку в результатах поиска, Google пинговать себя, чтобы записать клик; код ответа из ping - это HTTP 204.
Кроме того, 204 No Content предлагает, что это хороший метод для "веб-ошибок" или "маяков", если вы хотите сохранить каждый раз байт сетевого трафика.
(...) владельцы серверов желают, чтобы удаленные ссылки на этот ресурс будут удалены. (...)
Веб-пауки (особенно Google) будут деинсталлировать (обычно при следующем обходе) страницу, которая начнет возвращаться 410.
В динамическом контенте используйте заголовок Last_Modified или ETag
Время от времени у вас есть динамический контент, который может быть большим и/или дорогостоящим для создания и который не может меняться от запроса к запросу. Вы можете добавить заголовок Last_Modified или ETag в свой сгенерированный ответ.
В верхней части вашего дорогого динамического кода вы можете использовать If_Modified_Since или If_None_Match, чтобы определить, есть ли уже запрос на контент, который уже существует. Если это изменяет статус ответа на "304 Unmodified" и завершает запрос.
Некоторые серверные технологии предоставляют такие функции формально, но вы можете сделать это даже в низком ASP-Classic.
Примечание. Это отличается от настройки Cache-Control, Expires headers тем, что он гарантирует, что клиент всегда будет иметь самую последнюю информацию по запросу.
Вы можете запросить возобновить ответ (большой) 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 Client, Servers и Proxies. См. HTTP/1.1 RFC 2616 для дальнейшего чтения в HTTP-соединениях.
http://www.domain.invalid/index.php?id=44
, если query (id=44
) не смог вернуть ressource, почему бы не вернуть код состояния 404
?http://www.domain.invalid/index.php?id=foo
вызывается, тогда как id
принимает только целые числа, почему бы не вернуть код состояния 400
?200
(нормально, не проблема, вы делаете это хорошо) instade 401
?Да, коды статуса, кажется, является своего рода секретной функциональностью HTTP некоторым веб-разработчикам... Но мне интересно, не самый ли оккультный из всех "функций" этого протокола не его RFC!