AmazonのS3でホストされている静的ファイルの事前圧縮バージョンを参照するにはどうすればよいですか？
AmazonのS3から直接静的アセット（CSS、JavaScript、画像）を提供するWebサイトがあります。私の知る限り、S3はブラウザが受け入れた場合でもgzipをサポートしていません。
アプリケーションがstyle_v1.gz.cssでgzを検出したときに、HTMLページが事前に圧縮されたscript_v1.gz.jsおよびAccept-Encoding request headers?にリンクする場合（gzipの代わりに）
また、S3でこれらのファイルに特別なヘッダーを設定する必要がありますか？ （明らかなContent-Encoding：gzip以外）
なぜgz拡張子を持つ静的アセットを提供したいのですか？
年齢の一般的な指標であるにもかかわらず、ファイル拡張子は、実際には MIMEタイプ を通信するための劣った不正確なメカニズムです：ideally、web resourcesファイル拡張子に完全に依存せず、適切な HTTPヘッダーContent-TypeやContent-Encodingのようにコンテンツを通信するだけです（これにより、URIスペースの管理も容易になります- クールURIは変わりません ;）
確かに、これはインターネットの初期には機能せず、少数の劣悪なクライアントではまだ機能しない可能性があります（迷惑なことに、一部のプロキシや弱いモバイルはまだこれに苦しんでいるようです）が、関連する部分を明確に識別できない場合オーディエンスがこの制限の影響を受ける（そして最終的にブラウザーをアップグレードすることは選択肢ではない）、代わりに使用中のHTTPヘッダーを単純に信頼し始める必要があります。
したがって、事前に圧縮された静的なアセットwithContent-Encodingand（最後の質問に対処するため）同様に重要なContent-Typeヘッダー（そうでなければ、クライアントは拡張機能やコンテンツ自体からメディアタイプを推測する必要があります）、ただしgz拡張機能。SkylerJohnsonの S3を介してAmazon CloudFrontからgzip圧縮されたCSSとJavaScriptを提供 に対する回答で説明されています。
明らかに、Content-TypeとContent-Encodingに依存したら、gz.cssでサービスを提供する場合（または拡張機能をまったく使用しない場合）、これは同様に機能しますが、上記で概説したように、これは実際にはダウンストリームクライアントに誤解を招く可能性があります。ただし、gzipでエンコードされたファイルを必ずしも処理する必要はありません（プロキシが既にデコードしている場合があります）。