Content-Transfer-EncodingはHTTPヘッダーですか？
Base64エンコードされたPDFファイルを返すWebサービスを書いているので、私の計画は応答に2つのヘッダーを追加することです：
Content-Type: application/pdf
Content-Transfer-Encoding: base64
私の質問は：Content-Transfer-Encoding有効なHTTPヘッダー？私はそれがMIMEのためだけであるかもしれないと思います。そうでない場合、base64でエンコードされたPDFを返すという事実を表すために、どのようにHTTP応答を作成する必要がありますか？ありがとう。
編集：
HTTPはこのヘッダーをサポートしていないようです。 RFC2616セクション14 から：
注：Content-MD5の定義は、MIMEエンティティボディのRFC 1864とHTTPでまったく同じですが、Content-MD5のHTTPエンティティボディへの適用は、MIMEエンティティへの適用と異なるいくつかの方法があります。体。 1つは、HTTPは、MIMEとは異なり、Content-Transfer-Encodingを使用せず、Transfer-EncodingとContent-Encodingを使用することです。
ヘッダーに設定する必要があるものについてのアイデアはありますか？ありがとう。
EDIT 2
このPHPリファレンスマニュアルページのコメントにあるコードサンプルの多くは、実際にはis有効なHTTPヘッダーであることを示唆しているようです。
RFC 1341 （ RFC 2045 で廃止された）によると：
Content-Transfer-Encodingヘッダーフィールド。データまたは文字セットの制限がある可能性のあるメールトランスポートメカニズムを通過させるために、データに適用された補助エンコーディングを指定するために使用できます。
以降：
電子メールで便利に転送できる多くのContent-Typeは、「自然な」形式で8ビット文字またはバイナリデータとして表されます。このようなデータは、一部のトランスポートプロトコルでは送信できません。たとえば、RFC 821では、メールメッセージを1000文字行の7ビットUS-ASCIIデータに制限しています。
したがって、このようなデータを7ビットの短い行形式に再エンコードするための標準メカニズムを定義する必要があります。 （...）Content-Transfer-Encodingフィールドは、トランスポートで受け入れ可能な方法でボディを表すために使用された変換のタイプを示すために使用されます。
電子メールとは何の共通点もないWebサービスがあるため、このヘッダーは使用しないでください。
転送されたデータが圧縮されていることを示すContent-Encodingヘッダーを使用できます（gzip値）。
あなたの場合は
Content-Type: application/pdf
十分ですさらに、Content-Lengthヘッダーを設定できますが、私の意見では、Webサービス（httpサーバー/プロキシサーバーではありません）Content-Typeで十分です。適切に使用されない特定のヘッダー（例：Transfer-Encoding）は予期しない通信の問題を引き起こす可能性があるため、ヘッダーの使用について100％確信がない場合-本当に必要かどうか-使用しないでください。