メインコンテンツまでスキップ

3. Protocol Parameters (プロトコルパラメータ)

3.1 HTTP Version (HTTPバージョン)​

HTTPは、プロトコルのバージョンを示すために "<major>.<minor>" 番号付けスキームを使用します。プロトコルバージョンポリシーは、送信者がメッセージの形式とさらなるHTTP通信を理解する能力を示すことを可能にすることを意図しており、その通信によって取得される機能ではありません。通信動作に影響を与えない、または拡張可能なフィールド値に追加するだけのメッセージコンポーネントの追加については、バージョン番号は変更されません。プロトコルに対する変更が一般的なメッセージ解析アルゴリズムを変更しないが、メッセージセマンティクスに追加され、送信者の追加能力を示唆する機能を追加する場合、<minor> 番号がインクリメントされます。プロトコル内のメッセージの形式が変更される場合、<major> 番号がインクリメントされます。より完全な説明については、RFC 2145 [36] を参照してください。

HTTPメッセージのバージョンは、メッセージの最初の行のHTTP-Versionフィールドで示されます。

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

メジャーバージョン番号とマイナーバージョン番号は、別々の整数として扱わなければならず (MUST)、各バージョン番号は1桁以上にインクリメントされる可能性があります (MAY)。したがって、HTTP/2.4はHTTP/2.13より低いバージョンであり、HTTP/2.13はHTTP/12.3より低いバージョンです。先頭のゼロは受信者によって無視されなければならず (MUST)、送信してはなりません (MUST NOT)。

"HTTP/1.1" HTTP-Versionを含むリクエストまたはレスポンスメッセージを送信するアプリケーションは、本仕様に少なくとも条件付きで準拠しなければなりません (MUST)。本仕様に少なくとも条件付きで準拠するアプリケーションは、そのメッセージで "HTTP/1.1" のHTTP-Versionを使用すべきであり (SHOULD)、HTTP/1.0と互換性のないメッセージの場合は使用しなければなりません (MUST)。特定のHTTP-Version値をいつ送信するかの詳細については、RFC 2145 [36] を参照してください。

アプリケーションのHTTPバージョンは、そのアプリケーションが少なくとも条件付きで準拠する最高のHTTPバージョンです。

プロキシとゲートウェイアプリケーションは、アプリケーションとは異なるプロトコルバージョンのメッセージを転送する際に注意する必要があります。プロトコルバージョンは送信者のプロトコル能力を示すため、プロキシ/ゲートウェイは実際のバージョンより大きいバージョン指示子を含むメッセージを送信してはなりません (MUST NOT)。より高いバージョンのリクエストを受信した場合、プロキシ/ゲートウェイはリクエストバージョンをダウングレードするか、エラーで応答するか、トンネル動作に切り替えなければなりません (MUST)。

RFC 2068 [33] の発行以来、HTTP/1.0プロキシとの相互運用性の問題が発見されたため、キャッシングプロキシはリクエストをサポートする最高バージョンにアップグレードしなければならず (MUST)、ゲートウェイはアップグレードしてもよく (MAY)、トンネルはアップグレードしてはなりません (MUST NOT)。そのリクエストに対するプロキシ/ゲートウェイのレスポンスは、リクエストと同じメジャーバージョンでなければなりません (MUST)。

注意：HTTPバージョン間の変換には、関与するバージョンによって要求または禁止されるヘッダーフィールドの変更が含まれる場合があります。

3.2 Uniform Resource Identifiers (統一資源識別子)​

URIには多くの名前があります：WWWアドレス、Universal Document Identifiers、Universal Resource Identifiers [3]、そして最後に、統一資源ロケータ (Uniform Resource Locators, URL) [4] と名前 (Names, URN) [20] の組み合わせです。HTTPに関しては、統一資源識別子 (Uniform Resource Identifiers) は、名前、場所、またはその他の特性によってリソースを識別するフォーマットされた文字列です。

3.2.1 General Syntax (一般的な構文)​

HTTP内のURIは、使用されるコンテキストに応じて、絶対形式で表現されるか、既知のベースURI [11] に対して相対的に表現されます。この2つの形式の区別は、絶対URIが常にスキーム名で始まり、その後にコロンが続くことです。URL構文とセマンティクスに関する権威ある情報については、"Uniform Resource Identifiers (URI): Generic Syntax and Semantics"、RFC 2396 [42]（RFC 1738 [4] とRFC 1808 [11] を置き換える）を参照してください。本仕様は、その仕様からの "URI-reference"、"absoluteURI"、"relativeURI"、"port"、"host"、"abs_path"、"rel_path"、および "authority" の定義を採用します。

HTTPプロトコルは、URIの長さに事前の制限を課しません。サーバーは、サービスを提供する任意のリソースのURIを処理できなければならず (MUST)、GETベースのフォームを提供する場合は、無制限の長さのURIを処理できるべきです (SHOULD)。サーバーが処理できる長さを超えるURIの場合、サーバーは414（Request-URI Too Long）ステータスを返すべきです (SHOULD)（セクション10.4.15参照）。

注意：一部の古いクライアントまたはプロキシ実装がこれらの長さを適切にサポートできない可能性があるため、サーバーは255バイトを超えるURI長に依存することに注意すべきです。

3.2.2 http URL​

"http" スキームは、HTTPプロトコルを介してネットワークリソースを見つけるために使用されます。このセクションでは、http URLのスキーム固有の構文とセマンティクスを定義します。

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

ポートが空であるか指定されていない場合、ポート80が想定されます。セマンティクスは、識別されたリソースが、そのホストのそのポートでTCP接続をリッスンしているサーバー上にあり、リソースのRequest-URIがabs_path（セクション5.1.2）であるということです。URL内のIPアドレスの使用は可能な限り避けるべきです (SHOULD)（RFC 1900 [24] 参照）。abs_pathがURL内に存在しない場合、リソースのRequest-URIとして使用される場合は "/" として指定されなければなりません (MUST)（セクション5.1.2）。プロキシが完全修飾ドメイン名ではないホスト名を受信した場合、受信したホスト名にそのドメインを追加してもかまいません (MAY)。プロキシが完全修飾ドメイン名を受信した場合、プロキシはホスト名を変更してはなりません (MUST NOT)。

3.2.3 URI Comparison (URI比較)​

2つのURIを比較して一致するかどうかを判断する場合、クライアントはURI全体に対して大文字と小文字を区別するオクテット単位の比較を使用すべきですが (SHOULD)、以下の例外があります：

  • 空のポートまたは指定されていないポートは、そのURI参照のデフォルトポートと等価です。
  • ホスト名の比較は大文字と小文字を区別しない必要があります (MUST)。
  • スキーム名の比較は大文字と小文字を区別しない必要があります (MUST)。
  • 空のabs_pathは "/" のabs_pathと等価です。

"reserved" および "unsafe" セット以外の文字（RFC 2396 [42] 参照）は、それらの "%HEX HEX" エンコーディングと等価です。

たとえば、以下の3つのURIは等価です：

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

3.3 Date/Time Formats (日付/時刻形式)​

3.3.1 Full Date (完全な日付)​

HTTPアプリケーションは、歴史的に3つの異なる日付/タイムスタンプ表現形式を許可してきました：

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

最初の形式がインターネット標準として推奨され、RFC 1123 [8]（RFC 822 [9] の更新）で定義された固定長サブセットを表します。2番目の形式は広く使用されていますが、廃止されたRFC 850 [12] 日付形式に基づいており、4桁の年が欠けています。日付値を解析するHTTP/1.1クライアントとサーバーは、3つの形式すべてを受け入れなければなりませんが (MUST)（HTTP/1.0との互換性のため）、ヘッダーフィールドでHTTP-date値を表現する場合はRFC 1123形式のみを生成しなければなりません (MUST)。詳細については、セクション19.3を参照してください。

注意：非HTTPアプリケーションによって送信される可能性のある日付値を受け入れる際には、日付値の受信者が堅牢であることが推奨されます。これは、プロキシ/ゲートウェイを介してSMTPまたはNNTPにメッセージを取得または投稿する際に発生する場合があります。

すべてのHTTP日付/タイムスタンプは、例外なくグリニッジ標準時 (Greenwich Mean Time, GMT) で表現されなければなりません (MUST)。HTTPに関しては、GMTはUTC（協定世界時）と完全に等価です。これは、最初の2つの形式ではタイムゾーンの3文字略語として "GMT" を含めることで示され、asctimeフォーマットを読み取る際には想定されなければなりません (MUST)。HTTP-dateは大文字と小文字を区別し、構文で明示的にSPとして含まれているもの以外の追加のLWSを含んではなりません (MUST NOT)。

HTTP-date    = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date  = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1        = 2DIGIT SP month SP 4DIGIT
               ; day month year (e.g., 02 Jun 1982)
date2        = 2DIGIT "-" month "-" 2DIGIT
               ; day-month-year (e.g., 02-Jun-82)
date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
               ; month day (e.g., Jun  2)
time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
               ; 00:00:00 - 23:59:59
wkday        = "Mon" | "Tue" | "Wed"
             | "Thu" | "Fri" | "Sat" | "Sun"
weekday      = "Monday" | "Tuesday" | "Wednesday"
             | "Thursday" | "Friday" | "Saturday" | "Sunday"
month        = "Jan" | "Feb" | "Mar" | "Apr"
             | "May" | "Jun" | "Jul" | "Aug"
             | "Sep" | "Oct" | "Nov" | "Dec"

注意：日付/タイムスタンプ形式のHTTP要件は、プロトコルストリームでの使用にのみ適用されます。クライアントとサーバーは、ユーザープレゼンテーション、リクエストログなどでこれらの形式を使用する必要はありません。

3.3.2 Delta Seconds (デルタ秒)​

一部のHTTPヘッダーフィールドでは、メッセージの受信時刻以降の10進数で表された整数秒として時間値を指定できます。

delta-seconds  = 1*DIGIT

3.4 Character Sets (文字セット)​

HTTPは、MIMEで説明されているものと同じ "文字セット" (character set) という用語の定義を使用します：

本文書における "文字セット" という用語は、オクテットシーケンスを文字シーケンスに変換するために1つ以上のテーブルと組み合わせて使用される方法を指すために使用されます。逆方向への無条件の変換は必要ありません。すべての文字が特定の文字セットで利用可能であるとは限らず、文字セットは特定の文字を表すために複数のオクテットシーケンスを提供する場合があるためです。この定義は、US-ASCIIのような単純な単一テーブルマッピングから、ISO-2022技術を使用する複雑なテーブル切り替え方法まで、さまざまな文字エンコーディングを許可することを意図しています。ただし、MIME文字セット名に関連付けられた定義は、オクテットから文字への実行するマッピングを完全に指定しなければなりません (MUST)。特に、正確なマッピングを決定するために外部プロファイル情報を使用することは許可されません。

注意："文字セット" (character set) というこの用法は、より一般的には "文字エンコーディング" (character encoding) と呼ばれます。ただし、HTTPとMIMEは同じレジストリを共有しているため、用語も共有する必要があることが重要です。

HTTP文字セットは、大文字と小文字を区別しないトークン (tokens) によって識別されます。完全なトークンセットは、IANA文字セットレジストリ [19] によって定義されます。

charset = token

HTTPは文字セット値として任意のトークンの使用を許可しますが、IANA文字セットレジストリ [19] で事前定義された値を持つトークンは、そのレジストリで定義された文字セットを表さなければなりません (MUST)。アプリケーションは、IANAレジストリで定義された文字セットに文字セットの使用を制限すべきです (SHOULD)。

実装者は、IETF文字セット要件 [38] [41] について認識しておく必要があります。

3.4.1 Missing Charset (文字セットの欠落)​

一部のHTTP/1.0ソフトウェアは、charsetパラメータのないContent-Typeヘッダーを誤って "受信者が推測すべき" と解釈します。この動作を克服したい送信者は、文字セットがISO-8859-1である場合にcharsetパラメータを含めてもよく (MAY)、受信者を混乱させないことがわかっている場合はそうすべきです (SHOULD)。

残念ながら、一部の古いHTTP/1.0クライアントは明示的なcharsetパラメータを適切に処理しません。HTTP/1.1受信者は、送信者が提供するcharsetラベルを尊重しなければなりません (MUST)。文字セットを "推測" する規定を持つユーザーエージェントは、送信者がHTTP/1.0クライアントである場合でも、受信者が推測した文字セットではなく、コンテンツタイプフィールドからの文字セットを使用しなければなりません (MUST)。

3.5 Content Codings (コンテンツコーディング)​

コンテンツコーディング値は、エンティティに適用された、または適用できるエンコーディング変換を示します。コンテンツコーディングは主に、その基礎となるメディアタイプの識別と情報を失うことなくドキュメントを圧縮できるようにするために使用されます。エンティティは通常、その基礎となる表現が送信用にエンコードされている場合にのみエンコードされた形式で保存されます。

content-coding   = token

すべてのコンテンツコーディング値は大文字と小文字を区別しません。HTTP/1.1は、Accept-EncodingおよびContent-Encodingヘッダーフィールドでコンテンツコーディング値を使用します。値はエンティティボディに適用されるコンテンツコーディングを記述しますが、より重要なのは、Content-Typeヘッダーフィールドによって参照されるメディアタイプを取得するために適用できるデコーディングメカニズムを示すことです。

Internet Assigned Numbers Authority (IANA) は、コンテンツコーディング値トークンのレジストリとして機能します。最初に、このレジストリには以下のトークンが含まれています：

gzip RFC 1952 [25] で説明されているように、Lempel-Zivコーディング (LZ77) と32ビットCRCを使用するエンコーディング形式。このエンコーディング形式は、UNIX gzip プログラムによって生成されます。HTTP/1.1実装者は、歴史的な理由により、一部の受信者が "x-gzip" と "gzip" を同等として扱うことに注意してください。

compress Lempel-Ziv-Welch (LZW) アルゴリズムを使用して生成されるエンコーディング形式。このエンコーディング形式は、一般的なUNIXファイル圧縮プログラム "compress" によって生成されます。歴史的な理由により、受信者は "x-compress" と "compress" を同等として扱うべきです。

deflate RFC 1950 [31] とRFC 1951 [29] で説明されている "zlib" フォーマットと "deflate" 圧縮メカニズムの組み合わせ。

identity デフォルト（アイデンティティ）エンコーディング。このコンテンツコーディングの使用は、エンコーディングが行われていないことのみを示します。このコンテンツコーディングは、Accept-Encodingヘッダーフィールドで使用され、Content-Encodingヘッダーフィールドでは使用すべきではありません (SHOULD NOT)。

新しいコンテンツコーディングトークンは、Internet Assigned Numbers Authority (IANA) に登録すべきです。

3.6 Transfer Codings (転送コーディング)​

転送コーディング値は、ネットワークを介した "安全な転送" を確保するために、エンティティボディに適用された、適用できる、または適用が必要になる可能性があるエンコーディング変換を示すために使用されます。これは、転送コーディングがメッセージの属性であり、元のエンティティの属性ではないという点でコンテンツコーディングとは異なります。

transfer-coding         = "chunked" | transfer-extension
transfer-extension      = token *( ";" parameter )

パラメータは属性/値のペアの形式を取ります。

parameter               = attribute "=" value
attribute               = token
value                   = token | quoted-string

すべての転送コーディング値は大文字と小文字を区別しません。HTTP/1.1は、TEヘッダーフィールド（セクション14.39）とTransfer-Encodingヘッダーフィールド（セクション14.41）で転送コーディング値を使用します。

転送コーディングはHTTP/1.1の新機能です。メッセージがHTTP/1.1以降として示されていない限り、送信者はメッセージボディに転送コーディングを適用してはなりません (MUST NOT)。

3.6.1 Chunked Transfer Coding (チャンク転送コーディング)​

チャンクエンコーディングは、メッセージボディを一連のチャンクとして転送するように変更し、各チャンクには独自のサイズインジケータがあり、その後にエンティティヘッダーフィールドを含むオプションのトレーラー (trailer) が続きます。これにより、動的に生成されたコンテンツを、メッセージに関する必要な完全性チェック情報とともに転送できます。

Chunked-Body   = *chunk
                 last-chunk
                 trailer
                 CRLF

chunk          = chunk-size [ chunk-extension ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEX
last-chunk     = 1*("0") [ chunk-extension ] CRLF

chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token | quoted-string
chunk-data     = chunk-size(OCTET)
trailer        = *(entity-header CRLF)

chunk-sizeフィールドは、チャンクデータのサイズを示す16進数の文字列です。チャンクエンコーディングは、サイズがゼロのチャンクで終了し、その後にトレーラーが続き、トレーラーは空行で終了します。

トレーラーにより、送信者はメッセージの最後に追加のHTTPヘッダーフィールドを含めることができます。Trailerヘッダーフィールド（セクション14.40）を使用して、トレーラーに含まれるヘッダーフィールドを示すことができます。

セクション7.1で明示的に許可されていない限り、メッセージヘッダーフィールドをトレーラーに含めることは許可されていません。

受信者が受け入れ可能な転送コーディングにチャンク転送コーディングが含まれている場合、サーバーはチャンク転送コーディングを使用してもかまいません (MAY)。トレーラーの存在は、メッセージにTrailerヘッダーフィールドを含めることで示すことができます。

チャンクメッセージボディを受信するアプリケーションは、対応するチャンク拡張がTrailerヘッダーフィールドで定義されていない限り、理解できないチャンク拡張を無視しなければなりません (MUST)。

3.7 Media Types (メディアタイプ)​

HTTPは、データタイプに関するオープンエンド、拡張可能なデータタイピングとタイプネゴシエーションを提供するために、Content-Type（セクション14.17）およびAccept（セクション14.1）ヘッダーフィールドでインターネットメディアタイプ [17] を使用します。

media-type     = type "/" subtype *( ";" parameter )
type           = token
subtype        = token

タイプ、サブタイプ、およびパラメータ属性名は大文字と小文字を区別しません。パラメータ値は、パラメータ名のセマンティクスに応じて、大文字と小文字を区別する場合と区別しない場合があります。線形空白 (LWS) は、タイプとサブタイプの間、および属性とその値の間で使用してはなりません (MUST NOT)。ユーザーエージェントは、メディアタイプパラメータによって識別される文字セットラベル（セクション3.4）を尊重すべきです (SHOULD)。

メディアタイプ値の存在は、HTTPメッセージ内にエンティティボディが存在する必要があることを意味するものではありません。一部のメソッドまたは一部のレスポンスコードのレスポンスメッセージの場合、メッセージにエンティティボディが含まれていなくても、Content-Typeヘッダーフィールドが含まれる場合があります。このようなレスポンスメッセージは、エンティティボディではなく、ヘッダーフィールドを終了する空行で始まります。

3.7.1 Canonicalization and Text Defaults (正規化とテキストのデフォルト)​

標準として登録されたインターネットメディアタイプ "text" メインタイプは、MIMEと同じ規則を採用します。これは、"text" メインタイプのメディアタイプのContent-Typeヘッダーフィールドに "charset" パラメータが含まれていない場合、受信者はそれを文字セット "ISO-8859-1" として扱うべきである (SHOULD) ことを意味します（セクション3.4.1参照）。HTTP内の "text" バイトストリームのデータは "正規形式" (canonical form) で送信されます。つまり、HTTPはCRLF行末シーケンスに対して変換を行いません。

3.7.2 Multipart Types (マルチパートタイプ)​

MIMEは、1つまたは複数のエンティティを単一のメッセージボディ内にカプセル化する多数のマルチパートタイプを提供します。すべてのマルチパートタイプは、MIME [7] のセクション5.1で定義されている共通の構文を共有し、メディアタイプ値の一部として境界パラメータを含まなければなりません (MUST)。メッセージボディ自体はプロトコル要素であるため、2つのボディパート間の行区切りとしてCRLFを使用しなければなりません (MUST)。MIMEとは異なり、HTTP内のマルチパートボディの最後には終了境界区切りが付いていなければなりません (MUST)。

HTTP内では、マルチパートタイプのContent-Locationヘッダーについて、MIMEと同じセマンティクスに従うべきです (SHOULD)。ただし、HTTP内では、Content-Locationヘッダーを持つボディパートは、含まれるメッセージの外部Content-Locationと一致する場合でも、独立したアイデンティティを持つものとして扱われます。

一般に、HTTPはマルチパートボディパートを個別のリソースとして扱い、それぞれに独自のURIがあります。これにより、1つのメッセージ内で複数のリソースを並列または順次送信でき、206（Partial Content）レスポンスをサポートできます。

3.8 Product Tokens (製品トークン)​

製品トークンは、通信アプリケーションがソフトウェア名とバージョンによって自身を識別できるようにするために使用されます。製品トークンを使用するほとんどのフィールドでは、アプリケーションの重要な部分を構成するサブ製品のリストも許可されており、これらはスペースで区切られます。慣例により、製品はアプリケーション内での重要性が高い順にリストされます。

product         = token ["/" product-version]
product-version = token

例：

User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4

製品トークンは短く、重要でないものであるべきです (SHOULD)。広告やその他の不要な情報に使用してはなりません (MUST NOT)。製品バージョンには任意のトークン文字が表示される場合がありますが、そのトークンは製品のバージョンにのみ使用すべきです (SHOULD)（つまり、連続したバージョンは製品バージョントークンの値のみが異なるべきです）。

3.9 Quality Values (品質値)​

HTTPコンテンツネゴシエーション（セクション12）は、さまざまなネゴシエート可能なパラメータの相対的な重要性（"重み"）を示すために短い "浮動小数点" 数を使用します。重みは、0から1の間の実数値に正規化され、0が最小値、1が最大値です。HTTP/1.1アプリケーションは、小数点以下3桁を超える品質値を生成してはなりません (MUST NOT)。ユーザーがこれらの値を構成する場合も、同様に制限すべきです。

qvalue         = ( "0" [ "." 0*3DIGIT ] )
               | ( "1" [ "." 0*3("0") ] )

"品質値" の概念は、任意のコンテンツ（セクション14.1参照）、文字セット（セクション14.2）、コンテンツコーディング（セクション14.3）、言語（セクション14.4）、または転送コーディング（セクション14.39）の選択に適用されます。ただし、簡潔にするために、このセクションで使用される "品質値" という用語は、その品質値に関連付けられたこれらの特性のいずれかを指します。

3.10 Language Tags (言語タグ)​

言語タグは、英語やフランス語などの自然言語を識別し、1つ以上の部分で構成されます：主要言語タグと、場合によっては一連のサブタグ：

language-tag  = primary-tag *( "-" subtag )
primary-tag   = 1*8ALPHA
subtag        = 1*8ALPHA

タグ内ではスペースは許可されず、すべてのタグは大文字と小文字を区別しません。タグの名前空間はIANAによって管理されています。タグの例は次のとおりです：

en, en-US, en-cockney, i-cherokee, x-pig-latin

2文字の主要タグはISO-639言語略語 [34] であり、2文字の最初のサブタグはISO-3166国コード [35] です。（この文書の執筆時点でのISO 639の最後のオフライン版は [35] でしたが、この標準は時間とともに進化し続けると予想されるべきです。）

3.11 Entity Tags (エンティティタグ)​

エンティティタグは、同じリクエストリソースからの複数の表現間の比較に使用されます。エンティティタグは、不透明な引用符付き文字列で構成され、弱い指示子プレフィックスが付いている場合があります（セクション13.3.3参照）。

entity-tag = [ weak ] opaque-tag
weak       = "W/"
opaque-tag = quoted-string

"強いエンティティタグ" (strong entity tag) は、エンティティ値がどのように変更されても、エンティティタグが使用される任意の時点で使用できます。"弱いエンティティタグ" (weak entity tag) は、バイト等価性ではなくエンティティ値のセマンティック等価性で十分な場合の弱い比較にのみ使用されます。

弱いエンティティタグは、弱い比較にのみ使用できます。弱い指示子プレフィックスがない場合、エンティティタグは強いエンティティタグです。

エンティティタグは、それらのエンティティのセマンティクスが等価でない限り、特定のリソースからの2つのエンティティに対して一意でなければなりません (MUST)。

3.12 Range Units (範囲単位)​

HTTP/1.1により、クライアントはレスポンスエンティティの一部（範囲）のみの転送を要求できます。HTTP/1.1は、Range（セクション14.35）、Content-Range（セクション14.16）、およびAccept-Ranges（セクション14.5）ヘッダーフィールドで範囲単位を使用します。エンティティは、さまざまな構造単位に従ってサブ範囲に分解できます。

range-unit       = bytes-unit | other-range-unit
bytes-unit       = "bytes"
other-range-unit = token

HTTP/1.1の唯一の範囲単位は "bytes" です。HTTP/1.1実装は、理解できない範囲単位の仕様を無視してもかまいません (MAY)。

HTTP/1.1は、"bytes" 範囲単位用に登録されています。付録には、他の範囲単位の登録が含まれています。

に最終更新