[2] 意味的に意味のある形で ([[HTTP]] の通常の処理で要求されるもの以上の) メッセージを変更するよう設計された、あるいは設定された [[HTTP]] から [[HTTP]] への[[串]]を、[DFN[[RUBYB[[[変形串]]]@en[transforming proxy]]]]といいます [SRC[>>1]]。 * 仕様書 [REFS[ - [1] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ''' - [9] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) -- [7] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) -- [11] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [13] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) ]REFS] * [CODE(HTTP)@en[Cache-Control: no-transform]] [8] [[要求]]や[[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]の [DFN[[CODE(HTTP)@en[[[no-transform]]]]]] [[キャッシュ指令]]は、 [[中間器]]が ([[キャッシュ]]であるかどうかに関わらず) [[payload]] を[[変形]]しては[['''ならない''']]ことを示します [SRC[>>7, >>11]]。 [10] この[[キャッシュ指令]]は[[引数]]を指定できません [SRC[>>9]]。 * 処理モデル [3] [[串]]は、 [CODE(HTTP)@en[[[no-transform]]]] [[キャッシュ制御指令]]を含む[[メッセージ]]の [[payload]] を[[変形]]しては[['''なりません''']] [SRC[>>1]]。 [4] [[串]]は、 >>3 以外の[[メッセージ]]の [[payload]] を[[変形]]して[['''構いません''']] [SRC[>>1]]。 [215] [[payload]] を[[変形]]する[[串]]は、[[警告符号]] [CODE(HTTP)[[[214]]]] の [CODE(HTTP)@en[[[Warning:]]]] [[ヘッダー]]を (なければ) 追加しなければ[['''なりません''']] [SRC[>>1, >>13]]。 [216] [[payload]] を[[変形]]する[[串]]は、 [CODE(HTTP)[[[200]]]] [[応答]]を[[転送]]する時に [CODE(HTTP)[[[203]]]] に[[状態符号]]を変更することができます [SRC[>>1]]。 [14] [[変形]]と[[条件付き要求]]や[[範囲要求]]との関係は定かではありません。 [[範囲]]に対して[[変形]]を適用できるかは怪しいところですから、 [[範囲要求]]は[[変形]]後に適用されると解するべきでしょうか。 [15] [[実体タグ]]と[[変形]]の関係性も怪しいところです。 [[変形]]した場合は[[実体タグ]]は除去するべきかもしれません。 [16] [[キャッシュ]]に関する [[HTTP]] 的な操作を正しく行うことを考えると、 [[キャッシュ項目]]として保存するのは[[変形]]前の状態か、 あるいは両方を保存して[[上流]]に対する操作には前の状態を使うようにしないといけません。 * 歴史 [FIG(quote)[ [FIGCAPTION[ [12] [[RFC 2068]]/[[RFC 2616]] 14.9.5 No-Transform Directive [INS[非変換指令]] ]FIGCAPTION] > :[INS[no-transform]]: Implementers of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A [INS[non-transparent]] proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. [DEL[HTTP has to date been silent on these transformations.]] > Serious operational problems [DEL[have already occurred]] [INS[occur]], however, when these transformations [DEL[have been]] [INS[are]] applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body. > Therefore, if a response includes the no-transform directive, an intermediate cache or proxy MUST NOT change those headers that are listed in section 13.5.2 as being subject to the no-transform directive. This implies that the cache or proxy [DEL[must not]] [INS[MUST NOT]] change any aspect of the entity-body that is specified by these headers[DEL[.]][INS[,]] including the value of the entity-body itself. ]FIG] * 実装 [REFS[ - [5] [CITE[Hatena::MobileGateway]] ([TIME[2011-09-09 12:16:11 +09:00]] 版) ]REFS] [6] >>5 は [[HTTP]] でいう[[中間器]]ではありませんが、 [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]] [[no-transform]]]] に対応しているようです。 [FIG(quote)[ [FIGCAPTION[ [17] [CITE@ja[Cache-Control: no-transform で各種メディアの変換(再圧縮等)を防ぐ]] ([TIME[2015-07-17 08:46:56 +09:00]] 版) ]FIGCAPTION] > Googleプロキシで再圧縮された後のjpeg画像に付加されていたEXIFデータは以下のとおりです。 > – Orientation(画像の回転方向) > – ColorSpace(色空間) > – PixelXDimension(横ピクセル数) > – PixelYDimension(縦ピクセル数) > EXIFデータはあるものの、Orientation(画像の回転方向)は元の値によらず”1″(回転なし)の値になっており、さらに、ColorSpace(色空間)についても元の値によらず”1″(sRGB)となっているようです。 > AdobeRGBの色空間の画像が再圧縮された場合にはEXIF情報のColorSpaceはsRGBに書き換わってしまうものの、画像のデータ自体の色空間は変換されずAdobeRGBのままになっているため、ブラウザで表示した際の色味が変わってしまいます。 > つまり、画像の回転方向が必要な場合だけでなく、色空間を考慮した処理をする場合においても Cache-Control: no-transform を設定するべきであることが分かります。 ]FIG]