Client-Initiated Content-Encoding
HTTP Client-Initiated Content-Encoding
https://tools.ietf.org/html/draft-ietf-httpbis-cice-00
という、HTTPに関する拡張仕様が提案されており、4月にhttpbisのWGドラフトになっている。
Accept-Encodingヘッダをレスポンスメッセージでも使えるようにする。
Content CodingsとAccept-Encoding
HTTPでは、Content-Encodingヘッダを用いてペイロードのエンコーディングを示すことが出来ます。
特に、レスポンスメッセージにおいて"gzip" Content Codingsは圧縮のために広く使用されています。
クライアントは、どのようなエンコーディングに対応しているかAccept-Encodingヘッダをリクエストヘッダに付加することでサーバに伝えることが出来ます。ですが、Accept-Encodingはリクエストヘッダでしか使用できません(RFC7231)
Content-Encodingヘッダはリクエストメッセージでも使用できますが、サーバが使用できるエンコーディングを知る手立てはありません。
そこで、この提案ではAccept-Encodingをレスポンスヘッダでも使用できるように拡張します。
Example
クライアントはContent-Encodingに"compress"という文字列を指定してPOSTしたとします。
POST /edit/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Content-Encoding: compress
...compressed payload...
サーバは、指定されたContent-Encodingに対応していないので、「451 Unsupported Media Type」でレスポンスを返します。この時、Accept-Encodingでgzipに対応している旨をクライアントに通知します。クライアント側もgzipに対応していれば、それを用いてリクエストをリトライできます。
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: gzip
Content-Length: 68
Content-Type: text/plainまた、サーバはいかなるcontent codingsにも対応していない場合は
「Accept-Encoding: identity」をレスポンスヘッダに付加します。
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: identity
Content-Length: 61
Content-Type: text/plain
