HTTPの隠された機能

HTTPのどの隠された機能に言及する価値があると思いますか？

隠された機能とは、すでに標準の一部であるが、広く知られていないか、使用されていない機能を意味します。

回答ごとに1つの機能のみをお願いします。

Hyper Text Coffee Pot Control Protocol（HTTPの拡張機能）の一部である、ティーポットのステータスコードである418である必要があります。毎回笑わせてくれます。

2.3.2418私はティーポットです

ティーポットでコーヒーを淹れると、エラーコード「418I'mateapot」が表示されます。結果として得られるエンティティ本体は、短くて頑丈な場合があります。

リファラーのつづりが間違っていて、つづりを間違えたままにしておくことが決定されたという事実。

明白な答え：PUT、DELETE、TRACE、OPTIONS、CONNECTメソッド

ほとんどの人は、GETメソッドとPOSTメソッドについて知っています。これは、フォームを作成するときに使用するためです。ブラウザもHEADをよく使用します。他の方法はあまり知られていません。これらは主に、より具体的なアプリケーションで使用されます。

402 Payment Requiredを見たことがありますか？

204コンテンツなし

204は表示するコンテンツがない場合だけだと思いましたが、仕様には、ユーザーエージェントが「ドキュメントビューを変更しない」という追加の動作があるようです。

HOWTOによると：AJAXのHTTP 204（コンテンツなし）を返すようにApacheを構成する

FWIW、Googleは実際に似たようなことをします。ユーザーが検索結果のリンクをクリックするたびに、Googleは自分自身にpingを送信してクリックを記録します。pingからの応答コードはHTTP204です。

また、204 No Contentは、ネットワークトラフィックの最後のバイトをすべて節約したい場合に、これが「Webバグ」または「ビーコン」に適した手法であることを提案しています。

応答コード410 Gone：

（...）サーバーの所有者は、そのリソースへのリモートリンクを削除することを望んでいます。（...）

Webスパイダー（特にGoogle）は、410を返し始めるページのインデックスを解除します（通常は次のクロール時に）。

動的コンテンツでは、Last_ModifiedまたはETagヘッダーを使用します

場合によっては、生成するのに大きくてコストがかかる可能性があり、リクエストごとに変更されない可能性がある動的コンテンツがあります。生成された応答にLast_ModifiedまたはETagヘッダーを追加できます。

高価な動的コードの上部で、If_Modified_SinceまたはIf_None_Matchを使用して、コンテンツリクエスターが既に持っているコンテンツがまだ最新であるかどうかを判断できます。応答ステータスを「304Unmodified」に変更し、リクエストを終了します。

一部のサーバーサイドテクノロジーは、このような機能を正式に提供しますが、ASPクラシックが低い場合でも上記を実行できます。

これは、クライアントが要求に応じて常に最新の情報を確実に取得できるという点で、Cache-Control、Expiresヘッダーの設定とは異なることに注意してください。

あなたはして要求することができ再開（大）HTTPレスポンス（ファイルのダウンロード）を使用Rangeし、If-Rangeそれぞれ指定されたバイト範囲とユニークなファイル識別子やファイルの変更のタイムスタンプとリクエストヘッダを。これは、サーバーが最初の応答で、Accept-Ranges: bytesおよびETag/またはLast-Modified応答ヘッダーを送信し、サーバーがバイト範囲要求をサポートしているという通知、一意のファイルID、およびファイル変更タイムスタンプをそれぞれ送信した場合に可能です。

最初の応答は次のようになります（ETag通常、ファイル名、サイズ、および最終変更のタイムスタンプで構成されます）。

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

たとえば1KB（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を限界まで押し込もうとします。

これは隠された機能ではありませんが、明確に定義されたReST APIを見ると、HTTPがどのように機能するかを非常によく把握し、HTTPメソッド、ステータスコード、ヘッダーの単純な組み合わせで実現できることのすばらしい例を見つけることができます。前後に。

トレーラー（ヘッダーとは対照的）

このプロトコルを使用すると、独自のカスタムフィールドを定義できます。Cookieを使用したくない場合は、これらを使用して他の情報を伝達できます。

HTTP 100（続行）ステータス

クライアントは、リクエスト本文を含むリクエストメッセージを送信して、オリジンサーバーがリクエストを受け入れる意思があるかどうかを判断できます。

場合によっては、サーバーが本文を見ずにメッセージを拒否する場合、クライアントが本文を送信することは不適切または非常に非効率的である可能性があります。

不正なクライアントからのトラフィックを回避するために使用できます。および/または帯域幅が貴重な商品である場合。

ただし、この機能を最大限に活用するには、HTTP1.1クライアント、サーバー、およびプロキシにいくつかの基準があります。HTTP接続の詳細については、HTTP / 1.1 RFC2616を参照してください。

ステータスコード：

• URI http://www.domain.invalid/index.php?id=44が呼び出されたときに、クエリ（id=44）がリソースを返すことができなかった場合は、ステータスコードを返さないのはなぜ404ですか？
• ときにURIが http://www.domain.invalid/index.php?id=foo一方呼ばれるid整数のみを受け付け、なぜステータスコードを返しませんか400？
• なぜ、間違ったログイン/パスワードを入力すると、ほとんどすべてのWebアプリケーションが「認証に失敗しました」のようなメッセージをステータスコード200（OK、問題ありません、うまくいきます）で返し401ますか？

はい、ステータスコードは一部のWeb開発者にとってHTTPの一種の秘密の機能のようです...しかし、このプロトコルのすべての「機能」の中で最もオカルトなのはRFCではないのではないかと思います。