[2] 意味的に意味のある形で (HTTP の通常の処理で要求されるもの以上の) メッセージを変更するよう設計された、あるいは設定された HTTP から HTTP への串を、変形串transforming proxyといいます >>1。

仕様書

Cache-Control: no-transform

[8] 要求や応答の Cache-Control: ヘッダーの no-transform キャッシュ指令は、 中間器が (キャッシュであるかどうかに関わらず) payload を変形してはならないことを示します >>7, >>11。

[10] このキャッシュ指令は引数を指定できません >>9。

処理モデル

[3] 串は、 no-transform キャッシュ制御指令を含むメッセージの payload を変形してはなりません >>1。

[4] 串は、 >>3 以外のメッセージの payload を変形して構いません >>1。

[215] payload を変形する串は、警告符号 214 の Warning: ヘッダーを (なければ) 追加しなければなりません >>1, >>13。

[216] payload を変形する串は、 200 応答を転送する時に 203 に状態符号を変更することができます >>1。

[14] 変形と条件付き要求や範囲要求との関係は定かではありません。 範囲に対して変形を適用できるかは怪しいところですから、 範囲要求は変形後に適用されると解するべきでしょうか。

[15] 実体タグと変形の関係性も怪しいところです。 変形した場合は実体タグは除去するべきかもしれません。

[16] キャッシュに関する HTTP 的な操作を正しく行うことを考えると、 キャッシュ項目として保存するのは変形前の状態か、 あるいは両方を保存して上流に対する操作には前の状態を使うようにしないといけません。

歴史

[12] RFC 2068/RFC 2616 14.9.5 No-Transform Directive 非変換指令
no-transform
Implementers of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A 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. HTTP has to date been silent on these transformations.

Serious operational problems have already occurred occur, however, when these transformations have been 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 must not MUST NOT change any aspect of the entity-body that is specified by these headers., including the value of the entity-body itself.

実装

[6] >>5 は HTTP でいう中間器ではありませんが、 応答の Cache-Control: no-transform に対応しているようです。

[17] Cache-Control: no-transform で各種メディアの変換(再圧縮等)を防ぐ ( 版) https://blog.knjcode.com/cache-control-no-transform/

Googleプロキシで再圧縮された後のjpeg画像に付加されていたEXIFデータは以下のとおりです。

– Orientation(画像の回転方向)

– ColorSpace(色空間)

– PixelXDimension(横ピクセル数)

– PixelYDimension(縦ピクセル数)

EXIFデータはあるものの、Orientation(画像の回転方向)は元の値によらず”1″(回転なし)の値になっており、さらに、ColorSpace(色空間)についても元の値によらず”1″(sRGB)となっているようです。

AdobeRGBの色空間の画像が再圧縮された場合にはEXIF情報のColorSpaceはsRGBに書き換わってしまうものの、画像のデータ自体の色空間は変換されずAdobeRGBのままになっているため、ブラウザで表示した際の色味が変わってしまいます。

つまり、画像の回転方向が必要な場合だけでなく、色空間を考慮した処理をする場合においても Cache-Control: no-transform を設定するべきであることが分かります。