Changeset 207
- Timestamp:
- Feb 10, 2008, 12:26:19 PM (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r206 r207 495 495 <li class="tocline1">2.1 <a href="#notation.abnf">Augmented BNF</a></li> 496 496 <li class="tocline1">2.2 <a href="#basic.rules">Basic Rules</a></li> 497 <li class="tocline1">2.3 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li> 497 498 </ul> 498 499 </li> … … 985 986 </p> 986 987 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.22"></span> quoted-pair = "\" CHAR 988 </pre><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h2> 989 <p id="rfc.section.2.3.p.1">The ABNF rules below are defined in other parts:</p> 990 <div id="rfc.figure.u.13"></div><pre class="inline"> request-header = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>> 991 response-header = <response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>> 992 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> accept-params = <accept-params, defined in <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 993 entity-body = <entity-body, defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.body" title="Entity Body">Section 4.2</a>> 994 entity-header = <entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>> 995 </pre><div id="rfc.figure.u.15"></div><pre class="inline"> Cache-Control = <Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 996 Pragma = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 997 Warning = <Warning, defined in <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>> 987 998 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 988 999 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="http.version" href="#http.version">HTTP Version</a></h2> … … 996 1007 </p> 997 1008 <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 998 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.23"></span> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT1009 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.23"></span> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 999 1010 </pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. 1000 1011 Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent. … … 1026 1037 "abs_path", "query", and "authority" from that specification: 1027 1038 </p> 1028 <div id="rfc.figure.u.1 4"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> absoluteURI = <absoluteURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>>1039 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> absoluteURI = <absoluteURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3">Section 3</a>> 1029 1040 authority = <authority, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.3"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2">Section 3.2</a>> 1030 1041 fragment = <fragment, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.4"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-4.1">Section 4.1</a>> … … 1034 1045 relativeURI = <relativeURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.8"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-5">Section 5</a>> 1035 1046 uri-host = <host, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.9"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-3.2.2">Section 3.2.2</a>> 1036 </pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2. 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1047 </pre><p id="rfc.section.3.2.1.p.3">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1037 1048 </p> 1038 1049 <p id="rfc.section.3.2.1.p.4"> </p> … … 1046 1057 and semantics for http URLs. 1047 1058 </p> 1048 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.31"></span> http-URL = "http:" "//" uri-host [ ":" port ]1059 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.31"></span> http-URL = "http:" "//" uri-host [ ":" port ] 1049 1060 [ path-absolute [ "?" query ]] 1050 1061 </pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server … … 1065 1076 </p> 1066 1077 <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p> 1067 <div id="rfc.figure.u.1 6"></div><pre class="text"> http://example.com:80/~smith/home.html1078 <div id="rfc.figure.u.19"></div><pre class="text"> http://example.com:80/~smith/home.html 1068 1079 http://EXAMPLE.com/%7Esmith/home.html 1069 1080 http://EXAMPLE.com:/%7esmith/home.html … … 1071 1082 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> 1072 1083 <p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 1073 <div id="rfc.figure.u. 17"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 11231084 <div id="rfc.figure.u.20"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 1074 1085 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1075 1086 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format … … 1086 1097 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar. 1087 1098 </p> 1088 <div id="rfc.figure.u. 18"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> HTTP-date = rfc1123-date | rfc850-date | asctime-date1099 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span> HTTP-date = rfc1123-date | rfc850-date | asctime-date 1089 1100 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 1090 1101 rfc850-date = weekday "," SP date2 SP time SP "GMT" … … 1113 1124 is a property of the message, not of the original entity. 1114 1125 </p> 1115 <div id="rfc.figure.u. 19"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> transfer-coding = "chunked" | transfer-extension1126 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> transfer-coding = "chunked" | transfer-extension 1116 1127 transfer-extension = token *( ";" parameter ) 1117 1128 </pre><p id="rfc.section.3.4.p.3">Parameters are in the form of attribute/value pairs.</p> 1118 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> parameter = attribute "=" value1129 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> parameter = attribute "=" value 1119 1130 attribute = token 1120 1131 value = token | quoted-string … … 1130 1141 </p> 1131 1142 <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry 1132 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3. 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1133 </p> 1134 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3. 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1143 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1144 </p> 1145 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1135 1146 </p> 1136 1147 <p id="rfc.section.3.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. … … 1141 1152 necessary for the recipient to verify that it has received the full message. 1142 1153 </p> 1143 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> Chunked-Body = *chunk1154 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span> Chunked-Body = *chunk 1144 1155 last-chunk 1145 1156 trailer-part … … 1178 1189 </p> 1179 1190 <p id="rfc.section.3.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1180 <div id="rfc.figure.u.2 2"></div><pre class="text"> length := 01191 <div id="rfc.figure.u.25"></div><pre class="text"> length := 0 1181 1192 read chunk-size, chunk-extension (if any) and CRLF 1182 1193 while (chunk-size > 0) { … … 1200 1211 space. By convention, the products are listed in order of their significance for identifying the application. 1201 1212 </p> 1202 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> product = token ["/" product-version]1213 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> product = token ["/" product-version] 1203 1214 product-version = token 1204 1215 </pre><p id="rfc.section.3.5.p.3">Examples:</p> 1205 <div id="rfc.figure.u.2 4"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31216 <div id="rfc.figure.u.27"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1206 1217 Server: Apache/0.8.4 1207 1218 </pre><p id="rfc.section.3.5.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). … … 1210 1221 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="message.types" href="#message.types">Message Types</a></h2> 1211 1222 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1212 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.59"></span> HTTP-message = Request | Response ; HTTP/1.1 messages1223 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.59"></span> HTTP-message = Request | Response ; HTTP/1.1 messages 1213 1224 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of <a href="#RFC2822" id="rfc.xref.RFC2822.2"><cite title="Internet Message Format">[RFC2822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1214 1225 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1215 1226 fields, and possibly a message-body. 1216 1227 </p> 1217 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> generic-message = start-line1228 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> generic-message = start-line 1218 1229 *(message-header CRLF) 1219 1230 CRLF … … 1227 1238 </p> 1228 1239 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1229 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc2822#section-2.1">Section 2.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.3"><cite title="Internet Message Format">[RFC2822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1240 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc2822#section-2.1">Section 2.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.3"><cite title="Internet Message Format">[RFC2822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1230 1241 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1231 1242 each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, … … 1233 1244 forms. 1234 1245 </p> 1235 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> message-header = field-name ":" [ field-value ]1246 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span> message-header = field-name ":" [ field-value ] 1236 1247 field-name = token 1237 1248 field-value = *( field-content | LWS ) … … 1258 1269 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1259 1270 </p> 1260 <div id="rfc.figure.u. 28"></div><pre class="inline"><span id="rfc.iref.g.66"></span> message-body = entity-body1271 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.66"></span> message-body = entity-body 1261 1272 | <entity-body encoded as per Transfer-Encoding> 1262 1273 </pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding … … 1265 1276 <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1266 1277 <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1267 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length1278 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length 1268 1279 and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented 1269 1280 the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response. … … 1325 1336 to the entity being transferred. These header fields apply only to the message being transmitted. 1326 1337 </p> 1327 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.67"></span> general-header = Cache-Control ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>1338 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.67"></span> general-header = Cache-Control ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a> 1328 1339 | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1329 1340 | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> 1330 | Pragma ; <a href="#Part6" id="rfc.xref.Part6. 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>1341 | Pragma ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a> 1331 1342 | Trailer ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.6</a> 1332 1343 | Transfer-Encoding ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.7</a> 1333 1344 | Upgrade ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.8</a> 1334 1345 | Via ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.9</a> 1335 | Warning ; <a href="#Part6" id="rfc.xref.Part6. 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>1346 | Warning ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a> 1336 1347 </pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new 1337 1348 or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize … … 1342 1353 resource, the identifier of the resource, and the protocol version in use. 1343 1354 </p> 1344 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.68"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 5.1</a>1355 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.68"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 5.1</a> 1345 1356 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1346 | request-header ; <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>1347 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1357 | request-header ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> 1358 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1348 1359 CRLF 1349 1360 [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1352 1363 elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1353 1364 </p> 1354 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.69"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF1365 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.69"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1355 1366 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="method" href="#method">Method</a></h3> 1356 1367 <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p> 1357 <div id="rfc.figure.u.3 2"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> Method = token1368 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> Method = token 1358 1369 </pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3> 1359 1370 <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>) and identifies the resource upon which to apply the request. 1360 1371 </p> 1361 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.72"></span> Request-URI = "*"1372 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.72"></span> Request-URI = "*" 1362 1373 | absoluteURI 1363 1374 | ( path-absolute [ "?" query ] ) … … 1367 1378 apply to a resource. One example would be 1368 1379 </p> 1369 <div id="rfc.figure.u.3 4"></div><pre class="text"> OPTIONS * HTTP/1.11380 <div id="rfc.figure.u.37"></div><pre class="text"> OPTIONS * HTTP/1.1 1370 1381 </pre><p id="rfc.section.5.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, 1371 1382 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request … … 1373 1384 Request-Line would be: 1374 1385 </p> 1375 <div id="rfc.figure.u.3 5"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11386 <div id="rfc.figure.u.38"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1376 1387 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1377 1388 </p> 1378 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1389 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1379 1390 </p> 1380 1391 <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute … … 1382 1393 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1383 1394 </p> 1384 <div id="rfc.figure.u.3 6"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.11395 <div id="rfc.figure.u.39"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1385 1396 Host: www.example.org 1386 1397 </pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original … … 1420 1431 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1421 1432 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1422 <div id="rfc.figure.u. 37"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 6.1</a>1433 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 6.1</a> 1423 1434 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1424 | response-header ; <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>1425 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.1 0"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1435 | response-header ; <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> 1436 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1426 1437 CRLF 1427 1438 [ message-body ] ; <a href="#message.body" title="Message Body">Section 4.3</a> … … 1431 1442 CRLF sequence. 1432 1443 </p> 1433 <div id="rfc.figure.u. 38"></div><pre class="inline"><span id="rfc.iref.g.74"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF1444 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.74"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1434 1445 </pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1435 1446 <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1436 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,1447 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1437 1448 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1438 1449 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. … … 1448 1459 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1449 1460 </ul> 1450 <div id="rfc.figure.u. 39"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> Status-Code = 3DIGIT1461 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> Status-Code = 3DIGIT 1451 1462 Reason-Phrase = *<TEXT, excluding CR, LF> 1452 1463 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> … … 1504 1515 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1505 1516 </p> 1506 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1517 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1507 1518 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request. 1508 1519 </p> … … 1529 1540 </p> 1530 1541 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1531 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding1542 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1532 1543 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1533 1544 </p> … … 1547 1558 </p> 1548 1559 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1549 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1560 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1550 1561 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1551 1562 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking … … 1554 1565 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1555 1566 <ul> 1556 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1557 </li> 1558 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.1567 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1568 </li> 1569 <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 1559 1570 </li> 1560 1571 </ul> … … 1600 1611 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 1601 1612 an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding 1602 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1613 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 9.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1603 1614 </li> 1604 1615 </ul> … … 1639 1650 </p> 1640 1651 <p id="rfc.section.8.1.p.2">The Connection header has the following grammar:</p> 1641 <div id="rfc.figure.u.4 0"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span> Connection = "Connection" ":" 1#(connection-token)1652 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span> Connection = "Connection" ":" 1#(connection-token) 1642 1653 connection-token = token 1643 1654 </pre><p id="rfc.section.8.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header … … 1651 1662 of the response. For example, 1652 1663 </p> 1653 <div id="rfc.figure.u.4 1"></div><pre class="text"> Connection: close1664 <div id="rfc.figure.u.44"></div><pre class="text"> Connection: close 1654 1665 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1655 1666 </p> … … 1667 1678 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1668 1679 </p> 1669 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.80"></span> Content-Length = "Content-Length" ":" 1*DIGIT1680 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.80"></span> Content-Length = "Content-Length" ":" 1*DIGIT 1670 1681 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1671 <div id="rfc.figure.u.4 3"></div><pre class="text"> Content-Length: 34951682 <div id="rfc.figure.u.46"></div><pre class="text"> Content-Length: 3495 1672 1683 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. 1673 1684 </p> … … 1684 1695 as orig-date in <a href="http://tools.ietf.org/html/rfc2822#section-3.6.1">Section 3.6.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.4"><cite title="Internet Message Format">[RFC2822]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1685 1696 </p> 1686 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.81"></span> Date = "Date" ":" HTTP-date1697 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.81"></span> Date = "Date" ":" HTTP-date 1687 1698 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1688 <div id="rfc.figure.u.4 5"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1699 <div id="rfc.figure.u.48"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1689 1700 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1690 1701 </p> … … 1722 1733 a single IP address. 1723 1734 </p> 1724 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.82"></span> Host = "Host" ":" uri-host [ ":" port ] ; <a href="#http.url" title="http URL">Section 3.2.2</a>1735 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.82"></span> Host = "Host" ":" uri-host [ ":" port ] ; <a href="#http.url" title="http URL">Section 3.2.2</a> 1725 1736 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1726 1737 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1727 1738 </p> 1728 <div id="rfc.figure.u. 47"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11739 <div id="rfc.figure.u.50"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1729 1740 Host: www.example.org 1730 1741 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 1741 1752 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>). 1742 1753 </p> 1743 <div id="rfc.figure.u. 48"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> TE = "TE" ":" #( t-codings )1754 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> TE = "TE" ":" #( t-codings ) 1744 1755 t-codings = "trailers" | ( transfer-extension [ accept-params ] ) 1745 1756 </pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, … … 1747 1758 </p> 1748 1759 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1749 <div id="rfc.figure.u. 49"></div><pre class="text"> TE: deflate1760 <div id="rfc.figure.u.52"></div><pre class="text"> TE: deflate 1750 1761 TE: 1751 1762 TE: trailers, deflate;q=0.5 … … 1766 1777 <li> 1767 1778 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1768 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.1 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")1779 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.") 1769 1780 </p> 1770 1781 </li> … … 1784 1795 with chunked transfer-coding. 1785 1796 </p> 1786 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.85"></span> Trailer = "Trailer" ":" 1#field-name1797 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.85"></span> Trailer = "Trailer" ":" 1#field-name 1787 1798 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1788 1799 to know which header fields to expect in the trailer. … … 1804 1815 transfer-coding is a property of the message, not of the entity. 1805 1816 </p> 1806 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.86"></span> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding1817 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.86"></span> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 1807 1818 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>. An example is: 1808 1819 </p> 1809 <div id="rfc.figure.u.5 2"></div><pre class="text"> Transfer-Encoding: chunked1820 <div id="rfc.figure.u.55"></div><pre class="text"> Transfer-Encoding: chunked 1810 1821 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1811 1822 </p> … … 1817 1828 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1818 1829 </p> 1819 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.87"></span> Upgrade = "Upgrade" ":" 1#product1830 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.87"></span> Upgrade = "Upgrade" ":" 1#product 1820 1831 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1821 <div id="rfc.figure.u.5 4"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111832 <div id="rfc.figure.u.57"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1822 1833 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1823 1834 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1848 1859 of all senders along the request/response chain. 1849 1860 </p> 1850 <div id="rfc.figure.u.5 5"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> Via = "Via" ":" 1#( received-protocol received-by [ comment ] )1861 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) 1851 1862 received-protocol = [ protocol-name "/" ] protocol-version 1852 1863 protocol-name = token … … 1871 1882 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1872 1883 </p> 1873 <div id="rfc.figure.u.5 6"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1884 <div id="rfc.figure.u.59"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1874 1885 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1875 1886 </p> … … 1877 1888 For example, 1878 1889 </p> 1879 <div id="rfc.figure.u. 57"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1890 <div id="rfc.figure.u.60"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1880 1891 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1881 <div id="rfc.figure.u. 58"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1892 <div id="rfc.figure.u.61"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1882 1893 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1883 1894 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2311 2322 </p> 2312 2323 <p id="rfc.section.B.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2313 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2324 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2314 2325 </p> 2315 2326 <p id="rfc.section.B.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2394 2405 <p id="rfc.section.D.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2395 2406 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2396 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.1 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2407 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.4</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.16"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2397 2408 </p> 2398 2409 <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 2498 2509 <li>Get rid of unused rules LOALPHA and UPALPHA.</li> 2499 2510 <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li> 2511 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 2500 2512 </ul> 2501 2513 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 2698 2710 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2699 2711 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li> 2700 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1"> 3.2.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.3</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a>, <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a>, <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind">2701 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2. 4">4.3</a></li>2702 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2. 2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a></li>2703 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2. 3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li>2704 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2. 9">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.10">7.1.4</a></li>2705 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2. 6">5.1.2</a></li>2706 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2. 8">6.1.1</a></li>2707 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.1 1">7.2.3</a></li>2708 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.1 4">7.2.3</a></li>2709 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2. 1">3.2.1</a></li>2710 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.1 2">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>2712 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">3.2.1</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">4.3</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind"> 2713 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.6">4.3</a></li> 2714 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">5</a></li> 2715 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.2">2.3</a>, <a class="iref" href="#rfc.xref.Part2.5">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li> 2716 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li> 2717 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li> 2718 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a></li> 2719 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li> 2720 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li> 2721 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.3">3.2.1</a></li> 2722 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li> 2711 2723 </ul> 2712 2724 </li> 2713 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6"> 3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">B</a>, <a class="iref" href="#rfc.xref.Part3.13">D.3</a><ul class="ind">2714 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3. 6">3.4</a>, <a class="iref" href="#rfc.xref.Part3.7">3.4</a></li>2725 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a>, <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.4</a>, <a class="iref" href="#rfc.xref.Part3.5">2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">2.3</a>, <a class="iref" href="#rfc.xref.Part3.7">2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">2.3</a>, <a class="iref" href="#rfc.xref.Part3.9">3.4</a>, <a class="iref" href="#rfc.xref.Part3.10">3.4</a>, <a class="iref" href="#rfc.xref.Part3.11">4.2</a>, <a class="iref" href="#rfc.xref.Part3.12">5</a>, <a class="iref" href="#rfc.xref.Part3.13">6</a>, <a class="iref" href="#rfc.xref.Part3.14">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.15">B</a>, <a class="iref" href="#rfc.xref.Part3.16">D.3</a><ul class="ind"> 2726 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3.9">3.4</a>, <a class="iref" href="#rfc.xref.Part3.10">3.4</a></li> 2715 2727 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part3.5">2.2</a></li> 2716 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.1 1">8.5</a></li>2728 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.14">8.5</a></li> 2717 2729 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.1">1.3</a></li> 2718 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li> 2730 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.8">2.3</a>, <a class="iref" href="#rfc.xref.Part3.11">4.2</a>, <a class="iref" href="#rfc.xref.Part3.12">5</a>, <a class="iref" href="#rfc.xref.Part3.13">6</a></li> 2731 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part3.7">2.3</a></li> 2719 2732 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.2">1.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.3</a></li> 2733 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.6">2.3</a></li> 2720 2734 <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part3.4">1.4</a></li> 2721 2735 </ul> 2722 2736 </li> 2723 2737 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">D.3</a></li> 2724 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a>, <a class="iref" href="#rfc.xref.Part6.3"> 4.5</a>, <a class="iref" href="#rfc.xref.Part6.4">4.5</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.6">D.3</a><ul class="ind">2738 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a>, <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.5">2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#rfc.xref.Part6.8">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.9">D.3</a><ul class="ind"> 2725 2739 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.1">1.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.4</a></li> 2726 <li class="indline1"><em>Section 16.2</em> <a class="iref" href="#rfc.xref.Part6. 3">4.5</a></li>2727 <li class="indline1"><em>Section 16.4</em> <a class="iref" href="#rfc.xref.Part6. 4">4.5</a></li>2728 <li class="indline1"><em>Section 16.6</em> <a class="iref" href="#rfc.xref.Part6.5"> 4.5</a></li>2740 <li class="indline1"><em>Section 16.2</em> <a class="iref" href="#rfc.xref.Part6.6">4.5</a></li> 2741 <li class="indline1"><em>Section 16.4</em> <a class="iref" href="#rfc.xref.Part6.3">2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a></li> 2742 <li class="indline1"><em>Section 16.6</em> <a class="iref" href="#rfc.xref.Part6.5">2.3</a>, <a class="iref" href="#rfc.xref.Part6.8">4.5</a></li> 2729 2743 </ul> 2730 2744 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r206 r207 23 23 <!ENTITY diff2045entity "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY entity "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 <!ENTITY entity-body "<xref target='Part3' x:rel='#entity.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 26 <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 <!ENTITY header-accept "<xref target='Part3' x:rel='#header.accept' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 28 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 29 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 939 941 </artwork></figure> 940 942 </section> 943 944 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 945 <t> 946 The ABNF rules below are defined in other parts: 947 </t> 948 <figure><!-- Part2--><artwork type="abnf2616"> 949 request-header = <request-header, defined in &request-header-fields;> 950 response-header = <response-header, defined in &response-header-fields;> 951 </artwork></figure> 952 <figure><!-- Part3--><artwork type="abnf2616"> 953 accept-params = <accept-params, defined in &header-accept;> 954 entity-body = <entity-body, defined in &entity-body;> 955 entity-header = <entity-header, defined in &entity-header-fields;> 956 </artwork></figure> 957 <figure><!-- Part6--><artwork type="abnf2616"> 958 Cache-Control = <Cache-Control, defined in &header-pragma;> 959 Pragma = <Pragma, defined in &header-pragma;> 960 Warning = <Warning, defined in &header-warning;> 961 </artwork></figure> 962 </section> 963 941 964 </section> 942 965 … … 4263 4286 in the definition of the Upgrade header. 4264 4287 </t> 4288 <t> 4289 Add explicit references to BNF syntax and rules imported from other parts of the specification. 4290 </t> 4265 4291 </list> 4266 4292 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r206 r207 633 633 quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 634 634 token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 635 </pre><p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 635 </pre><div id="abnf.dependencies"> 636 <p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 637 </div> 636 638 <div id="rfc.figure.u.3"></div><pre class="inline"> absoluteURI = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 637 Accept = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 639 fragment = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 640 Host = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a>> 641 HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> 642 product = <product, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</a>> 643 relativeURI = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 644 TE = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>> 645 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> Accept = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> 638 646 Accept-Charset = 639 647 <Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>> … … 642 650 Accept-Language = 643 651 <Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>> 644 Accept-Ranges = <Accept-Ranges, defined in <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a>> 645 Age = <Age, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a>> 646 Authorization = <Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a>> 647 delta-seconds = <delta-seconds, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a>> 648 ETag = <ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a>> 649 fragment = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 650 HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> 651 Host = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a>> 652 </pre><div id="rfc.figure.u.5"></div><pre class="inline"> ETag = <ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a>> 652 653 If-Match = <If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 7.2</a>> 653 654 If-Modified-Since = 654 655 <If-Modified-Since, defined in <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 7.3</a>> 655 656 If-None-Match = <If-None-Match, defined in <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 7.4</a>> 656 If-Range = <If-Range, defined in <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</a>>657 657 If-Unmodified-Since = 658 658 <If-Unmodified-Since, defined in <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 7.5</a>> 659 product = <product, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</a>> 659 </pre><div id="rfc.figure.u.6"></div><pre class="inline"> Accept-Ranges = <Accept-Ranges, defined in <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a>> 660 If-Range = <If-Range, defined in <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.if-range" title="If-Range">Section 6.3</a>> 661 Range = <Range, defined in <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 6.4</a>> 662 </pre><div id="rfc.figure.u.7"></div><pre class="inline"> Age = <Age, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a>> 663 delta-seconds = <delta-seconds, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a>> 664 Vary = <Vary, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 16.5</a>> 665 </pre><div id="rfc.figure.u.8"></div><pre class="inline"> Authorization = <Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a>> 660 666 Proxy-Authenticate = 661 667 <Proxy-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a>> 662 668 Proxy-Authorization = 663 669 <Proxy-Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a>> 664 Range = <Range, defined in <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 6.4</a>>665 relativeURI = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>>666 TE = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>>667 Vary = <Vary, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 16.5</a>>668 670 WWW-Authenticate = 669 671 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> 670 672 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1> 671 673 <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p> 672 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a>674 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> 673 675 | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> 674 676 | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a> … … 690 692 method invocation. 691 693 </p> 692 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.3"></span> request-header = Accept ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>694 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.3"></span> request-header = Accept ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> 693 695 | Accept-Charset ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> 694 696 | Accept-Encoding ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> … … 721 723 are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol. 722 724 </p> 723 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> Status-Code =725 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> Status-Code = 724 726 "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue 725 727 | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols … … 777 779 the Request-URI. 778 780 </p> 779 <div id="rfc.figure.u. 7"></div><pre class="inline"><span id="rfc.iref.g.7"></span> response-header = Accept-Ranges ; <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a>781 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span> response-header = Accept-Ranges ; <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a> 780 782 | Age ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 16.1</a> 781 783 | ETag ; <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 7.1</a> … … 1387 1389 of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. 1388 1390 </p> 1389 <div id="rfc.figure.u. 8"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Allow = "Allow" ":" #Method1391 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Allow = "Allow" ":" #Method 1390 1392 </pre><p id="rfc.section.10.1.p.3">Example of use:</p> 1391 <div id="rfc.figure.u. 9"></div><pre class="text"> Allow: GET, HEAD, PUT1393 <div id="rfc.figure.u.14"></div><pre class="text"> Allow: GET, HEAD, PUT 1392 1394 </pre><p id="rfc.section.10.1.p.5">This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value <em class="bcp14">SHOULD</em> be followed. The actual set of allowed methods is defined by the origin server at the time of each request. 1393 1395 </p> … … 1402 1404 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1403 1405 <p id="rfc.section.10.2.p.1">The Expect request-header field is used to indicate that particular server behaviors are required by the client.</p> 1404 <div id="rfc.figure.u.1 0"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> Expect = "Expect" ":" 1#expectation1406 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> Expect = "Expect" ":" 1#expectation 1405 1407 1406 1408 expectation = "100-continue" | expectation-extension … … 1428 1430 <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc2822#section-3.4">Section 3.4</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.1"><cite title="Internet Message Format">[RFC2822]</cite></a>: 1429 1431 </p> 1430 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.14"></span> From = "From" ":" mailbox1432 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.14"></span> From = "From" ":" mailbox 1431 1433 1432 1434 mailbox = <mailbox, defined in <a href="#RFC2822" id="rfc.xref.RFC2822.2"><cite title="Internet Message Format">[RFC2822]</cite></a>, <a href="http://tools.ietf.org/html/rfc2822#section-3.4">Section 3.4</a>> 1433 1435 </pre><p id="rfc.section.10.3.p.3">An example is:</p> 1434 <div id="rfc.figure.u.1 2"></div><pre class="text"> From: webmaster@example.org1436 <div id="rfc.figure.u.17"></div><pre class="text"> From: webmaster@example.org 1435 1437 </pre><p id="rfc.section.10.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 1436 1438 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving … … 1452 1454 URI. 1453 1455 </p> 1454 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.15"></span> Location = "Location" ":" absoluteURI [ "#" fragment ]1456 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.15"></span> Location = "Location" ":" absoluteURI [ "#" fragment ] 1455 1457 </pre><p id="rfc.section.10.4.p.3">An example is:</p> 1456 <div id="rfc.figure.u.1 4"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html1458 <div id="rfc.figure.u.19"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1457 1459 </pre><p id="rfc.section.10.4.p.5"> </p> 1458 1460 <dl class="empty"> … … 1475 1477 useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. 1476 1478 </p> 1477 <div id="rfc.figure.u. 15"></div><pre class="inline"><span id="rfc.iref.g.16"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT1479 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1478 1480 </pre><p id="rfc.section.10.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p> 1479 1481 <p id="rfc.section.10.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). … … 1490 1492 obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. 1491 1493 </p> 1492 <div id="rfc.figure.u. 16"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI )1494 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1493 1495 </pre><p id="rfc.section.10.6.p.3">Example:</p> 1494 <div id="rfc.figure.u. 17"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html1496 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1495 1497 </pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations. 1496 1498 </p> … … 1503 1505 the time of the response. 1504 1506 </p> 1505 <div id="rfc.figure.u. 18"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )1507 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1506 1508 </pre><p id="rfc.section.10.7.p.3">Two examples of its use are</p> 1507 <div id="rfc.figure.u. 19"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT1509 <div id="rfc.figure.u.24"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1508 1510 Retry-After: 120 1509 1511 </pre><p id="rfc.section.10.7.p.5">In the latter example, the delay is 2 minutes.</p> … … 1515 1517 for identifying the application. 1516 1518 </p> 1517 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Server = "Server" ":" 1*( product | comment )1519 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Server = "Server" ":" 1*( product | comment ) 1518 1520 </pre><p id="rfc.section.10.8.p.3">Example:</p> 1519 <div id="rfc.figure.u.2 1"></div><pre class="text"> Server: CERN/3.0 libwww/2.171521 <div id="rfc.figure.u.26"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1520 1522 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1521 1523 </p> … … 1534 1536 product tokens are listed in order of their significance for identifying the application. 1535 1537 </p> 1536 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.20"></span> User-Agent = "User-Agent" ":" 1*( product | comment )1538 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.20"></span> User-Agent = "User-Agent" ":" 1*( product | comment ) 1537 1539 </pre><p id="rfc.section.10.9.p.3">Example:</p> 1538 <div id="rfc.figure.u.2 3"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31540 <div id="rfc.figure.u.28"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1539 1541 </pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1540 1542 <p id="rfc.section.11.p.1"> <span class="comment">[rfc.comment.1: TBD.]</span> … … 1948 1950 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.20">9.5.6</a></li> 1949 1951 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a></li> 1950 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.1 0">2</a></li>1952 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.11">2</a></li> 1951 1953 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.22">10.8</a>, <a class="iref" href="#rfc.xref.Part1.24">10.9</a></li> 1952 1954 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.17">7</a></li> 1953 1955 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.19">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.21">10.2</a></li> 1954 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.1 1">2</a>, <a class="iref" href="#rfc.xref.Part1.15">4</a></li>1956 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.15">4</a></li> 1955 1957 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.16">4</a></li> 1956 1958 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.18">8.8</a>, <a class="iref" href="#rfc.xref.Part1.23">10.8</a>, <a class="iref" href="#rfc.xref.Part1.25">A.2</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r206 r207 305 305 token = <token, defined in &basic-rules;> 306 306 </artwork></figure> 307 <t >307 <t anchor="abnf.dependencies"> 308 308 The ABNF rules below are defined in other parts: 309 309 </t> 310 <figure>< artwork type="abnf2616">310 <figure><!--Part1--><artwork type="abnf2616"> 311 311 absoluteURI = <absoluteURI, defined in &general-syntax;> 312 fragment = <fragment, defined in &general-syntax;> 313 Host = <Host, defined in &header-host;> 314 HTTP-date = <HTTP-date, defined in &full-date;> 315 product = <product, defined in &product-tokens;> 316 relativeURI = <relativeURI, defined in &general-syntax;> 317 TE = <TE, defined in &header-te;> 318 </artwork></figure> 319 <figure><!--Part3--><artwork type="abnf2616"> 312 320 Accept = <Accept, defined in &header-accept;> 313 321 Accept-Charset = … … 317 325 Accept-Language = 318 326 <Accept-Language, defined in &header-accept-language;> 319 Accept-Ranges = <Accept-Ranges, defined in &header-accept-ranges;> 320 Age = <Age, defined in &header-age;> 321 Authorization = <Authorization, defined in &header-authorization;> 322 delta-seconds = <delta-seconds, defined in &header-age;> 327 </artwork></figure> 328 <figure><!--Part4--><artwork type="abnf2616"> 323 329 ETag = <ETag, defined in &header-etag;> 324 fragment = <fragment, defined in &general-syntax;>325 HTTP-date = <HTTP-date, defined in &full-date;>326 Host = <Host, defined in &header-host;>327 330 If-Match = <If-Match, defined in &header-if-match;> 328 331 If-Modified-Since = 329 332 <If-Modified-Since, defined in &header-if-modified-since;> 330 333 If-None-Match = <If-None-Match, defined in &header-if-none-match;> 331 If-Range = <If-Range, defined in &header-if-range;>332 334 If-Unmodified-Since = 333 335 <If-Unmodified-Since, defined in &header-if-unmodified-since;> 334 product = <product, defined in &product-tokens;> 336 </artwork></figure> 337 <figure><!--Part5--><artwork type="abnf2616"> 338 Accept-Ranges = <Accept-Ranges, defined in &header-accept-ranges;> 339 If-Range = <If-Range, defined in &header-if-range;> 340 Range = <Range, defined in &header-range;> 341 </artwork></figure> 342 <figure><!--Part6--><artwork type="abnf2616"> 343 Age = <Age, defined in &header-age;> 344 delta-seconds = <delta-seconds, defined in &header-age;> 345 Vary = <Vary, defined in &header-vary;> 346 </artwork><!--Part7--></figure> 347 <figure><artwork type="abnf2616"> 348 Authorization = <Authorization, defined in &header-authorization;> 335 349 Proxy-Authenticate = 336 350 <Proxy-Authenticate, defined in &header-proxy-authenticate;> 337 351 Proxy-Authorization = 338 352 <Proxy-Authorization, defined in &header-proxy-authorization;> 339 Range = <Range, defined in &header-range;>340 relativeURI = <relativeURI, defined in &general-syntax;>341 TE = <TE, defined in &header-te;>342 Vary = <Vary, defined in &header-vary;>343 353 WWW-Authenticate = 344 354 <WWW-Authenticate, defined in &header-www-authenticate;> -
draft-ietf-httpbis/latest/p3-payload.html
r206 r207 592 592 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 593 593 token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 594 </pre><p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 594 </pre><div id="abnf.dependencies"> 595 <p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 596 </div> 595 597 <div id="rfc.figure.u.3"></div><pre class="inline"> absoluteURI = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 596 Allow = <Allow, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 10.1</a>>597 598 Content-Length = <Content-Length, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a>> 598 Content-Range = <Content-Range, defined in <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 6.2</a>> 599 Expires = <Expires, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 16.3</a>> 600 Last-Modified = <Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 7.6</a>> 601 message-header = <message-header, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 602 relativeURI = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 599 relativeURI = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#general.syntax" title="General Syntax">Section 3.2.1</a>> 600 message-header = <message-header, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 601 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> Allow = <Allow, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 10.1</a>> 602 </pre><div id="rfc.figure.u.5"></div><pre class="inline"> Last-Modified = <Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 7.6</a>> 603 </pre><div id="rfc.figure.u.6"></div><pre class="inline"> Content-Range = <Content-Range, defined in <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 6.2</a>> 604 </pre><div id="rfc.figure.u.7"></div><pre class="inline"> Expires = <Expires, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 16.3</a>> 603 605 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 604 606 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="character.sets" href="#character.sets">Character Sets</a></h2> … … 620 622 Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>). 621 623 </p> 622 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.1"></span> charset = token624 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span> charset = token 623 625 </pre><p id="rfc.section.3.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 624 626 Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry. … … 643 645 decoded by the recipient. 644 646 </p> 645 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.2"></span> content-coding = token647 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.2"></span> content-coding = token 646 648 </pre><p id="rfc.section.3.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 647 649 mechanism will be required to remove the encoding. … … 687 689 <p id="rfc.section.3.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 6.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 688 690 </p> 689 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> media-type = type "/" subtype *( ";" parameter )691 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> media-type = type "/" subtype *( ";" parameter ) 690 692 type = token 691 693 subtype = token 692 694 </pre><p id="rfc.section.3.3.p.3">Parameters <em class="bcp14">MAY</em> follow the type/subtype in the form of attribute/value pairs. 693 695 </p> 694 <div id="rfc.figure.u. 7"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> parameter = attribute "=" value696 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> parameter = attribute "=" value 695 697 attribute = token 696 698 value = token | quoted-string … … 745 747 a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 746 748 </p> 747 <div id="rfc.figure.u. 8"></div><pre class="inline"><span id="rfc.iref.g.10"></span> qvalue = ( "0" [ "." 0*3DIGIT ] )749 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span> qvalue = ( "0" [ "." 0*3DIGIT ] ) 748 750 | ( "1" [ "." 0*3("0") ] ) 749 751 </pre><p id="rfc.section.3.4.p.3">"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.</p> … … 755 757 <p id="rfc.section.3.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags: 756 758 </p> 757 <div id="rfc.figure.u. 9"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> language-tag = primary-tag *( "-" subtag )759 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> language-tag = primary-tag *( "-" subtag ) 758 760 primary-tag = 1*8ALPHA 759 761 subtag = 1*8ALPHA … … 761 763 by the IANA. Example tags include: 762 764 </p> 763 <div id="rfc.figure.u.1 0"></div><pre class="text"> en, en-US, en-cockney, i-cherokee, x-pig-latin765 <div id="rfc.figure.u.14"></div><pre class="text"> en, en-US, en-cockney, i-cherokee, x-pig-latin 764 766 </pre><p id="rfc.section.3.5.p.6">where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country 765 767 code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered … … 777 779 by the request. 778 780 </p> 779 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 10.1</a>781 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 10.1</a> 780 782 | Content-Encoding ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 6.5</a> 781 783 | Content-Language ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 6.6</a> … … 795 797 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2> 796 798 <p id="rfc.section.4.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 797 <div id="rfc.figure.u.1 2"></div><pre class="inline"><span id="rfc.iref.g.16"></span> entity-body = *OCTET799 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.16"></span> entity-body = *OCTET 798 800 </pre><p id="rfc.section.4.2.p.3">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 799 801 safe and proper transfer of the message. … … 803 805 and Content-Encoding. These define a two-layer, ordered encoding model: 804 806 </p> 805 <div id="rfc.figure.u.1 3"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) )807 <div id="rfc.figure.u.17"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) ) 806 808 </pre><p id="rfc.section.4.2.1.p.3">Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content 807 809 codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. There … … 907 909 for an in-line image. 908 910 </p> 909 <div id="rfc.figure.u.1 4"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> Accept = "Accept" ":"911 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> Accept = "Accept" ":" 910 912 #( media-range [ accept-params ] ) 911 913 … … 931 933 </dl> 932 934 <p id="rfc.section.6.1.p.5">The example</p> 933 <div id="rfc.figure.u.1 5"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic935 <div id="rfc.figure.u.19"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 934 936 </pre><p id="rfc.section.6.1.p.7"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 935 937 quality." … … 940 942 </p> 941 943 <p id="rfc.section.6.1.p.9">A more elaborate example is</p> 942 <div id="rfc.figure.u. 16"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,944 <div id="rfc.figure.u.20"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 943 945 text/x-dvi; q=0.8, text/x-c 944 946 </pre><p id="rfc.section.6.1.p.11">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then … … 948 950 to a given type, the most specific reference has precedence. For example, 949 951 </p> 950 <div id="rfc.figure.u. 17"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */*952 <div id="rfc.figure.u.21"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 951 953 </pre><p id="rfc.section.6.1.p.14">have the following precedence:</p> 952 <div id="rfc.figure.u. 18"></div><pre class="text"> 1) text/html;level=1954 <div id="rfc.figure.u.22"></div><pre class="text"> 1) text/html;level=1 953 955 2) text/html 954 956 3) text/* … … 957 959 which matches that type. For example, 958 960 </p> 959 <div id="rfc.figure.u. 19"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,961 <div id="rfc.figure.u.23"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 960 962 text/html;level=2;q=0.4, */*;q=0.5 961 963 </pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p> 962 <div id="rfc.figure.u.2 0"></div><pre class="text"> text/html;level=1 = 1964 <div id="rfc.figure.u.24"></div><pre class="text"> text/html;level=1 = 1 963 965 text/html = 0.7 964 966 text/plain = 0.3 … … 976 978 to a server which is capable of representing documents in those character sets. 977 979 </p> 978 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Accept-Charset = "Accept-Charset" ":"980 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Accept-Charset = "Accept-Charset" ":" 979 981 1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] ) 980 982 </pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section 3.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 981 983 example is 982 984 </p> 983 <div id="rfc.figure.u.2 2"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8985 <div id="rfc.figure.u.26"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 984 986 </pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is 985 987 not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets … … 995 997 <p id="rfc.section.6.3.p.1">The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section 3.2</a>) that are acceptable in the response. 996 998 </p> 997 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> Accept-Encoding = "Accept-Encoding" ":"999 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> Accept-Encoding = "Accept-Encoding" ":" 998 1000 #( codings [ ";" "q" "=" qvalue ] ) 999 1001 codings = ( content-coding | "*" ) 1000 1002 </pre><p id="rfc.section.6.3.p.3">Examples of its use are:</p> 1001 <div id="rfc.figure.u.2 4"></div><pre class="text"> Accept-Encoding: compress, gzip1003 <div id="rfc.figure.u.28"></div><pre class="text"> Accept-Encoding: compress, gzip 1002 1004 Accept-Encoding: 1003 1005 Accept-Encoding: * … … 1041 1043 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 3.5</a>. 1042 1044 </p> 1043 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> Accept-Language = "Accept-Language" ":"1045 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> Accept-Language = "Accept-Language" ":" 1044 1046 1#( language-range [ ";" "q" "=" qvalue ] ) 1045 1047 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) … … 1047 1049 that range. The quality value defaults to "q=1". For example, 1048 1050 </p> 1049 <div id="rfc.figure.u. 26"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71051 <div id="rfc.figure.u.30"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1050 1052 </pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag 1051 1053 if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the … … 1085 1087 without losing the identity of its underlying media type. 1086 1088 </p> 1087 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.26"></span> Content-Encoding = "Content-Encoding" ":" 1#content-coding1089 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.26"></span> Content-Encoding = "Content-Encoding" ":" 1#content-coding 1088 1090 </pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 3.2</a>. An example of its use is 1089 1091 </p> 1090 <div id="rfc.figure.u. 28"></div><pre class="text"> Content-Encoding: gzip1092 <div id="rfc.figure.u.32"></div><pre class="text"> Content-Encoding: gzip 1091 1093 </pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with 1092 1094 this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control … … 1105 1107 Note that this might not be equivalent to all the languages used within the entity-body. 1106 1108 </p> 1107 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.27"></span> Content-Language = "Content-Language" ":" 1#language-tag1109 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.27"></span> Content-Language = "Content-Language" ":" 1#language-tag 1108 1110 </pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 3.5</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's 1109 1111 own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is 1110 1112 </p> 1111 <div id="rfc.figure.u.3 0"></div><pre class="text"> Content-Language: da1113 <div id="rfc.figure.u.34"></div><pre class="text"> Content-Language: da 1112 1114 </pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1113 1115 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language … … 1117 1119 simultaneously in the original Maori and English versions, would call for 1118 1120 </p> 1119 <div id="rfc.figure.u.3 1"></div><pre class="text"> Content-Language: mi, en1121 <div id="rfc.figure.u.35"></div><pre class="text"> Content-Language: mi, en 1120 1122 </pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic 1121 1123 audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended … … 1132 1134 accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned. 1133 1135 </p> 1134 <div id="rfc.figure.u.3 2"></div><pre class="inline"><span id="rfc.iref.g.28"></span> Content-Location = "Content-Location" ":"1136 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.28"></span> Content-Location = "Content-Location" ":" 1135 1137 ( absoluteURI | relativeURI ) 1136 1138 </pre><p id="rfc.section.6.7.p.3">The value of Content-Location also defines the base URI for the entity.</p> … … 1151 1153 attacks.) 1152 1154 </p> 1153 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest1155 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest 1154 1156 md5-digest = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1155 1157 </pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including … … 1188 1190 the HEAD method, the media type that would have been sent had the request been a GET. 1189 1191 </p> 1190 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.31"></span> Content-Type = "Content-Type" ":" media-type1192 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.31"></span> Content-Type = "Content-Type" ":" media-type 1191 1193 </pre><p id="rfc.section.6.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 3.3</a>. An example of the field is 1192 1194 </p> 1193 <div id="rfc.figure.u.3 5"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41195 <div id="rfc.figure.u.39"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1194 1196 </pre><p id="rfc.section.6.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section 4.2.1</a>. 1195 1197 </p> … … 1407 1409 environments. 1408 1410 </p> 1409 <div id="rfc.figure.u. 36"></div><pre class="inline"><span id="rfc.iref.g.32"></span> MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT1411 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.32"></span> MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT 1410 1412 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this 1411 1413 document and not the MIME specification. … … 1461 1463 in <a href="#RFC1806" id="rfc.xref.RFC1806.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>. 1462 1464 </p> 1463 <div id="rfc.figure.u. 37"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> content-disposition = "Content-Disposition" ":"1465 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> content-disposition = "Content-Disposition" ":" 1464 1466 disposition-type *( ";" disposition-parm ) 1465 1467 disposition-type = "attachment" | disp-extension-token … … 1469 1471 disp-extension-parm = token "=" ( token | quoted-string ) 1470 1472 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1471 <div id="rfc.figure.u. 38"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext"1473 <div id="rfc.figure.u.42"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1472 1474 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1473 1475 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. … … 1679 1681 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 1680 1682 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 1681 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.1 1">2</a></li>1682 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.1 0">2</a></li>1683 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a></li> 1684 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.11">2</a></li> 1683 1685 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.13">4.2</a></li> 1684 1686 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.14">4.2.2</a></li> -
draft-ietf-httpbis/latest/p3-payload.xml
r206 r207 271 271 token = <token, defined in &basic-rules;> 272 272 </artwork></figure> 273 <t >273 <t anchor="abnf.dependencies"> 274 274 The ABNF rules below are defined in other parts: 275 275 </t> 276 <figure>< artwork type="abnf2616">276 <figure><!--Part1--><artwork type="abnf2616"> 277 277 absoluteURI = <absoluteURI, defined in &general-syntax;> 278 Content-Length = <Content-Length, defined in &header-content-length;> 279 relativeURI = <relativeURI, defined in &general-syntax;> 280 message-header = <message-header, defined in &message-headers;> 281 </artwork></figure> 282 <figure><!--Part2--><artwork type="abnf2616"> 278 283 Allow = <Allow, defined in &header-allow;> 279 Content-Length = <Content-Length, defined in &header-content-length;> 284 </artwork></figure> 285 <figure><!--Part4--><artwork type="abnf2616"> 286 Last-Modified = <Last-Modified, defined in &header-last-modified;> 287 </artwork></figure> 288 <figure><!--Part5--><artwork type="abnf2616"> 280 289 Content-Range = <Content-Range, defined in &header-content-range;> 290 </artwork></figure> 291 <figure><!--Part6--><artwork type="abnf2616"> 281 292 Expires = <Expires, defined in &header-expires;> 282 Last-Modified = <Last-Modified, defined in &header-last-modified;>283 message-header = <message-header, defined in &message-headers;>284 relativeURI = <relativeURI, defined in &general-syntax;>285 293 </artwork></figure> 286 294 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r205 r207 547 547 </p> 548 548 <div id="rfc.figure.u.1"></div><pre class="inline"> quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 549 </pre><p id="rfc.section.2.p.3">The ABNF rules below are defined in other parts:</p> 549 </pre><div id="abnf.dependencies"> 550 <p id="rfc.section.2.p.3">The ABNF rules below are defined in other parts:</p> 551 </div> 550 552 <div id="rfc.figure.u.2"></div><pre class="inline"> HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> 551 553 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="entity.tags" href="#entity.tags">Entity Tags</a></h1> -
draft-ietf-httpbis/latest/p4-conditional.xml
r205 r207 263 263 quoted-string = <quoted-string, defined in &basic-rules;> 264 264 </artwork></figure> 265 <t >265 <t anchor="abnf.dependencies"> 266 266 The ABNF rules below are defined in other parts: 267 267 </t> 268 <figure>< artwork type="abnf2616">268 <figure><!--Part1--><artwork type="abnf2616"> 269 269 HTTP-date = <HTTP-date, defined in &full-date;> 270 270 </artwork></figure> -
draft-ietf-httpbis/latest/p5-range.html
r205 r207 553 553 SP = <SP, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 554 554 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 555 </pre><p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 555 </pre><div id="abnf.dependencies"> 556 <p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 557 </div> 556 558 <div id="rfc.figure.u.3"></div><pre class="inline"> HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> 557 559 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> entity-tag = <entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 3</a>> -
draft-ietf-httpbis/latest/p5-range.xml
r205 r207 268 268 token = <token, defined in &basic-rules;> 269 269 </artwork></figure> 270 <t >270 <t anchor="abnf.dependencies"> 271 271 The ABNF rules below are defined in other parts: 272 272 </t> 273 <figure>< artwork type="abnf2616">273 <figure><!--Part1--><artwork type="abnf2616"> 274 274 HTTP-date = <HTTP-date, defined in &full-date;> 275 275 </artwork></figure> 276 <figure>< artwork type="abnf2616">276 <figure><!--Part4--><artwork type="abnf2616"> 277 277 entity-tag = <entity-tag, defined in &entity-tags;> 278 278 </artwork></figure> -
draft-ietf-httpbis/latest/p6-cache.html
r205 r207 685 685 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 686 686 token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 687 </pre><p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 687 </pre><div id="abnf.dependencies"> 688 <p id="rfc.section.2.p.4">The ABNF rules below are defined in other parts:</p> 689 </div> 688 690 <div id="rfc.figure.u.3"></div><pre class="inline"> field-name = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 689 691 HTTP-date = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.3.1</a>> -
draft-ietf-httpbis/latest/p6-cache.xml
r205 r207 444 444 token = <token, defined in &basic-rules;> 445 445 </artwork></figure> 446 <t >446 <t anchor="abnf.dependencies"> 447 447 The ABNF rules below are defined in other parts: 448 448 </t> 449 <figure>< artwork type="abnf2616">449 <figure><!--Part1--><artwork type="abnf2616"> 450 450 field-name = <field-name, defined in &message-headers;> 451 451 HTTP-date = <HTTP-date, defined in &full-date;> -
draft-ietf-httpbis/latest/p7-auth.html
r205 r207 537 537 <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="Augmented BNF">Section 2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 5234, see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>.]</span> 538 538 </p> 539 <p id="rfc.section.2.p.2">The ABNF rules below are defined in other specifications:</p> 539 <div id="abnf.dependencies"> 540 <p id="rfc.section.2.p.2">The ABNF rules below are defined in other specifications:</p> 541 </div> 540 542 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> challenge = <challenge, defined in <a href="#RFC2617" id="rfc.xref.RFC2617.3"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a>> 541 543 credentials = <credentials, defined in <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a>> -
draft-ietf-httpbis/latest/p7-auth.xml
r205 r207 249 249 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>.</cref> 250 250 </t> 251 <t >251 <t anchor="abnf.dependencies"> 252 252 The ABNF rules below are defined in other specifications: 253 253 </t>
Note: See TracChangeset
for help on using the changeset viewer.