Приховані функції HTTP

Як ви думаєте, про які приховані функції HTTP варто згадати?

Під прихованими функціями я маю на увазі функції, які вже є частиною стандарту, але досить невідомі або невикористані.

Будь ласка, лише одна функція на відповідь

Це повинен бути код стану 418 I'm a teapot , який є частиною протоколу керування кавовим горщиком Hyper Text (розширення 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.

Зверніть увагу, що це відрізняється від налаштування Керування кешем, Термін дії заголовків тим, що забезпечує, що клієнт завжди має останню інформацію на запит.

Ви можете подати запит на відновлення (великої) відповіді 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 , якщо запит ( id=44) не може повернути ресурс, чому б не повернути код стану 404?
• Коли URI http://www.domain.invalid/index.php?id=foo викликається, тоді як idприймає лише цілі числа, чому б не повернути код стану 400?
• Чому, коли ви вводите неправильний логін / пароль, майже всі веб-програми повертають повідомлення на зразок "Не вдалося виконати автентифікацію" із кодом стану 200(гаразд, немає проблем, ви добре це робите) замість 401?

Так, коди стану здаються деяким секретним функціоналом HTTP для деяких веб-розробників ... Але мені цікаво, чи не найбільш прихованою з усіх "особливостей" цього протоколу є його RFC !