[1] [DFN[[CODE(MIME)@en[[[application/http]]]]]] は、 [[HTTP]] [[メッセージ]]の列の[[MIME型]]です。 * 仕様書 [REFS[ - [4] '''[CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) ''' - [11] [CITE[OData Version 4.0 Part 1: Protocol Plus Errata 01]] ([TIME[2014-09-04 16:00:00 +09:00]] 版) - [13] [CITE[OData Version 4.0 Part 1: Protocol Plus Errata 01]] ([TIME[2014-09-04 16:00:00 +09:00]] 版) ]REFS] * 文脈 [9] どのような場面でこの [[MIME型]]が使われることがあるのかは不明です。 [12] [[OData]] は[[非同期]]の処理結果の報告に [CODE(MIME)@en[[[application/http]]]] を使っています [SRC[>>11]]。また [[HTTP]] [[応答]]で転送される [CODE(MIME)@en[[[multipart/mixed]]]] の[[本体部分]]としても [CODE(MIME)@en[[[message/http]]]] を使っています [SRC[>>13]]。 [15] [[Google BigQuery]] は複数の[[要求]]をまとめて送信したり、 それに対する[[応答]]を受信したりするために [CODE(MIME)@en[[[application/http]]]] を [CODE(MIME)@en[[[multipart/mixed]]]] の[[本体部分]]として使っています [SRC[>>14]]。 ;; [16] 例示の[[要求]]は[[要求行]]に[[プロトコルの版]]が含まれていません。 例示の誤りなのか実際にそう動作しているのかは不明です。 [REFS[ - [14] [CITE@ja[Batch Requests - Google BigQuery — Google Cloud Platform]] ([TIME[2014-12-18 02:33:04 +09:00]] 版) ]REFS] * 引数 [5] [[引数]]は次の2つが定義されており、いずれも省略可能です [SRC[>>4]]。 [FIG(short list)[ - [CODE(MIME)@en[[[msgtype]]]] - [CODE(MIME)@en[[[version]]]] ]FIG] * CTE [6] [[CTE]] は [CODE(MIME)@en[[[binary]]]] とされており、 [[プロトコル]]によっては何らかの[[符号化]]が必要です [SRC[>>4]]。 ;; [7] すなわち、 [CODE(MIME)@en[[[7bit]]]] や [CODE(MIME)@en[[[8bit]]]] は不適切です。 * 本体 [8] [[本体]]は、1つ以上の[[要求メッセージ]]の列か、[[応答メッセージ]]の列です [SRC[>>4]]。 [17] [[HTTP/2]] を扱えるのかは不明です。 * 処理モデル [10] 処理モデルは特に規定されておらず、どのように利用するべきなのか不明です。 * 関連 [2] 類似の媒体型として、 [CODE(MIME)[[[message/http]]]] があります。こちらは [[RFC1945]] から規定されていました。 [CODE(MIME)[[[message/*]]]] では、 [[MIME]] の規定により、行長に制限があるとか、生でない [[CTE]] を使ってはいけないとかで、転送することが不可能な HTTP メッセージが存在します。 [WEAK[一見転送できそうに見えても、 [CODE(char)[[[CR]]]] だけとか [CODE(char)[[[LF]]]] だけとかの改行が含まれていて、正規化されてしまった結果 HTTP メッセージとしては ([CODE(HTTP)[[[Content-Length]]]] とかと) 不整合なものになってしまう可能性があります。]] そんなわけで [CODE(MIME)[application/http]] が用意されました。 おそらく、ほとんどすべての場合で、 HTTP メッセージには [CODE(MIME)[message/http]] ではなく [CODE(MIME)[application/http]] を使う方が適切でしょう。 [3] もう一つの重要な [CODE(MIME)[message/http]] との違いとして、 [CODE(MIME)[application/http]] では[[パイプライン接続]]のようにメッセージ群を一つの[[実体]]に含めることができます。 (但し、要求のメッセージ群だけまたは応答のメッセージ群だけの連続でないといけません。混合は不可とされています。) [FIG(quote)[ [FIGCAPTION[ [18] [CITE@en[Batching Requests  |  Gmail API  |  Google Developers]] ([TIME[2015-10-08 03:21:07 +09:00]] 版) ]FIGCAPTION] > A batch request is a single standard HTTP request containing multiple Gmail API calls, using the multipart/mixed content type. Within that main HTTP request, each of the parts contains a nested HTTP request. > Each part begins with its own Content-Type: application/http HTTP header. It can also have an optional Content-ID header. However, the part headers are just there to mark the beginning of the part; they're separate from the nested request. After the server unwraps the batch request into separate requests, the part headers are ignored. ]FIG] [FIG(quote)[ [FIGCAPTION[ [19] [CITE@ja[Google アナリティクス API リクエストのバッチ処理  |  アナリティクス Real Time Reporting API  |  Google Developers]] ( ([TIME[2016-09-30 03:30:47 +09:00]])) ]FIGCAPTION] > バッチ リクエストは、multipart/mixed コンテンツ タイプを使用した、複数の Google アナリティクス API 呼び出しを含む 1 つの標準的な HTTP リクエストです。このメインの HTTP リクエストを構成する各パートには、ネストされた HTTP リクエストが含まれます。 > 各パーツはそれぞれ Content-Type: application/http HTTP ヘッダーで始まり、オプションの Content-ID ヘッダーを指定することもできます。ただし、パーツヘッダーはパーツの開始箇所を示すためだけに存在していて、ネストされたリクエストとは分かれています。サーバーが一括リクエストを別々のリクエストにアンラップした後、パーツヘッダーは無視されます。 > 各パーツのボディ自体が完全な HTTP リクエストで、独自の動詞、URL、ヘッダー、ボディが含まれます。HTTP リクエストには URL のパス部分のみを含める必要があり、完全な URL は、一括リクエストでは許可されていません。 ]FIG] [20] [CITE@ja[Indexing API の使用  |  検索  |  Google Developers]] ([TIME[2019-12-18 02:56:05 +09:00]]) [21] [CITE@en[Sending batch requests  |  Cloud Storage  |  Google Cloud]] ([TIME[2019-11-16 06:23:28 +09:00]])