![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 190
- Timestamp:
- 03/02/08 19:07:03 (15 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
-
p1-messaging.html (modified) (40 diffs)
-
p1-messaging.xml (modified) (2 diffs)
-
p2-semantics.html (modified) (37 diffs)
-
p2-semantics.xml (modified) (5 diffs)
-
p3-payload.html (modified) (3 diffs)
-
p6-cache.html (modified) (2 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r189 r190 513 513 </ul> 514 514 </li> 515 <li class="tocline1">3.5 <a href="#product.tokens">Product Tokens</a></li> 515 516 </ul> 516 517 </li> … … 1032 1033 relativeURI = <relativeURI, defined in <a href="#RFC2396" id="rfc.xref.RFC2396.7"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>, <a href="http://tools.ietf.org/html/rfc2396#section-5">Section 5</a>> 1033 1034 uri-host = <host, 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-3.2.2">Section 3.2.2</a>> 1034 </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>).1035 </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 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1035 1036 </p> 1036 1037 <p id="rfc.section.3.2.1.p.4"> </p> … … 1193 1194 </pre><p id="rfc.section.3.4.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-extension extensions they do not understand. 1194 1195 </p> 1196 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1197 <p id="rfc.section.3.5.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 1198 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white 1199 space. By convention, the products are listed in order of their significance for identifying the application. 1200 </p> 1201 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span> product = token ["/" product-version] 1202 product-version = token 1203 </pre><p id="rfc.section.3.5.p.3">Examples:</p> 1204 <div id="rfc.figure.u.24"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1205 Server: Apache/0.8.4 1206 </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). 1207 </p> 1195 1208 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1> 1196 1209 <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> 1197 1210 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1198 <div id="rfc.figure.u.2 3"></div><pre class="inline"><span id="rfc.iref.g.57"></span> HTTP-message = Request | Response ; HTTP/1.1 messages1211 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.59"></span> HTTP-message = Request | Response ; HTTP/1.1 messages 1199 1212 </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 1200 1213 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1201 1214 fields, and possibly a message-body. 1202 1215 </p> 1203 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span> generic-message = start-line1216 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> generic-message = start-line 1204 1217 *(message-header CRLF) 1205 1218 CRLF … … 1213 1226 </p> 1214 1227 <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> 1215 <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 3.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. The1228 <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 3</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 5</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 3.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. The 1216 1229 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 1217 1230 each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, … … 1219 1232 forms. 1220 1233 </p> 1221 <div id="rfc.figure.u.2 5"></div><pre class="inline"><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> message-header = field-name ":" [ field-value ]1234 <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 ] 1222 1235 field-name = token 1223 1236 field-value = *( field-content | LWS ) … … 1244 1257 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1245 1258 </p> 1246 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.64"></span> message-body = entity-body1259 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.66"></span> message-body = entity-body 1247 1260 | <entity-body encoded as per Transfer-Encoding> 1248 1261 </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 … … 1251 1264 <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> 1252 1265 <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 1253 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 length1266 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 2</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 length 1254 1267 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 1255 1268 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. … … 1311 1324 to the entity being transferred. These header fields apply only to the message being transmitted. 1312 1325 </p> 1313 <div id="rfc.figure.u.2 7"></div><pre class="inline"><span id="rfc.iref.g.65"></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 15.2</a>1326 <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 15.2</a> 1314 1327 | Connection ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1315 1328 | Date ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> … … 1328 1341 resource, the identifier of the resource, and the protocol version in use. 1329 1342 </p> 1330 <div id="rfc.figure.u. 28"></div><pre class="inline"><span id="rfc.iref.g.66"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 5.1</a>1343 <div id="rfc.figure.u.30"></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> 1331 1344 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1332 | 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>1345 | 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 3</a> 1333 1346 | 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 3.1</a> 1334 1347 CRLF … … 1338 1351 elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1339 1352 </p> 1340 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.67"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF1353 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.69"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1341 1354 </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> 1342 1355 <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> 1343 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> Method = token1356 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span> Method = token 1344 1357 </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> 1345 1358 <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. 1346 1359 </p> 1347 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.70"></span> Request-URI = "*"1360 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.72"></span> Request-URI = "*" 1348 1361 | absoluteURI 1349 1362 | ( path-absolute [ "?" query ] ) … … 1353 1366 apply to a resource. One example would be 1354 1367 </p> 1355 <div id="rfc.figure.u.3 2"></div><pre class="text"> OPTIONS * HTTP/1.11368 <div id="rfc.figure.u.34"></div><pre class="text"> OPTIONS * HTTP/1.1 1356 1369 </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, 1357 1370 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 … … 1359 1372 Request-Line would be: 1360 1373 </p> 1361 <div id="rfc.figure.u.3 3"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11374 <div id="rfc.figure.u.35"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1362 1375 </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. 1363 1376 </p> 1364 <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>).1377 <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 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1365 1378 </p> 1366 1379 <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 … … 1368 1381 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1369 1382 </p> 1370 <div id="rfc.figure.u.3 4"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.11383 <div id="rfc.figure.u.36"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1371 1384 Host: www.example.org 1372 1385 </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 … … 1406 1419 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1407 1420 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1408 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.71"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 6.1</a>1421 <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> 1409 1422 *(( general-header ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1410 | 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>1423 | 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 5</a> 1411 1424 | entity-header ) CRLF) ; <a href="#Part3" id="rfc.xref.Part3.10"><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 3.1</a> 1412 1425 CRLF … … 1417 1430 CRLF sequence. 1418 1431 </p> 1419 <div id="rfc.figure.u.3 6"></div><pre class="inline"><span id="rfc.iref.g.72"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF1432 <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 CRLF 1420 1433 </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> 1421 1434 <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 1422 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 is intended to give a short textual description of the Status-Code. The Status-Code is intended for use1435 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</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 is intended to give a short textual description of the Status-Code. The Status-Code is intended for use 1423 1436 by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. 1424 1437 </p> … … 1433 1446 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1434 1447 </ul> 1435 <div id="rfc.figure.u.3 7"></div><pre class="inline"><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span> Status-Code = 3DIGIT1448 <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 = 3DIGIT 1436 1449 Reason-Phrase = *<TEXT, excluding CR, LF> 1437 1450 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> … … 1489 1502 <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. 1490 1503 </p> 1491 <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 to1504 <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 7.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 to 1492 1505 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. 1493 1506 </p> … … 1514 1527 </p> 1515 1528 <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 1516 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.10"><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 understanding1529 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><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 1517 1530 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. 1518 1531 </p> … … 1532 1545 </p> 1533 1546 <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> 1534 <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.11"><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 willing1547 <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 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><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 1535 1548 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1536 1549 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking … … 1539 1552 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1540 1553 <ul> 1541 <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.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.1542 </li> 1543 <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.13"><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.1554 <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 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 1555 </li> 1556 <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 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.13"><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. 1544 1557 </li> 1545 1558 </ul> … … 1585 1598 <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 1586 1599 an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding 1587 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.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1600 of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1588 1601 </li> 1589 1602 </ul> … … 1624 1637 </p> 1625 1638 <p id="rfc.section.8.1.p.2">The Connection header has the following grammar:</p> 1626 <div id="rfc.figure.u. 38"></div><pre class="inline"><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> Connection = "Connection" ":" 1#(connection-token)1639 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span> Connection = "Connection" ":" 1#(connection-token) 1627 1640 connection-token = token 1628 1641 </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 … … 1636 1649 of the response. For example, 1637 1650 </p> 1638 <div id="rfc.figure.u. 39"></div><pre class="text"> Connection: close1651 <div id="rfc.figure.u.41"></div><pre class="text"> Connection: close 1639 1652 </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. 1640 1653 </p> … … 1652 1665 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. 1653 1666 </p> 1654 <div id="rfc.figure.u.4 0"></div><pre class="inline"><span id="rfc.iref.g.78"></span> Content-Length = "Content-Length" ":" 1*DIGIT1667 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.80"></span> Content-Length = "Content-Length" ":" 1*DIGIT 1655 1668 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1656 <div id="rfc.figure.u.4 1"></div><pre class="text"> Content-Length: 34951669 <div id="rfc.figure.u.43"></div><pre class="text"> Content-Length: 3495 1657 1670 </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>. 1658 1671 </p> … … 1669 1682 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. 1670 1683 </p> 1671 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.79"></span> Date = "Date" ":" HTTP-date1684 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.81"></span> Date = "Date" ":" HTTP-date 1672 1685 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1673 <div id="rfc.figure.u.4 3"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1686 <div id="rfc.figure.u.45"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1674 1687 </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: 1675 1688 </p> … … 1707 1720 a single IP address. 1708 1721 </p> 1709 <div id="rfc.figure.u.4 4"></div><pre class="inline"><span id="rfc.iref.g.80"></span> Host = "Host" ":" uri-host [ ":" port ] ; <a href="#http.url" title="http URL">Section 3.2.2</a>1722 <div id="rfc.figure.u.46"></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> 1710 1723 </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 1711 1724 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1712 1725 </p> 1713 <div id="rfc.figure.u.4 5"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11726 <div id="rfc.figure.u.47"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1714 1727 Host: www.example.org 1715 1728 </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 … … 1726 1739 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>). 1727 1740 </p> 1728 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span> TE = "TE" ":" #( t-codings )1741 <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 ) 1729 1742 t-codings = "trailers" | ( transfer-extension [ accept-params ] ) 1730 1743 </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, … … 1732 1745 </p> 1733 1746 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1734 <div id="rfc.figure.u.4 7"></div><pre class="text"> TE: deflate1747 <div id="rfc.figure.u.49"></div><pre class="text"> TE: deflate 1735 1748 TE: 1736 1749 TE: trailers, deflate;q=0.5 … … 1769 1782 with chunked transfer-coding. 1770 1783 </p> 1771 <div id="rfc.figure.u. 48"></div><pre class="inline"><span id="rfc.iref.g.83"></span> Trailer = "Trailer" ":" 1#field-name1784 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.85"></span> Trailer = "Trailer" ":" 1#field-name 1772 1785 </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 1773 1786 to know which header fields to expect in the trailer. … … 1789 1802 transfer-coding is a property of the message, not of the entity. 1790 1803 </p> 1791 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.84"></span> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding1804 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.86"></span> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 1792 1805 </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: 1793 1806 </p> 1794 <div id="rfc.figure.u.5 0"></div><pre class="text"> Transfer-Encoding: chunked1807 <div id="rfc.figure.u.52"></div><pre class="text"> Transfer-Encoding: chunked 1795 1808 </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. 1796 1809 </p> … … 1802 1815 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. 1803 1816 </p> 1804 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.85"></span> Upgrade = "Upgrade" ":" 1#product1817 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.87"></span> Upgrade = "Upgrade" ":" 1#product 1805 1818 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1806 <div id="rfc.figure.u.5 2"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111819 <div id="rfc.figure.u.54"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1807 1820 </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 1808 1821 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1833 1846 of all senders along the request/response chain. 1834 1847 </p> 1835 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><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> Via = "Via" ":" 1#( received-protocol received-by [ comment ] )1848 <div id="rfc.figure.u.55"></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 ] ) 1836 1849 received-protocol = [ protocol-name "/" ] protocol-version 1837 1850 protocol-name = token … … 1856 1869 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1857 1870 </p> 1858 <div id="rfc.figure.u.5 4"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1871 <div id="rfc.figure.u.56"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1859 1872 </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. 1860 1873 </p> … … 1862 1875 For example, 1863 1876 </p> 1864 <div id="rfc.figure.u.5 5"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1877 <div id="rfc.figure.u.57"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1865 1878 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1866 <div id="rfc.figure.u.5 6"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1879 <div id="rfc.figure.u.58"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1867 1880 </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 1868 1881 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2477 2490 <li>Get rid of prose rules that span multiple lines.</li> 2478 2491 <li>Get rid of unused rules LOALPHA and UPALPHA.</li> 2492 <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li> 2479 2493 </ul> 2480 2494 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 2551 2565 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.4.1</b></a></li> 2552 2566 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.18"><b>2.2</b></a></li> 2553 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.7 6"><b>8.1</b></a></li>2554 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.7 7"><b>8.1</b></a></li>2555 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g. 78"><b>8.2</b></a></li>2567 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.78"><b>8.1</b></a></li> 2568 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.79"><b>8.1</b></a></li> 2569 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.80"><b>8.2</b></a></li> 2556 2570 <li class="indline1"><tt>CR</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.2</b></a></li> 2557 2571 <li class="indline1"><tt>CRLF</tt> <a class="iref" href="#rfc.iref.g.12"><b>2.2</b></a></li> 2558 2572 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.19"><b>2.2</b></a></li> 2559 2573 <li class="indline1"><tt>CTL</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.2</b></a></li> 2560 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g. 79"><b>8.3</b></a></li>2574 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.81"><b>8.3</b></a></li> 2561 2575 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.3.1</b></a></li> 2562 2576 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.3.1</b></a></li> … … 2564 2578 <li class="indline1"><tt>DIGIT</tt> <a class="iref" href="#rfc.iref.g.5"><b>2.2</b></a></li> 2565 2579 <li class="indline1"><tt>DQUOTE</tt> <a class="iref" href="#rfc.iref.g.11"><b>2.2</b></a></li> 2566 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.7 4"><b>6.1.1</b></a></li>2567 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g. 69"><b>5.1.1</b></a></li>2568 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.6 3"><b>4.2</b></a></li>2569 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.6 1"><b>4.2</b></a></li>2570 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.6 2"><b>4.2</b></a></li>2571 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.6 5"><b>4.5</b></a></li>2572 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g. 58"><b>4.1</b></a></li>2580 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.76"><b>6.1.1</b></a></li> 2581 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.71"><b>5.1.1</b></a></li> 2582 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.65"><b>4.2</b></a></li> 2583 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.63"><b>4.2</b></a></li> 2584 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.64"><b>4.2</b></a></li> 2585 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.67"><b>4.5</b></a></li> 2586 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.60"><b>4.1</b></a></li> 2573 2587 <li class="indline1"><tt>HEX</tt> <a class="iref" href="#rfc.iref.g.15"><b>2.2</b></a></li> 2574 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.8 0"><b>8.4</b></a></li>2588 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.4</b></a></li> 2575 2589 <li class="indline1"><tt>HTAB</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.2</b></a></li> 2576 2590 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.32"><b>3.3.1</b></a></li> 2577 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.5 7"><b>4.1</b></a></li>2591 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.59"><b>4.1</b></a></li> 2578 2592 <li class="indline1"><tt>http-URL</tt> <a class="iref" href="#rfc.iref.g.31"><b>3.2.2</b></a></li> 2579 2593 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.23"><b>3.1</b></a></li> … … 2581 2595 <li class="indline1"><tt>LF</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.2</b></a></li> 2582 2596 <li class="indline1"><tt>LWS</tt> <a class="iref" href="#rfc.iref.g.13"><b>2.2</b></a></li> 2583 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.6 4"><b>4.3</b></a></li>2584 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.6 0"><b>4.2</b></a></li>2585 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g. 68"><b>5.1.1</b></a></li>2597 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.66"><b>4.3</b></a></li> 2598 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.62"><b>4.2</b></a></li> 2599 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.70"><b>5.1.1</b></a></li> 2586 2600 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.3.1</b></a></li> 2587 2601 <li class="indline1"><tt>OCTET</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> … … 2589 2603 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.26"><b>3.2.1</b></a></li> 2590 2604 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.27"><b>3.2.1</b></a></li> 2591 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.9</b></a></li> 2592 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.9</b></a></li> 2593 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.9</b></a></li> 2605 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.57"><b>3.5</b></a></li> 2606 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.58"><b>3.5</b></a></li> 2607 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.9</b></a></li> 2608 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.9</b></a></li> 2609 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.9</b></a></li> 2594 2610 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.21"><b>2.2</b></a></li> 2595 2611 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.28"><b>3.2.1</b></a></li> 2596 2612 <li class="indline1"><tt>quoted-pair</tt> <a class="iref" href="#rfc.iref.g.22"><b>2.2</b></a></li> 2597 2613 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.20"><b>2.2</b></a></li> 2598 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.7 5"><b>6.1.1</b></a></li>2599 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.9 0"><b>8.9</b></a></li>2600 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.8 7"><b>8.9</b></a></li>2614 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.77"><b>6.1.1</b></a></li> 2615 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.9</b></a></li> 2616 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.9</b></a></li> 2601 2617 <li class="indline1"><tt>relativeURI</tt> <a class="iref" href="#rfc.iref.g.29"><b>3.2.1</b></a></li> 2602 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.6 6"><b>5</b></a></li>2603 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.6 7"><b>5.1</b></a></li>2604 <li class="indline1"><tt>Request-URI</tt> <a class="iref" href="#rfc.iref.g.7 0"><b>5.1.2</b></a></li>2605 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.7 1"><b>6</b></a></li>2618 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.68"><b>5</b></a></li> 2619 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.69"><b>5.1</b></a></li> 2620 <li class="indline1"><tt>Request-URI</tt> <a class="iref" href="#rfc.iref.g.72"><b>5.1.2</b></a></li> 2621 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.73"><b>6</b></a></li> 2606 2622 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.33"><b>3.3.1</b></a></li> 2607 2623 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.3.1</b></a></li> 2608 2624 <li class="indline1"><tt>separators</tt> <a class="iref" href="#rfc.iref.g.17"><b>2.2</b></a></li> 2609 2625 <li class="indline1"><tt>SP</tt> <a class="iref" href="#rfc.iref.g.9"><b>2.2</b></a></li> 2610 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g. 59"><b>4.1</b></a></li>2611 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.7 3"><b>6.1.1</b></a></li>2612 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.7 2"><b>6.1</b></a></li>2613 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.8 2"><b>8.5</b></a></li>2614 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.8 1"><b>8.5</b></a></li>2626 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.61"><b>4.1</b></a></li> 2627 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.75"><b>6.1.1</b></a></li> 2628 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.74"><b>6.1</b></a></li> 2629 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.5</b></a></li> 2630 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.5</b></a></li> 2615 2631 <li class="indline1"><tt>TEXT</tt> <a class="iref" href="#rfc.iref.g.14"><b>2.2</b></a></li> 2616 2632 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.3.1</b></a></li> 2617 2633 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.16"><b>2.2</b></a></li> 2618 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.8 3"><b>8.6</b></a></li>2634 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.6</b></a></li> 2619 2635 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.56"><b>3.4.1</b></a></li> 2620 2636 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.4</b></a></li> 2621 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.8 4"><b>8.7</b></a></li>2637 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.7</b></a></li> 2622 2638 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.4</b></a></li> 2623 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.8 5"><b>8.8</b></a></li>2639 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.8</b></a></li> 2624 2640 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.30"><b>3.2.1</b></a></li> 2625 2641 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.47"><b>3.4</b></a></li> 2626 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.8 6"><b>8.9</b></a></li>2642 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.9</b></a></li> 2627 2643 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.3.1</b></a></li> 2628 2644 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.3.1</b></a></li> … … 2676 2692 <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> 2677 2693 <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"> 2678 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.4">4.3</a></li>2679 <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>2680 <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>2681 <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>2682 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li>2683 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li>2684 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>2685 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li>2686 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.1">3.2.1</a></li>2687 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>2694 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part2.4">4.3</a></li> 2695 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.2">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5</a></li> 2696 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.7">6</a></li> 2697 <li class="indline1"><em>Section 7.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> 2698 <li class="indline1"><em>Section 7.9</em> <a class="iref" href="#rfc.xref.Part2.6">5.1.2</a></li> 2699 <li class="indline1"><em>Section 8</em> <a class="iref" href="#rfc.xref.Part2.8">6.1.1</a></li> 2700 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li> 2701 <li class="indline1"><em>Section 8.1</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a></li> 2702 <li class="indline1"><em>Section 8.4.15</em> <a class="iref" href="#rfc.xref.Part2.1">3.2.1</a></li> 2703 <li class="indline1"><em>Section 9.2</em> <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li> 2688 2704 </ul> 2689 2705 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r188 r190 1331 1331 </section> 1332 1332 1333 <section title="Product Tokens" anchor="product.tokens"> 1334 <t> 1335 Product tokens are used to allow communicating applications to 1336 identify themselves by software name and version. Most fields using 1337 product tokens also allow sub-products which form a significant part 1338 of the application to be listed, separated by white space. By 1339 convention, the products are listed in order of their significance 1340 for identifying the application. 1341 </t> 1342 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/> 1343 product = token ["/" product-version] 1344 product-version = token 1345 </artwork></figure> 1346 <t> 1347 Examples: 1348 </t> 1349 <figure><artwork type="example"> 1350 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1351 Server: Apache/0.8.4 1352 </artwork></figure> 1353 <t> 1354 Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be 1355 used for advertising or other non-essential information. Although any 1356 token character &MAY; appear in a product-version, this token &SHOULD; 1357 only be used for a version identifier (i.e., successive versions of 1358 the same product &SHOULD; only differ in the product-version portion of 1359 the product value). 1360 </t> 1361 </section> 1362 1333 1363 </section> 1334 1364 … … 4195 4225 <list style="symbols"> 4196 4226 <t> 4197 Get rid of duplicate BNF rule names ("host" -> "uri-host", "trailer" -> 4198 "trailer-part"). 4199 </t> 4200 <t> 4201 Avoid underscore character in rule names ("http_URL" -> 4202 "http-URL", "abs_path" -> "path-absolute"). 4203 </t> 4204 <t> 4205 Add rules for terms imported from URI spec ("absoluteURI", "authority", 4206 "path-absolute", "port", "query", "relativeURI", "host) -- these will 4207 have to be updated when switching over to RFC3986. 4208 </t> 4209 <t> 4210 Synchronize core rules with RFC5234 (this includes a change to CHAR 4211 which now excludes NUL). 4212 </t> 4213 <t> 4214 Get rid of prose rules that span multiple lines. 4215 </t> 4216 <t> 4217 Get rid of unused rules LOALPHA and UPALPHA. 4227 Get rid of duplicate BNF rule names ("host" -> "uri-host", "trailer" -> 4228 "trailer-part"). 4229 </t> 4230 <t> 4231 Avoid underscore character in rule names ("http_URL" -> 4232 "http-URL", "abs_path" -> "path-absolute"). 4233 </t> 4234 <t> 4235 Add rules for terms imported from URI spec ("absoluteURI", "authority", 4236 "path-absolute", "port", "query", "relativeURI", "host) -- these will 4237 have to be updated when switching over to RFC3986. 4238 </t> 4239 <t> 4240 Synchronize core rules with RFC5234 (this includes a change to CHAR 4241 which now excludes NUL). 4242 </t> 4243 <t> 4244 Get rid of prose rules that span multiple lines. 4245 </t> 4246 <t> 4247 Get rid of unused rules LOALPHA and UPALPHA. 4248 </t> 4249 <t> 4250 Move "Product Tokens" section (back) into Part 1, as "token" is used 4251 in the definition of the Upgrade header. 4218 4252 </t> 4219 4253 </list> -
draft-ietf-httpbis/latest/p2-semantics.html
r189 r190 333 333 <link rel="Index" href="#rfc.index"> 334 334 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 335 <link rel="Chapter" title="2 Product Tokens" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Method" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Request Header Fields" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Status Code and Reason Phrase" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Response Header Fields" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 Entity" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Method Definitions" href="#rfc.section.8"> 342 <link rel="Chapter" title="9 Status Code Definitions" href="#rfc.section.9"> 343 <link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10"> 344 <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11"> 345 <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12"> 346 <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13"> 347 <link rel="Chapter" href="#rfc.section.14" title="14 References"> 335 <link rel="Chapter" title="2 Method" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Request Header Fields" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Response Header Fields" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Entity" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 Method Definitions" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Status Code Definitions" href="#rfc.section.8"> 342 <link rel="Chapter" title="9 Header Field Definitions" href="#rfc.section.9"> 343 <link rel="Chapter" title="10 IANA Considerations" href="#rfc.section.10"> 344 <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11"> 345 <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12"> 346 <link rel="Chapter" href="#rfc.section.13" title="13 References"> 348 347 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 349 348 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> … … 487 486 </ul> 488 487 </li> 489 <li class="tocline0">2. <a href="#product.tokens">Product Tokens</a></li> 490 <li class="tocline0">3. <a href="#method">Method</a></li> 491 <li class="tocline0">4. <a href="#request.header.fields">Request Header Fields</a></li> 492 <li class="tocline0">5. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> 493 <li class="tocline0">6. <a href="#response.header.fields">Response Header Fields</a></li> 494 <li class="tocline0">7. <a href="#entity">Entity</a></li> 495 <li class="tocline0">8. <a href="#method.definitions">Method Definitions</a><ul class="toc"> 496 <li class="tocline1">8.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc"> 497 <li class="tocline1">8.1.1 <a href="#safe.methods">Safe Methods</a></li> 498 <li class="tocline1">8.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> 488 <li class="tocline0">2. <a href="#method">Method</a></li> 489 <li class="tocline0">3. <a href="#request.header.fields">Request Header Fields</a></li> 490 <li class="tocline0">4. <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> 491 <li class="tocline0">5. <a href="#response.header.fields">Response Header Fields</a></li> 492 <li class="tocline0">6. <a href="#entity">Entity</a></li> 493 <li class="tocline0">7. <a href="#method.definitions">Method Definitions</a><ul class="toc"> 494 <li class="tocline1">7.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc"> 495 <li class="tocline1">7.1.1 <a href="#safe.methods">Safe Methods</a></li> 496 <li class="tocline1">7.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li> 499 497 </ul> 500 498 </li> 501 <li class="tocline1"> 8.2 <a href="#OPTIONS">OPTIONS</a></li>502 <li class="tocline1"> 8.3 <a href="#GET">GET</a></li>503 <li class="tocline1"> 8.4 <a href="#HEAD">HEAD</a></li>504 <li class="tocline1"> 8.5 <a href="#POST">POST</a></li>505 <li class="tocline1"> 8.6 <a href="#PUT">PUT</a></li>506 <li class="tocline1"> 8.7 <a href="#DELETE">DELETE</a></li>507 <li class="tocline1"> 8.8 <a href="#TRACE">TRACE</a></li>508 <li class="tocline1"> 8.9 <a href="#CONNECT">CONNECT</a></li>499 <li class="tocline1">7.2 <a href="#OPTIONS">OPTIONS</a></li> 500 <li class="tocline1">7.3 <a href="#GET">GET</a></li> 501 <li class="tocline1">7.4 <a href="#HEAD">HEAD</a></li> 502 <li class="tocline1">7.5 <a href="#POST">POST</a></li> 503 <li class="tocline1">7.6 <a href="#PUT">PUT</a></li> 504 <li class="tocline1">7.7 <a href="#DELETE">DELETE</a></li> 505 <li class="tocline1">7.8 <a href="#TRACE">TRACE</a></li> 506 <li class="tocline1">7.9 <a href="#CONNECT">CONNECT</a></li> 509 507 </ul> 510 508 </li> 511 <li class="tocline0"> 9. <a href="#status.codes">Status Code Definitions</a><ul class="toc">512 <li class="tocline1"> 9.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc">513 <li class="tocline1"> 9.1.1 <a href="#status.100">100 Continue</a></li>514 <li class="tocline1"> 9.1.2 <a href="#status.101">101 Switching Protocols</a></li>509 <li class="tocline0">8. <a href="#status.codes">Status Code Definitions</a><ul class="toc"> 510 <li class="tocline1">8.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc"> 511 <li class="tocline1">8.1.1 <a href="#status.100">100 Continue</a></li> 512 <li class="tocline1">8.1.2 <a href="#status.101">101 Switching Protocols</a></li> 515 513 </ul> 516 514 </li> 517 <li class="tocline1"> 9.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc">518 <li class="tocline1"> 9.2.1 <a href="#status.200">200 OK</a></li>519 <li class="tocline1"> 9.2.2 <a href="#status.201">201 Created</a></li>520 <li class="tocline1"> 9.2.3 <a href="#status.202">202 Accepted</a></li>521 <li class="tocline1"> 9.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li>522 <li class="tocline1"> 9.2.5 <a href="#status.204">204 No Content</a></li>523 <li class="tocline1"> 9.2.6 <a href="#status.205">205 Reset Content</a></li>524 <li class="tocline1"> 9.2.7 <a href="#status.206">206 Partial Content</a></li>515 <li class="tocline1">8.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc"> 516 <li class="tocline1">8.2.1 <a href="#status.200">200 OK</a></li> 517 <li class="tocline1">8.2.2 <a href="#status.201">201 Created</a></li> 518 <li class="tocline1">8.2.3 <a href="#status.202">202 Accepted</a></li> 519 <li class="tocline1">8.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li> 520 <li class="tocline1">8.2.5 <a href="#status.204">204 No Content</a></li> 521 <li class="tocline1">8.2.6 <a href="#status.205">205 Reset Content</a></li> 522 <li class="tocline1">8.2.7 <a href="#status.206">206 Partial Content</a></li> 525 523 </ul> 526 524 </li> 527 <li class="tocline1"> 9.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc">528 <li class="tocline1"> 9.3.1 <a href="#status.300">300 Multiple Choices</a></li>529 <li class="tocline1"> 9.3.2 <a href="#status.301">301 Moved Permanently</a></li>530 <li class="tocline1"> 9.3.3 <a href="#status.302">302 Found</a></li>531 <li class="tocline1"> 9.3.4 <a href="#status.303">303 See Other</a></li>532 <li class="tocline1"> 9.3.5 <a href="#status.304">304 Not Modified</a></li>533 <li class="tocline1"> 9.3.6 <a href="#status.305">305 Use Proxy</a></li>534 <li class="tocline1"> 9.3.7 <a href="#status.306">306 (Unused)</a></li>535 <li class="tocline1"> 9.3.8 <a href="#status.307">307 Temporary Redirect</a></li>525 <li class="tocline1">8.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc"> 526 <li class="tocline1">8.3.1 <a href="#status.300">300 Multiple Choices</a></li> 527 <li class="tocline1">8.3.2 <a href="#status.301">301 Moved Permanently</a></li> 528 <li class="tocline1">8.3.3 <a href="#status.302">302 Found</a></li> 529 <li class="tocline1">8.3.4 <a href="#status.303">303 See Other</a></li> 530 <li class="tocline1">8.3.5 <a href="#status.304">304 Not Modified</a></li> 531 <li class="tocline1">8.3.6 <a href="#status.305">305 Use Proxy</a></li> 532 <li class="tocline1">8.3.7 <a href="#status.306">306 (Unused)</a></li> 533 <li class="tocline1">8.3.8 <a href="#status.307">307 Temporary Redirect</a></li> 536 534 </ul> 537 535 </li> 538 <li class="tocline1"> 9.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc">539 <li class="tocline1"> 9.4.1 <a href="#status.400">400 Bad Request</a></li>540 <li class="tocline1"> 9.4.2 <a href="#status.401">401 Unauthorized</a></li>541 <li class="tocline1"> 9.4.3 <a href="#status.402">402 Payment Required</a></li>542 <li class="tocline1"> 9.4.4 <a href="#status.403">403 Forbidden</a></li>543 <li class="tocline1"> 9.4.5 <a href="#status.404">404 Not Found</a></li>544 <li class="tocline1"> 9.4.6 <a href="#status.405">405 Method Not Allowed</a></li>545 <li class="tocline1"> 9.4.7 <a href="#status.406">406 Not Acceptable</a></li>546 <li class="tocline1"> 9.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li>547 <li class="tocline1"> 9.4.9 <a href="#status.408">408 Request Timeout</a></li>548 <li class="tocline1"> 9.4.10 <a href="#status.409">409 Conflict</a></li>549 <li class="tocline1"> 9.4.11 <a href="#status.410">410 Gone</a></li>550 <li class="tocline1"> 9.4.12 <a href="#status.411">411 Length Required</a></li>551 <li class="tocline1"> 9.4.13 <a href="#status.412">412 Precondition Failed</a></li>552 <li class="tocline1"> 9.4.14 <a href="#status.413">413 Request Entity Too Large</a></li>553 <li class="tocline1"> 9.4.15 <a href="#status.414">414 Request-URI Too Long</a></li>554 <li class="tocline1"> 9.4.16 <a href="#status.415">415 Unsupported Media Type</a></li>555 <li class="tocline1"> 9.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li>556 <li class="tocline1"> 9.4.18 <a href="#status.417">417 Expectation Failed</a></li>536 <li class="tocline1">8.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc"> 537 <li class="tocline1">8.4.1 <a href="#status.400">400 Bad Request</a></li> 538 <li class="tocline1">8.4.2 <a href="#status.401">401 Unauthorized</a></li> 539 <li class="tocline1">8.4.3 <a href="#status.402">402 Payment Required</a></li> 540 <li class="tocline1">8.4.4 <a href="#status.403">403 Forbidden</a></li> 541 <li class="tocline1">8.4.5 <a href="#status.404">404 Not Found</a></li> 542 <li class="tocline1">8.4.6 <a href="#status.405">405 Method Not Allowed</a></li> 543 <li class="tocline1">8.4.7 <a href="#status.406">406 Not Acceptable</a></li> 544 <li class="tocline1">8.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li> 545 <li class="tocline1">8.4.9 <a href="#status.408">408 Request Timeout</a></li> 546 <li class="tocline1">8.4.10 <a href="#status.409">409 Conflict</a></li> 547 <li class="tocline1">8.4.11 <a href="#status.410">410 Gone</a></li> 548 <li class="tocline1">8.4.12 <a href="#status.411">411 Length Required</a></li> 549 <li class="tocline1">8.4.13 <a href="#status.412">412 Precondition Failed</a></li> 550 <li class="tocline1">8.4.14 <a href="#status.413">413 Request Entity Too Large</a></li> 551 <li class="tocline1">8.4.15 <a href="#status.414">414 Request-URI Too Long</a></li> 552 <li class="tocline1">8.4.16 <a href="#status.415">415 Unsupported Media Type</a></li> 553 <li class="tocline1">8.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li> 554 <li class="tocline1">8.4.18 <a href="#status.417">417 Expectation Failed</a></li> 557 555 </ul> 558 556 </li> 559 <li class="tocline1"> 9.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc">560 <li class="tocline1"> 9.5.1 <a href="#status.500">500 Internal Server Error</a></li>561 <li class="tocline1"> 9.5.2 <a href="#status.501">501 Not Implemented</a></li>562 <li class="tocline1"> 9.5.3 <a href="#status.502">502 Bad Gateway</a></li>563 <li class="tocline1"> 9.5.4 <a href="#status.503">503 Service Unavailable</a></li>564 <li class="tocline1"> 9.5.5 <a href="#status.504">504 Gateway Timeout</a></li>565 <li class="tocline1"> 9.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li>557 <li class="tocline1">8.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc"> 558 <li class="tocline1">8.5.1 <a href="#status.500">500 Internal Server Error</a></li> 559 <li class="tocline1">8.5.2 <a href="#status.501">501 Not Implemented</a></li> 560 <li class="tocline1">8.5.3 <a href="#status.502">502 Bad Gateway</a></li> 561 <li class="tocline1">8.5.4 <a href="#status.503">503 Service Unavailable</a></li> 562 <li class="tocline1">8.5.5 <a href="#status.504">504 Gateway Timeout</a></li> 563 <li class="tocline1">8.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li> 566 564 </ul> 567 565 </li> 568 566 </ul> 569 567 </li> 570 <li class="tocline0"> 10. <a href="#header.fields">Header Field Definitions</a><ul class="toc">571 <li class="tocline1"> 10.1 <a href="#header.allow">Allow</a></li>572 <li class="tocline1"> 10.2 <a href="#header.expect">Expect</a></li>573 <li class="tocline1"> 10.3 <a href="#header.from">From</a></li>574 <li class="tocline1"> 10.4 <a href="#header.location">Location</a></li>575 <li class="tocline1"> 10.5 <a href="#header.max-forwards">Max-Forwards</a></li>576 <li class="tocline1"> 10.6 <a href="#header.referer">Referer</a></li>577 <li class="tocline1"> 10.7 <a href="#header.retry-after">Retry-After</a></li>578 <li class="tocline1"> 10.8 <a href="#header.server">Server</a></li>579 <li class="tocline1"> 10.9 <a href="#header.user-agent">User-Agent</a></li>568 <li class="tocline0">9. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 569 <li class="tocline1">9.1 <a href="#header.allow">Allow</a></li> 570 <li class="tocline1">9.2 <a href="#header.expect">Expect</a></li> 571 <li class="tocline1">9.3 <a href="#header.from">From</a></li> 572 <li class="tocline1">9.4 <a href="#header.location">Location</a></li> 573 <li class="tocline1">9.5 <a href="#header.max-forwards">Max-Forwards</a></li> 574 <li class="tocline1">9.6 <a href="#header.referer">Referer</a></li> 575 <li class="tocline1">9.7 <a href="#header.retry-after">Retry-After</a></li> 576 <li class="tocline1">9.8 <a href="#header.server">Server</a></li> 577 <li class="tocline1">9.9 <a href="#header.user-agent">User-Agent</a></li> 580 578 </ul> 581 579 </li> 582 <li class="tocline0">1 1. <a href="#IANA.considerations">IANA Considerations</a></li>583 <li class="tocline0">1 2. <a href="#security.considerations">Security Considerations</a><ul class="toc">584 <li class="tocline1">1 2.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>585 <li class="tocline1">1 2.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>586 <li class="tocline1">1 2.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>580 <li class="tocline0">10. <a href="#IANA.considerations">IANA Considerations</a></li> 581 <li class="tocline0">11. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 582 <li class="tocline1">11.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li> 583 <li class="tocline1">11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li> 584 <li class="tocline1">11.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li> 587 585 </ul> 588 586 </li> 589 <li class="tocline0">1 3. <a href="#ack">Acknowledgments</a></li>590 <li class="tocline0">1 4. <a href="#rfc.references">References</a><ul class="toc">591 <li class="tocline1">1 4.1 <a href="#rfc.references.1">Normative References</a></li>592 <li class="tocline1">1 4.2 <a href="#rfc.references.2">Informative References</a></li>587 <li class="tocline0">12. <a href="#ack">Acknowledgments</a></li> 588 <li class="tocline0">13. <a href="#rfc.references">References</a><ul class="toc"> 589 <li class="tocline1">13.1 <a href="#rfc.references.1">Normative References</a></li> 590 <li class="tocline1">13.2 <a href="#rfc.references.2">Informative References</a></li> 593 591 </ul> 594 592 </li> … … 626 624 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." 627 625 </p> 628 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1> 629 <p id="rfc.section.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 630 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white 631 space. By convention, the products are listed in order of their significance for identifying the application. 632 </p> 633 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> product = token ["/" product-version] 634 product-version = token 635 </pre><p id="rfc.section.2.p.3">Examples:</p> 636 <div id="rfc.figure.u.2"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 637 Server: Apache/0.8.4 638 </pre><p id="rfc.section.2.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). 639 </p> 640 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1> 641 <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> 642 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> 643 | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> 644 | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a> 645 | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 8.5</a> 646 | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 8.6</a> 647 | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 8.7</a> 648 | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 8.8</a> 649 | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 8.9</a> 626 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 627 <p id="rfc.section.2.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> 628 <div id="rfc.figure.u.1"></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 7.2</a> 629 | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 7.3</a> 630 | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 7.4</a> 631 | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 7.5</a> 632 | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 7.6</a> 633 | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 7.7</a> 634 | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 7.8</a> 635 | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 7.9</a> 650 636 | extension-method 651 637 extension-method = token 652 </pre><p id="rfc.section. 3.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 10.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the638 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 9.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the 653 639 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested 654 640 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET 655 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 8</a>.656 </p> 657 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1>658 <p id="rfc.section. 4.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,641 and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 7</a>. 642 </p> 643 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h1> 644 <p id="rfc.section.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself, 659 645 to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language 660 646 method invocation. 661 647 </p> 662 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> request-header = Accept ; <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 5.1</a>648 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.3"></span> request-header = Accept ; <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 5.1</a> 663 649 | Accept-Charset ; <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 5.2</a> 664 650 | Accept-Encoding ; <a href="#Part3" id="rfc.xref.Part3.3"><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 5.3</a> 665 651 | Accept-Language ; <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 5.4</a> 666 652 | Authorization ; <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 3.1</a> 667 | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a>668 | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a>653 | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 654 | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> 669 655 | Host ; <a href="#Part1" id="rfc.xref.Part1.2"><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> 670 656 | If-Match ; <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.if-match" title="If-Match">Section 6.2</a> … … 673 659 | If-Range ; <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.if-range" title="If-Range">Section 5.3</a> 674 660 | If-Unmodified-Since ; <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-unmodified-since" title="If-Unmodified-Since">Section 6.5</a> 675 | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.5</a>661 | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.5</a> 676 662 | Proxy-Authorization ; <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-authorization" title="Proxy-Authorization">Section 3.3</a> 677 663 | Range ; <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.range" title="Range">Section 5.4</a> 678 | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a>664 | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 679 665 | TE ; <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#header.upgrade" title="Upgrade">Section 8.8</a> 680 | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a>681 </pre><p id="rfc.section. 4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new666 | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.9</a> 667 </pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new 682 668 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. 683 669 Unrecognized header fields are treated as entity-header fields. 684 670 </p> 685 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>686 <p id="rfc.section. 5.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The status687 codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 9</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use671 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> 672 <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The status 673 codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 8</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use 688 674 by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase. 689 675 </p> 690 <p id="rfc.section. 5.p.2">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's,676 <p id="rfc.section.4.p.2">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, 691 677 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. 692 678 </p> 693 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> Status-Code =694 "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue695 | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols696 | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 9.2.1</a>: OK697 | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 9.2.2</a>: Created698 | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 9.2.3</a>: Accepted699 | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 9.2.4</a>: Non-Authoritative Information700 | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 9.2.5</a>: No Content701 | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 9.2.6</a>: Reset Content702 | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 9.2.7</a>: Partial Content703 | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 9.3.1</a>: Multiple Choices704 | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 9.3.2</a>: Moved Permanently705 | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 9.3.3</a>: Found706 | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 9.3.4</a>: See Other707 | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 9.3.5</a>: Not Modified708 | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 9.3.6</a>: Use Proxy709 | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 9.3.8</a>: Temporary Redirect710 | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 9.4.1</a>: Bad Request711 | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 9.4.2</a>: Unauthorized712 | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 9.4.3</a>: Payment Required713 | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 9.4.4</a>: Forbidden714 | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 9.4.5</a>: Not Found715 | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 9.4.6</a>: Method Not Allowed716 | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 9.4.7</a>: Not Acceptable717 | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 9.4.8</a>: Proxy Authentication Required718 | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 9.4.9</a>: Request Time-out719 | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 9.4.10</a>: Conflict720 | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 9.4.11</a>: Gone721 | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 9.4.12</a>: Length Required722 | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 9.4.13</a>: Precondition Failed723 | "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 9.4.14</a>: Request Entity Too Large724 | "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-URI Too Long">Section 9.4.15</a>: Request-URI Too Large725 | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 9.4.16</a>: Unsupported Media Type726 | "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 9.4.17</a>: Requested range not satisfiable727 | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 9.4.18</a>: Expectation Failed728 | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 9.5.1</a>: Internal Server Error729 | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 9.5.2</a>: Not Implemented730 | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 9.5.3</a>: Bad Gateway731 | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 9.5.4</a>: Service Unavailable732 | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 9.5.5</a>: Gateway Time-out733 | "505" ; <a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 9.5.6</a>: HTTP Version not supported679 <div id="rfc.figure.u.3"></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 = 680 "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 8.1.1</a>: Continue 681 | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 8.1.2</a>: Switching Protocols 682 | "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 8.2.1</a>: OK 683 | "201" ; <a href="#status.201" id="rfc.xref.status.201.1" title="201 Created">Section 8.2.2</a>: Created 684 | "202" ; <a href="#status.202" id="rfc.xref.status.202.1" title="202 Accepted">Section 8.2.3</a>: Accepted 685 | "203" ; <a href="#status.203" id="rfc.xref.status.203.1" title="203 Non-Authoritative Information">Section 8.2.4</a>: Non-Authoritative Information 686 | "204" ; <a href="#status.204" id="rfc.xref.status.204.1" title="204 No Content">Section 8.2.5</a>: No Content 687 | "205" ; <a href="#status.205" id="rfc.xref.status.205.1" title="205 Reset Content">Section 8.2.6</a>: Reset Content 688 | "206" ; <a href="#status.206" id="rfc.xref.status.206.1" title="206 Partial Content">Section 8.2.7</a>: Partial Content 689 | "300" ; <a href="#status.300" id="rfc.xref.status.300.1" title="300 Multiple Choices">Section 8.3.1</a>: Multiple Choices 690 | "301" ; <a href="#status.301" id="rfc.xref.status.301.1" title="301 Moved Permanently">Section 8.3.2</a>: Moved Permanently 691 | "302" ; <a href="#status.302" id="rfc.xref.status.302.1" title="302 Found">Section 8.3.3</a>: Found 692 | "303" ; <a href="#status.303" id="rfc.xref.status.303.1" title="303 See Other">Section 8.3.4</a>: See Other 693 | "304" ; <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 8.3.5</a>: Not Modified 694 | "305" ; <a href="#status.305" id="rfc.xref.status.305.1" title="305 Use Proxy">Section 8.3.6</a>: Use Proxy 695 | "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 8.3.8</a>: Temporary Redirect 696 | "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 8.4.1</a>: Bad Request 697 | "401" ; <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 8.4.2</a>: Unauthorized 698 | "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 8.4.3</a>: Payment Required 699 | "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 8.4.4</a>: Forbidden 700 | "404" ; <a href="#status.404" id="rfc.xref.status.404.1" title="404 Not Found">Section 8.4.5</a>: Not Found 701 | "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 8.4.6</a>: Method Not Allowed 702 | "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 8.4.7</a>: Not Acceptable 703 | "407" ; <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 8.4.8</a>: Proxy Authentication Required 704 | "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 8.4.9</a>: Request Time-out 705 | "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 8.4.10</a>: Conflict 706 | "410" ; <a href="#status.410" id="rfc.xref.status.410.1" title="410 Gone">Section 8.4.11</a>: Gone 707 | "411" ; <a href="#status.411" id="rfc.xref.status.411.1" title="411 Length Required">Section 8.4.12</a>: Length Required 708 | "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 8.4.13</a>: Precondition Failed 709 | "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 8.4.14</a>: Request Entity Too Large 710 | "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-URI Too Long">Section 8.4.15</a>: Request-URI Too Large 711 | "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 8.4.16</a>: Unsupported Media Type 712 | "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 8.4.17</a>: Requested range not satisfiable 713 | "417" ; <a href="#status.417" id="rfc.xref.status.417.1" title="417 Expectation Failed">Section 8.4.18</a>: Expectation Failed 714 | "500" ; <a href="#status.500" id="rfc.xref.status.500.1" title="500 Internal Server Error">Section 8.5.1</a>: Internal Server Error 715 | "501" ; <a href="#status.501" id="rfc.xref.status.501.1" title="501 Not Implemented">Section 8.5.2</a>: Not Implemented 716 | "502" ; <a href="#status.502" id="rfc.xref.status.502.1" title="502 Bad Gateway">Section 8.5.3</a>: Bad Gateway 717 | "503" ; <a href="#status.503" id="rfc.xref.status.503.1" title="503 Service Unavailable">Section 8.5.4</a>: Service Unavailable 718 | "504" ; <a href="#status.504" id="rfc.xref.status.504.1" title="504 Gateway Timeout">Section 8.5.5</a>: Gateway Time-out 719 | "505" ; <a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section 8.5.6</a>: HTTP Version not supported 734 720 | extension-code 735 721 736 722 extension-code = 3DIGIT 737 723 Reason-Phrase = *<TEXT, excluding CR, LF> 738 </pre><p id="rfc.section. 5.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,724 </pre><p id="rfc.section.4.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, 739 725 though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent 740 726 to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was … … 742 728 which will explain the unusual status. 743 729 </p> 744 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1>745 <p id="rfc.section. 6.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the730 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 731 <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 746 732 Status-Line. These header fields give information about the server and about further access to the resource identified by 747 733 the Request-URI. 748 734 </p> 749 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; <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.accept-ranges" title="Accept-Ranges">Section 5.1</a>735 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.7"></span> response-header = Accept-Ranges ; <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.accept-ranges" title="Accept-Ranges">Section 5.1</a> 750 736 | Age ; <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 15.1</a> 751 737 | ETag ; <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.etag" title="ETag">Section 6.1</a> 752 | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a>738 | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.4</a> 753 739 | Proxy-Authenticate ; <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-authenticate" title="Proxy-Authenticate">Section 3.2</a> 754 | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a>755 | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a>740 | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.7</a> 741 | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.8</a> 756 742 | Vary ; <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.vary" title="Vary">Section 15.5</a> 757 743 | WWW-Authenticate ; <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 3.4</a> 758 </pre><p id="rfc.section. 6.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new744 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new 759 745 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header 760 746 fields. Unrecognized header fields are treated as entity-header fields. 761 747 </p> 762 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="entity" href="#entity">Entity</a></h1>763 <p id="rfc.section. 7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header748 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="entity" href="#entity">Entity</a></h1> 749 <p id="rfc.section.6.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header 764 750 fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header 765 751 fields are defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 766 752 </p> 767 <p id="rfc.section. 7.p.2">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.4"><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 ensure753 <p id="rfc.section.6.p.2">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.4"><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 768 754 safe and proper transfer of the message. 769 755 </p> 770 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>771 <p id="rfc.section. 8.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed756 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 757 <p id="rfc.section.7.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed 772 758 to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests. 773 759 </p> 774 <h2 id="rfc.section. 8.1"><a href="#rfc.section.8.1">8.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>775 <h3 id="rfc.section. 8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>776 <p id="rfc.section. 8.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be760 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> 761 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 762 <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be 777 763 careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves 778 764 or others. 779 765 </p> 780 <p id="rfc.section. 8.1.1.p.2">In particular, the convention has been established that the GET and HEAD methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user766 <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET and HEAD methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user 781 767 agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact 782 768 that a possibly unsafe action is being requested. 783 769 </p> 784 <p id="rfc.section. 8.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request;770 <p id="rfc.section.7.1.1.p.3">Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; 785 771 in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the 786 772 side-effects, so therefore cannot be held accountable for them. 787 773 </p> 788 <h3 id="rfc.section. 8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3>789 <p id="rfc.section. 8.1.2.p.1">Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N774 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="idempotent.methods" href="#idempotent.methods">Idempotent Methods</a></h3> 775 <p id="rfc.section.7.1.2.p.1">Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N 790 776 > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, 791 777 the methods OPTIONS and TRACE <em class="bcp14">SHOULD NOT</em> have side effects, and so are inherently idempotent. 792 778 </p> 793 <p id="rfc.section. 8.1.2.p.2">However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that779 <p id="rfc.section.7.1.2.p.2">However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that 794 780 sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that 795 781 is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result 796 782 depends on a value that is later modified in the same sequence. 797 783 </p> 798 <p id="rfc.section. 8.1.2.p.3">A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed784 <p id="rfc.section.7.1.2.p.3">A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed 799 785 on the same set of resources). 800 786 </p> 801 787 <div id="rfc.iref.o.1"></div> 802 788 <div id="rfc.iref.m.1"></div> 803 <h2 id="rfc.section. 8.2"><a href="#rfc.section.8.2">8.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2>804 <p id="rfc.section. 8.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response789 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h2> 790 <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response 805 791 chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated 806 792 with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 807 793 </p> 808 <p id="rfc.section. 8.2.p.2">Responses to this method are not cacheable.</p>809 <p id="rfc.section. 8.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then794 <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p> 795 <p id="rfc.section.7.2.p.3">If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then 810 796 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 811 797 to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension <em class="bcp14">MAY</em> discard the request body. 812 798 </p> 813 <p id="rfc.section. 8.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to799 <p id="rfc.section.7.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to 814 800 a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful 815 801 as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. 816 802 For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). 817 803 </p> 818 <p id="rfc.section. 8.2.p.5">If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating804 <p id="rfc.section.7.2.p.5">If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 819 805 with that resource. 820 806 </p> 821 <p id="rfc.section. 8.2.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,807 <p id="rfc.section.7.2.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., 822 808 Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification, 823 809 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 824 810 </p> 825 <p id="rfc.section. 8.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which811 <p id="rfc.section.7.2.p.7">The Max-Forwards request-header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which 826 812 request forwarding is permitted, the proxy <em class="bcp14">MUST</em> check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy <em class="bcp14">MUST NOT</em> forward the message; instead, the proxy <em class="bcp14">SHOULD</em> respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy <em class="bcp14">MUST</em> decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded 827 813 request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 828 814 </p> 829 <div id="rfc.iref.g. 10"></div>815 <div id="rfc.iref.g.8"></div> 830 816 <div id="rfc.iref.m.2"></div> 831 <h2 id="rfc.section. 8.3"><a href="#rfc.section.8.3">8.3</a> <a id="GET" href="#GET">GET</a></h2>832 <p id="rfc.section. 8.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI817 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="GET" href="#GET">GET</a></h2> 818 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI 833 819 refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not 834 820 the source text of the process, unless that text happens to be the output of the process. 835 821 </p> 836 <p id="rfc.section. 8.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,822 <p id="rfc.section.7.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, 837 823 If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under 838 824 the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary … … 840 826 held by the client. 841 827 </p> 842 <p id="rfc.section. 8.3.p.3">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial828 <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial 843 829 GET requests that only part of the entity be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed 844 830 without transferring data already held by the client. 845 831 </p> 846 <p id="rfc.section. 8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.847 </p> 848 <p id="rfc.section. 8.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations when used for forms.832 <p id="rfc.section.7.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 833 </p> 834 <p id="rfc.section.7.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. 849 835 </p> 850 836 <div id="rfc.iref.h.1"></div> 851 837 <div id="rfc.iref.m.3"></div> 852 <h2 id="rfc.section. 8.4"><a href="#rfc.section.8.4">8.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2>853 <p id="rfc.section. 8.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about838 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="HEAD" href="#HEAD">HEAD</a></h2> 839 <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about 854 840 the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext 855 841 links for validity, accessibility, and recent modification. 856 842 </p> 857 <p id="rfc.section. 8.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs843 <p id="rfc.section.7.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs 858 844 from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the 859 845 cache <em class="bcp14">MUST</em> treat the cache entry as stale. … … 861 847 <div id="rfc.iref.p.1"></div> 862 848 <div id="rfc.iref.m.4"></div> 863 <h2 id="rfc.section. 8.5"><a href="#rfc.section.8.5">8.5</a> <a id="POST" href="#POST">POST</a></h2>864 <p id="rfc.section. 8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed849 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 850 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed 865 851 by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the 866 852 following functions: … … 872 858 <li>Extending a database through an append operation.</li> 873 859 </ul> 874 <p id="rfc.section. 8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p>875 <p id="rfc.section. 8.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either860 <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p> 861 <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 876 862 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity 877 863 that describes the result. 878 864 </p> 879 <p id="rfc.section. 8.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location880 header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 10.4</a>).881 </p> 882 <p id="rfc.section. 8.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.865 <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location 866 header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 867 </p> 868 <p id="rfc.section.7.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. 883 869 However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. 884 870 </p> 885 871 <div id="rfc.iref.p.2"></div> 886 872 <div id="rfc.iref.m.5"></div> 887 <h2 id="rfc.section. 8.6"><a href="#rfc.section.8.6">8.6</a> <a id="PUT" href="#PUT">PUT</a></h2>888 <p id="rfc.section. 8.6.p.1">The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an873 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 874 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an 889 875 already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing 890 876 resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create … … 893 879 an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 894 880 </p> 895 <p id="rfc.section. 8.6.p.2">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.896 </p> 897 <p id="rfc.section. 8.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The881 <p id="rfc.section.7.6.p.2">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 882 </p> 883 <p id="rfc.section.7.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The 898 884 URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 899 885 process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request … … 901 887 it <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 902 888 </p> 903 <p id="rfc.section. 8.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which889 <p id="rfc.section.7.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which 904 890 is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in 905 891 several other URIs being defined by the origin server. 906 892 </p> 907 <p id="rfc.section. 8.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>908 <p id="rfc.section. 8.6.p.6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.893 <p id="rfc.section.7.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 894 <p id="rfc.section.7.6.p.6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. 909 895 </p> 910 896 <div id="rfc.iref.d.1"></div> 911 897 <div id="rfc.iref.m.6"></div> 912 <h2 id="rfc.section. 8.7"><a href="#rfc.section.8.7">8.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2>913 <p id="rfc.section. 8.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation898 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 899 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 914 900 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 915 901 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 916 902 location. 917 903 </p> 918 <p id="rfc.section. 8.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted,904 <p id="rfc.section.7.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, 919 905 or 204 (No Content) if the action has been enacted but the response does not include an entity. 920 906 </p> 921 <p id="rfc.section. 8.7.p.3">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.907 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 922 908 </p> 923 909 <div id="rfc.iref.t.1"></div> 924 910 <div id="rfc.iref.m.7"></div> 925 <h2 id="rfc.section. 8.8"><a href="#rfc.section.8.8">8.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2>926 <p id="rfc.section. 8.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the911 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> 912 <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the 927 913 request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the 928 origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 10.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity.929 </p> 930 <p id="rfc.section. 8.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing914 origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity. 915 </p> 916 <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 931 917 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 932 918 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 933 919 infinite loop. 934 920 </p> 935 <p id="rfc.section. 8.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method <em class="bcp14">MUST NOT</em> be cached.921 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method <em class="bcp14">MUST NOT</em> be cached. 936 922 </p> 937 923 <div id="rfc.iref.c.1"></div> 938 924 <div id="rfc.iref.m.8"></div> 939 <h2 id="rfc.section. 8.9"><a href="#rfc.section.8.9">8.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2>940 <p id="rfc.section. 8.9.p.1">This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g.925 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 926 <p id="rfc.section.7.9.p.1">This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. 941 927 SSL tunneling <a href="#Luo1998" id="rfc.xref.Luo1998.1"><cite title="Tunneling TCP based protocols through Web proxy servers">[Luo1998]</cite></a>). 942 928 </p> 943 <h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>944 <p id="rfc.section. 9.p.1">Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required929 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> 930 <p id="rfc.section.8.p.1">Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required 945 931 in the response. 946 932 </p> 947 <h2 id="rfc.section. 9.1"><a href="#rfc.section.9.1">9.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>948 <p id="rfc.section. 9.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is933 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> 934 <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is 949 935 terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 950 936 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 951 937 </p> 952 <p id="rfc.section. 9.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100938 <p id="rfc.section.8.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 953 939 (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent. 954 940 </p> 955 <p id="rfc.section. 9.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself941 <p id="rfc.section.8.1.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself 956 942 requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards 957 943 a request, then it need not forward the corresponding 100 (Continue) response(s).) 958 944 </p> 959 <div id="rfc.iref.2 5"></div>945 <div id="rfc.iref.23"></div> 960 946 <div id="rfc.iref.s.1"></div> 961 <h3 id="rfc.section. 9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3>962 <p id="rfc.section. 9.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been947 <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="status.100" href="#status.100">100 Continue</a></h3> 948 <p id="rfc.section.8.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 963 949 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 964 950 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 965 951 </p> 966 <div id="rfc.iref.2 6"></div>952 <div id="rfc.iref.24"></div> 967 953 <div id="rfc.iref.s.2"></div> 968 <h3 id="rfc.section. 9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3>969 <p id="rfc.section. 9.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined954 <h3 id="rfc.section.8.1.2"><a href="#rfc.section.8.1.2">8.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 955 <p id="rfc.section.8.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 970 956 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 971 957 </p> 972 <p id="rfc.section. 9.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over958 <p id="rfc.section.8.1.2.p.2">The protocol <em class="bcp14">SHOULD</em> be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over 973 959 older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use 974 960 such features. 975 961 </p> 976 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>977 <p id="rfc.section. 9.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>978 <div id="rfc.iref.2 7"></div>962 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2> 963 <p id="rfc.section.8.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p> 964 <div id="rfc.iref.25"></div> 979 965 <div id="rfc.iref.s.3"></div> 980 <h3 id="rfc.section. 9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3>981 <p id="rfc.section. 9.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for966 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="status.200" href="#status.200">200 OK</a></h3> 967 <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for 982 968 example: 983 969 </p> … … 992 978 <dd>an entity containing the request message as received by the end server.</dd> 993 979 </dl> 994 <div id="rfc.iref.2 8"></div>980 <div id="rfc.iref.26"></div> 995 981 <div id="rfc.iref.s.4"></div> 996 <h3 id="rfc.section. 9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3>997 <p id="rfc.section. 9.2.2.p.1">The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced982 <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> 983 <p id="rfc.section.8.2.2.p.1">The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced 998 984 by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header 999 985 field. The response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose … … 1001 987 server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. 1002 988 </p> 1003 <p id="rfc.section. 9.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the requested variant just created,989 <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, 1004 990 see <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1005 991 </p> 1006 <div id="rfc.iref.2 9"></div>992 <div id="rfc.iref.27"></div> 1007 993 <div id="rfc.iref.s.5"></div> 1008 <h3 id="rfc.section. 9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3>1009 <p id="rfc.section. 9.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually994 <h3 id="rfc.section.8.2.3"><a href="#rfc.section.8.2.3">8.2.3</a> <a id="status.202" href="#status.202">202 Accepted</a></h3> 995 <p id="rfc.section.8.2.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually 1010 996 be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status 1011 997 code from an asynchronous operation such as this. 1012 998 </p> 1013 <p id="rfc.section. 9.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process999 <p id="rfc.section.8.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process 1014 1000 (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the 1015 1001 server persist until the process is completed. The entity returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the 1016 1002 user can expect the request to be fulfilled. 1017 1003 </p> 1018 <div id="rfc.iref. 30"></div>1004 <div id="rfc.iref.28"></div> 1019 1005 <div id="rfc.iref.s.6"></div> 1020 <h3 id="rfc.section. 9.2.4"><a href="#rfc.section.9.2.4">9.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>1021 <p id="rfc.section. 9.2.4.p.1">The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered1006 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1007 <p id="rfc.section.8.2.4.p.1">The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered 1022 1008 from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might 1023 1009 result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only 1024 1010 appropriate when the response would otherwise be 200 (OK). 1025 1011 </p> 1026 <div id="rfc.iref. 31"></div>1012 <div id="rfc.iref.29"></div> 1027 1013 <div id="rfc.iref.s.7"></div> 1028 <h3 id="rfc.section. 9.2.5"><a href="#rfc.section.9.2.5">9.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3>1029 <p id="rfc.section. 9.2.5.p.1">The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.1014 <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 1015 <p id="rfc.section.8.2.5.p.1">The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. 1030 1016 The response <em class="bcp14">MAY</em> include new or updated metainformation in the form of entity-headers, which if present <em class="bcp14">SHOULD</em> be associated with the requested variant. 1031 1017 </p> 1032 <p id="rfc.section. 9.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input1018 <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input 1033 1019 for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation <em class="bcp14">SHOULD</em> be applied to the document currently in the user agent's active view. 1034 1020 </p> 1035 <p id="rfc.section. 9.2.5.p.3">The 204 response <em class="bcp14">MUST NOT</em> include a message-body, and thus is always terminated by the first empty line after the header fields.1036 </p> 1037 <div id="rfc.iref.3 2"></div>1021 <p id="rfc.section.8.2.5.p.3">The 204 response <em class="bcp14">MUST NOT</em> include a message-body, and thus is always terminated by the first empty line after the header fields. 1022 </p> 1023 <div id="rfc.iref.30"></div> 1038 1024 <div id="rfc.iref.s.8"></div> 1039 <h3 id="rfc.section. 9.2.6"><a href="#rfc.section.9.2.6">9.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3>1040 <p id="rfc.section. 9.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions1025 <h3 id="rfc.section.8.2.6"><a href="#rfc.section.8.2.6">8.2.6</a> <a id="status.205" href="#status.205">205 Reset Content</a></h3> 1026 <p id="rfc.section.8.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions 1041 1027 to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate 1042 1028 another input action. The response <em class="bcp14">MUST NOT</em> include an entity. 1043 1029 </p> 1044 <div id="rfc.iref.3 3"></div>1030 <div id="rfc.iref.31"></div> 1045 1031 <div id="rfc.iref.s.9"></div> 1046 <h3 id="rfc.section. 9.2.7"><a href="#rfc.section.9.2.7">9.2.7</a> <a id="status.206" href="#status.206">206 Partial Content</a></h3>1047 <p id="rfc.section. 9.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined1032 <h3 id="rfc.section.8.2.7"><a href="#rfc.section.8.2.7">8.2.7</a> <a id="status.206" href="#status.206">206 Partial Content</a></h3> 1033 <p id="rfc.section.8.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined 1048 1034 in <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1049 1035 </p> 1050 <h2 id="rfc.section. 9.3"><a href="#rfc.section.9.3">9.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>1051 <p id="rfc.section. 9.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.1036 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> 1037 <p id="rfc.section.8.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. 1052 1038 The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is 1053 1039 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. … … 1058 1044 </dd> 1059 1045 </dl> 1060 <div id="rfc.iref.3 4"></div>1046 <div id="rfc.iref.32"></div> 1061 1047 <div id="rfc.iref.s.10"></div> 1062 <h3 id="rfc.section. 9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3>1063 <p id="rfc.section. 9.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven1048 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1049 <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven 1064 1050 negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</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>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that 1065 1051 location. 1066 1052 </p> 1067 <p id="rfc.section. 9.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose1053 <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose 1068 1054 the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending 1069 1055 upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1070 1056 </p> 1071 <p id="rfc.section. 9.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.1072 </p> 1073 <div id="rfc.iref.3 5"></div>1057 <p id="rfc.section.8.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise. 1058 </p> 1059 <div id="rfc.iref.33"></div> 1074 1060 <div id="rfc.iref.s.11"></div> 1075 <h3 id="rfc.section. 9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3>1076 <p id="rfc.section. 9.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI1061 <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 1062 <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI 1077 1063 to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. 1078 1064 </p> 1079 <p id="rfc.section. 9.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).1080 </p> 1081 <p id="rfc.section. 9.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1065 <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1066 </p> 1067 <p id="rfc.section.8.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1082 1068 the request was issued. 1083 1069 </p> … … 1087 1073 </dd> 1088 1074 </dl> 1089 <div id="rfc.iref.3 6"></div>1075 <div id="rfc.iref.34"></div> 1090 1076 <div id="rfc.iref.s.12"></div> 1091 <h3 id="rfc.section. 9.3.3"><a href="#rfc.section.9.3.3">9.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3>1092 <p id="rfc.section. 9.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the1077 <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> 1078 <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the 1093 1079 client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires 1094 1080 header field. 1095 1081 </p> 1096 <p id="rfc.section. 9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).1097 </p> 1098 <p id="rfc.section. 9.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1082 <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1083 </p> 1084 <p id="rfc.section.8.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1099 1085 the request was issued. 1100 1086 </p> … … 1106 1092 </dd> 1107 1093 </dl> 1108 <div id="rfc.iref.3 7"></div>1094 <div id="rfc.iref.35"></div> 1109 1095 <div id="rfc.iref.s.13"></div> 1110 <h3 id="rfc.section. 9.3.4"><a href="#rfc.section.9.3.4">9.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3>1111 <p id="rfc.section. 9.3.4.p.1">The response to the request can be found under a different URI and <em class="bcp14">SHOULD</em> be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script1096 <h3 id="rfc.section.8.3.4"><a href="#rfc.section.8.3.4">8.3.4</a> <a id="status.303" href="#status.303">303 See Other</a></h3> 1097 <p id="rfc.section.8.3.4.p.1">The response to the request can be found under a different URI and <em class="bcp14">SHOULD</em> be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script 1112 1098 to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested 1113 1099 resource. The 303 response <em class="bcp14">MUST NOT</em> be cached, but the response to the second (redirected) request might be cacheable. 1114 1100 </p> 1115 <p id="rfc.section. 9.3.4.p.2">The different URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).1101 <p id="rfc.section.8.3.4.p.2">The different URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1116 1102 </p> 1117 1103 <dl class="empty"> … … 1120 1106 </dd> 1121 1107 </dl> 1122 <div id="rfc.iref.3 8"></div>1108 <div id="rfc.iref.36"></div> 1123 1109 <div id="rfc.iref.s.14"></div> 1124 <h3 id="rfc.section. 9.3.5"><a href="#rfc.section.9.3.5">9.3.5</a> <a id="status.304" href="#status.304">304 Not Modified</a></h3>1125 <p id="rfc.section. 9.3.5.p.1">The response to the request has not been modified since the conditions indicated by the client's conditional GET request,1110 <h3 id="rfc.section.8.3.5"><a href="#rfc.section.8.3.5">8.3.5</a> <a id="status.304" href="#status.304">304 Not Modified</a></h3> 1111 <p id="rfc.section.8.3.5.p.1">The response to the request has not been modified since the conditions indicated by the client's conditional GET request, 1126 1112 as defined in <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1127 1113 </p> 1128 <div id="rfc.iref.3 9"></div>1114 <div id="rfc.iref.37"></div> 1129 1115 <div id="rfc.iref.s.15"></div> 1130 <h3 id="rfc.section. 9.3.6"><a href="#rfc.section.9.3.6">9.3.6</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3>1131 <p id="rfc.section. 9.3.6.p.1">The requested resource <em class="bcp14">MUST</em> be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is1116 <h3 id="rfc.section.8.3.6"><a href="#rfc.section.8.3.6">8.3.6</a> <a id="status.305" href="#status.305">305 Use Proxy</a></h3> 1117 <p id="rfc.section.8.3.6.p.1">The requested resource <em class="bcp14">MUST</em> be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is 1132 1118 expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers. 1133 1119 </p> … … 1137 1123 </dd> 1138 1124 </dl> 1139 <div id="rfc.iref. 40"></div>1125 <div id="rfc.iref.38"></div> 1140 1126 <div id="rfc.iref.s.16"></div> 1141 <h3 id="rfc.section. 9.3.7"><a href="#rfc.section.9.3.7">9.3.7</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3>1142 <p id="rfc.section. 9.3.7.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p>1143 <div id="rfc.iref. 41"></div>1127 <h3 id="rfc.section.8.3.7"><a href="#rfc.section.8.3.7">8.3.7</a> <a id="status.306" href="#status.306">306 (Unused)</a></h3> 1128 <p id="rfc.section.8.3.7.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p> 1129 <div id="rfc.iref.39"></div> 1144 1130 <div id="rfc.iref.s.17"></div> 1145 <h3 id="rfc.section. 9.3.8"><a href="#rfc.section.9.3.8">9.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>1146 <p id="rfc.section. 9.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires1131 <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 1132 <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires 1147 1133 header field. 1148 1134 </p> 1149 <p id="rfc.section. 9.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand1135 <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand 1150 1136 the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI. 1151 1137 </p> 1152 <p id="rfc.section. 9.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1138 <p id="rfc.section.8.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1153 1139 the request was issued. 1154 1140 </p> 1155 <h2 id="rfc.section. 9.4"><a href="#rfc.section.9.4">9.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>1156 <p id="rfc.section. 9.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD1141 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> 1142 <p id="rfc.section.8.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD 1157 1143 request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. 1158 1144 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user. 1159 1145 </p> 1160 <p id="rfc.section. 9.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes1146 <p id="rfc.section.8.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes 1161 1147 the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send 1162 1148 a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted 1163 1149 by the HTTP application. 1164 1150 </p> 1151 <div id="rfc.iref.40"></div> 1152 <div id="rfc.iref.s.18"></div> 1153 <h3 id="rfc.section.8.4.1"><a href="#rfc.section.8.4.1">8.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> 1154 <p id="rfc.section.8.4.1.p.1">The request could not be understood by the server due to malformed syntax. The client <em class="bcp14">SHOULD NOT</em> repeat the request without modifications. 1155 </p> 1156 <div id="rfc.iref.41"></div> 1157 <div id="rfc.iref.s.19"></div> 1158 <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h3> 1159 <p id="rfc.section.8.4.2.p.1">The request requires user authentication (see <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). 1160 </p> 1165 1161 <div id="rfc.iref.42"></div> 1166 <div id="rfc.iref.s.18"></div> 1167 <h3 id="rfc.section.9.4.1"><a href="#rfc.section.9.4.1">9.4.1</a> <a id="status.400" href="#status.400">400 Bad Request</a></h3> 1168 <p id="rfc.section.9.4.1.p.1">The request could not be understood by the server due to malformed syntax. The client <em class="bcp14">SHOULD NOT</em> repeat the request without modifications. 1169 </p> 1162 <div id="rfc.iref.s.20"></div> 1163 <h3 id="rfc.section.8.4.3"><a href="#rfc.section.8.4.3">8.4.3</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3> 1164 <p id="rfc.section.8.4.3.p.1">This code is reserved for future use.</p> 1170 1165 <div id="rfc.iref.43"></div> 1171 <div id="rfc.iref.s.19"></div>1172 <h3 id="rfc.section.9.4.2"><a href="#rfc.section.9.4.2">9.4.2</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h3>1173 <p id="rfc.section.9.4.2.p.1">The request requires user authentication (see <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>).1174 </p>1175 <div id="rfc.iref.44"></div>1176 <div id="rfc.iref.s.20"></div>1177 <h3 id="rfc.section.9.4.3"><a href="#rfc.section.9.4.3">9.4.3</a> <a id="status.402" href="#status.402">402 Payment Required</a></h3>1178 <p id="rfc.section.9.4.3.p.1">This code is reserved for future use.</p>1179 <div id="rfc.iref.45"></div>1180 1166 <div id="rfc.iref.s.21"></div> 1181 <h3 id="rfc.section. 9.4.4"><a href="#rfc.section.9.4.4">9.4.4</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3>1182 <p id="rfc.section. 9.4.4.p.1">The server understood the request, but is refusing to fulfill it. Authorization will not help and the request <em class="bcp14">SHOULD NOT</em> be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled,1167 <h3 id="rfc.section.8.4.4"><a href="#rfc.section.8.4.4">8.4.4</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> 1168 <p id="rfc.section.8.4.4.p.1">The server understood the request, but is refusing to fulfill it. Authorization will not help and the request <em class="bcp14">SHOULD NOT</em> be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, 1183 1169 it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, 1184 1170 the status code 404 (Not Found) can be used instead. 1185 1171 </p> 1186 <div id="rfc.iref.4 6"></div>1172 <div id="rfc.iref.44"></div> 1187 1173 <div id="rfc.iref.s.22"></div> 1188 <h3 id="rfc.section. 9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3>1189 <p id="rfc.section. 9.4.5.p.1">The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or1174 <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1175 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or 1190 1176 permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1191 1177 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request 1192 1178 has been refused, or when no other response is applicable. 1193 1179 </p> 1194 <div id="rfc.iref.4 7"></div>1180 <div id="rfc.iref.45"></div> 1195 1181 <div id="rfc.iref.s.23"></div> 1196 <h3 id="rfc.section. 9.4.6"><a href="#rfc.section.9.4.6">9.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>1197 <p id="rfc.section. 9.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1198 </p> 1199 <div id="rfc.iref.4 8"></div>1182 <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1183 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1184 </p> 1185 <div id="rfc.iref.46"></div> 1200 1186 <div id="rfc.iref.s.24"></div> 1201 <h3 id="rfc.section. 9.4.7"><a href="#rfc.section.9.4.7">9.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3>1202 <p id="rfc.section. 9.4.7.p.1">The resource identified by the request is only capable of generating response entities which have content characteristics1187 <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1188 <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response entities which have content characteristics 1203 1189 not acceptable according to the accept headers sent in the request. 1204 1190 </p> 1205 <p id="rfc.section. 9.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent1191 <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent 1206 1192 can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. 1207 1193 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. … … 1213 1199 </dd> 1214 1200 </dl> 1215 <p id="rfc.section.9.4.7.p.3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 1201 <p id="rfc.section.8.4.7.p.3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 1202 </p> 1203 <div id="rfc.iref.47"></div> 1204 <div id="rfc.iref.s.25"></div> 1205 <h3 id="rfc.section.8.4.8"><a href="#rfc.section.8.4.8">8.4.8</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h3> 1206 <p id="rfc.section.8.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy (see <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). 1207 </p> 1208 <div id="rfc.iref.48"></div> 1209 <div id="rfc.iref.s.26"></div> 1210 <h3 id="rfc.section.8.4.9"><a href="#rfc.section.8.4.9">8.4.9</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> 1211 <p id="rfc.section.8.4.9.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. 1216 1212 </p> 1217 1213 <div id="rfc.iref.49"></div> 1218 <div id="rfc.iref.s.25"></div>1219 <h3 id="rfc.section.9.4.8"><a href="#rfc.section.9.4.8">9.4.8</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h3>1220 <p id="rfc.section.9.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy (see <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>).1221 </p>1222 <div id="rfc.iref.50"></div>1223 <div id="rfc.iref.s.26"></div>1224 <h3 id="rfc.section.9.4.9"><a href="#rfc.section.9.4.9">9.4.9</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3>1225 <p id="rfc.section.9.4.9.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time.1226 </p>1227 <div id="rfc.iref.51"></div>1228 1214 <div id="rfc.iref.s.27"></div> 1229 <h3 id="rfc.section. 9.4.10"><a href="#rfc.section.9.4.10">9.4.10</a> <a id="status.409" href="#status.409">409 Conflict</a></h3>1230 <p id="rfc.section. 9.4.10.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in1215 <h3 id="rfc.section.8.4.10"><a href="#rfc.section.8.4.10">8.4.10</a> <a id="status.409" href="#status.409">409 Conflict</a></h3> 1216 <p id="rfc.section.8.4.10.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in 1231 1217 situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response 1232 1218 body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include 1233 1219 enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. 1234 1220 </p> 1235 <p id="rfc.section. 9.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity1221 <p id="rfc.section.8.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity 1236 1222 being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might 1237 1223 use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain 1238 1224 a list of the differences between the two versions in a format defined by the response Content-Type. 1239 1225 </p> 1240 <div id="rfc.iref.5 2"></div>1226 <div id="rfc.iref.50"></div> 1241 1227 <div id="rfc.iref.s.28"></div> 1242 <h3 id="rfc.section. 9.4.11"><a href="#rfc.section.9.4.11">9.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3>1243 <p id="rfc.section. 9.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected1228 <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3> 1229 <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected 1244 1230 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether 1245 1231 or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise. 1246 1232 </p> 1247 <p id="rfc.section. 9.4.11.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource1233 <p id="rfc.section.8.4.11.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource 1248 1234 is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event 1249 1235 is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's … … 1251 1237 -- that is left to the discretion of the server owner. 1252 1238 </p> 1239 <div id="rfc.iref.51"></div> 1240 <div id="rfc.iref.s.29"></div> 1241 <h3 id="rfc.section.8.4.12"><a href="#rfc.section.8.4.12">8.4.12</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 1242 <p id="rfc.section.8.4.12.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request 1243 message. 1244 </p> 1245 <div id="rfc.iref.52"></div> 1246 <div id="rfc.iref.s.30"></div> 1247 <h3 id="rfc.section.8.4.13"><a href="#rfc.section.8.4.13">8.4.13</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h3> 1248 <p id="rfc.section.8.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as 1249 defined in <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 1250 </p> 1253 1251 <div id="rfc.iref.53"></div> 1254 <div id="rfc.iref.s.29"></div> 1255 <h3 id="rfc.section.9.4.12"><a href="#rfc.section.9.4.12">9.4.12</a> <a id="status.411" href="#status.411">411 Length Required</a></h3> 1256 <p id="rfc.section.9.4.12.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request 1257 message. 1252 <div id="rfc.iref.s.31"></div> 1253 <h3 id="rfc.section.8.4.14"><a href="#rfc.section.8.4.14">8.4.14</a> <a id="status.413" href="#status.413">413 Request Entity Too Large</a></h3> 1254 <p id="rfc.section.8.4.14.p.1">The server is refusing to process a request because the request entity is larger than the server is willing or able to process. 1255 The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. 1256 </p> 1257 <p id="rfc.section.8.4.14.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. 1258 1258 </p> 1259 1259 <div id="rfc.iref.54"></div> 1260 <div id="rfc.iref.s.30"></div>1261 <h3 id="rfc.section.9.4.13"><a href="#rfc.section.9.4.13">9.4.13</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h3>1262 <p id="rfc.section.9.4.13.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server, as1263 defined in <a href="#Part4" id="rfc.xref.Part4.8"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.1264 </p>1265 <div id="rfc.iref.55"></div>1266 <div id="rfc.iref.s.31"></div>1267 <h3 id="rfc.section.9.4.14"><a href="#rfc.section.9.4.14">9.4.14</a> <a id="status.413" href="#status.413">413 Request Entity Too Large</a></h3>1268 <p id="rfc.section.9.4.14.p.1">The server is refusing to process a request because the request entity is larger than the server is willing or able to process.1269 The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.1270 </p>1271 <p id="rfc.section.9.4.14.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.1272 </p>1273 <div id="rfc.iref.56"></div>1274 1260 <div id="rfc.iref.s.32"></div> 1275 <h3 id="rfc.section. 9.4.15"><a href="#rfc.section.9.4.15">9.4.15</a> <a id="status.414" href="#status.414">414 Request-URI Too Long</a></h3>1276 <p id="rfc.section. 9.4.15.p.1">The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This1261 <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a> <a id="status.414" href="#status.414">414 Request-URI Too Long</a></h3> 1262 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This 1277 1263 rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query 1278 1264 information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points … … 1280 1266 servers using fixed-length buffers for reading or manipulating the Request-URI. 1281 1267 </p> 1268 <div id="rfc.iref.55"></div> 1269 <div id="rfc.iref.s.33"></div> 1270 <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 1271 <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the entity of the request is in a format not supported by the requested 1272 resource for the requested method. 1273 </p> 1274 <div id="rfc.iref.56"></div> 1275 <div id="rfc.iref.s.34"></div> 1276 <h3 id="rfc.section.8.4.17"><a href="#rfc.section.8.4.17">8.4.17</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3> 1277 <p id="rfc.section.8.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource. 1278 </p> 1282 1279 <div id="rfc.iref.57"></div> 1283 <div id="rfc.iref.s.33"></div>1284 <h3 id="rfc.section.9.4.16"><a href="#rfc.section.9.4.16">9.4.16</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>1285 <p id="rfc.section.9.4.16.p.1">The server is refusing to service the request because the entity of the request is in a format not supported by the requested1286 resource for the requested method.1287 </p>1288 <div id="rfc.iref.58"></div>1289 <div id="rfc.iref.s.34"></div>1290 <h3 id="rfc.section.9.4.17"><a href="#rfc.section.9.4.17">9.4.17</a> <a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h3>1291 <p id="rfc.section.9.4.17.p.1">The request included a Range request-header field (<a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and none of the range-specifier values in this field overlap the current extent of the selected resource.1292 </p>1293 <div id="rfc.iref.59"></div>1294 1280 <div id="rfc.iref.s.35"></div> 1295 <h3 id="rfc.section. 9.4.18"><a href="#rfc.section.9.4.18">9.4.18</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3>1296 <p id="rfc.section. 9.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 10.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could1281 <h3 id="rfc.section.8.4.18"><a href="#rfc.section.8.4.18">8.4.18</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 1282 <p id="rfc.section.8.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 9.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 1297 1283 not be met by the next-hop server. 1298 1284 </p> 1299 <h2 id="rfc.section. 9.5"><a href="#rfc.section.9.5">9.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>1300 <p id="rfc.section. 9.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable1285 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> 1286 <p id="rfc.section.8.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable 1301 1287 of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. 1302 1288 User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method. 1303 1289 </p> 1290 <div id="rfc.iref.58"></div> 1291 <div id="rfc.iref.s.36"></div> 1292 <h3 id="rfc.section.8.5.1"><a href="#rfc.section.8.5.1">8.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> 1293 <p id="rfc.section.8.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> 1294 <div id="rfc.iref.59"></div> 1295 <div id="rfc.iref.s.37"></div> 1296 <h3 id="rfc.section.8.5.2"><a href="#rfc.section.8.5.2">8.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3> 1297 <p id="rfc.section.8.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server 1298 does not recognize the request method and is not capable of supporting it for any resource. 1299 </p> 1304 1300 <div id="rfc.iref.60"></div> 1305 <div id="rfc.iref.s.36"></div> 1306 <h3 id="rfc.section.9.5.1"><a href="#rfc.section.9.5.1">9.5.1</a> <a id="status.500" href="#status.500">500 Internal Server Error</a></h3> 1307 <p id="rfc.section.9.5.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p> 1301 <div id="rfc.iref.s.38"></div> 1302 <h3 id="rfc.section.8.5.3"><a href="#rfc.section.8.5.3">8.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3> 1303 <p id="rfc.section.8.5.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting 1304 to fulfill the request. 1305 </p> 1308 1306 <div id="rfc.iref.61"></div> 1309 <div id="rfc.iref.s.37"></div>1310 <h3 id="rfc.section.9.5.2"><a href="#rfc.section.9.5.2">9.5.2</a> <a id="status.501" href="#status.501">501 Not Implemented</a></h3>1311 <p id="rfc.section.9.5.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server1312 does not recognize the request method and is not capable of supporting it for any resource.1313 </p>1314 <div id="rfc.iref.62"></div>1315 <div id="rfc.iref.s.38"></div>1316 <h3 id="rfc.section.9.5.3"><a href="#rfc.section.9.5.3">9.5.3</a> <a id="status.502" href="#status.502">502 Bad Gateway</a></h3>1317 <p id="rfc.section.9.5.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting1318 to fulfill the request.1319 </p>1320 <div id="rfc.iref.63"></div>1321 1307 <div id="rfc.iref.s.39"></div> 1322 <h3 id="rfc.section. 9.5.4"><a href="#rfc.section.9.5.4">9.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3>1323 <p id="rfc.section. 9.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication1308 <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 1309 <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication 1324 1310 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1325 1311 </p> … … 1329 1315 </dd> 1330 1316 </dl> 1331 <div id="rfc.iref.6 4"></div>1317 <div id="rfc.iref.62"></div> 1332 1318 <div id="rfc.iref.s.40"></div> 1333 <h3 id="rfc.section. 9.5.5"><a href="#rfc.section.9.5.5">9.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>1334 <p id="rfc.section. 9.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the1319 <h3 id="rfc.section.8.5.5"><a href="#rfc.section.8.5.5">8.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> 1320 <p id="rfc.section.8.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the 1335 1321 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 1336 1322 </p> … … 1339 1325 </dd> 1340 1326 </dl> 1341 <div id="rfc.iref.6 5"></div>1327 <div id="rfc.iref.63"></div> 1342 1328 <div id="rfc.iref.s.41"></div> 1343 <h3 id="rfc.section. 9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>1344 <p id="rfc.section. 9.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server1329 <h3 id="rfc.section.8.5.6"><a href="#rfc.section.8.5.6">8.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> 1330 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1345 1331 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1346 1332 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server. 1347 1333 </p> 1348 <h1 id="rfc.section. 10"><a href="#rfc.section.10">10.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>1349 <p id="rfc.section. 10.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>1350 <p id="rfc.section. 10.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1334 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1335 <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 1336 <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 1351 1337 receives the entity. 1352 1338 </p> 1353 1339 <div id="rfc.iref.a.1"></div> 1354 1340 <div id="rfc.iref.h.2"></div> 1355 <h2 id="rfc.section. 10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2>1356 <p id="rfc.section. 10.1.p.1">The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose1341 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1342 <p id="rfc.section.9.1.p.1">The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose 1357 1343 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. 1358 1344 </p> 1359 <div id="rfc.figure.u. 7"></div><pre class="inline"><span id="rfc.iref.g.11"></span> Allow = "Allow" ":" #Method1360 </pre><p id="rfc.section. 10.1.p.3">Example of use:</p>1361 <div id="rfc.figure.u. 8"></div><pre class="text"> Allow: GET, HEAD, PUT1362 </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.1363 </p> 1364 <p id="rfc.section. 10.1.p.6">The Allow header field <em class="bcp14">MAY</em> be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not1345 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Allow = "Allow" ":" #Method 1346 </pre><p id="rfc.section.9.1.p.3">Example of use:</p> 1347 <div id="rfc.figure.u.6"></div><pre class="text"> Allow: GET, HEAD, PUT 1348 </pre><p id="rfc.section.9.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. 1349 </p> 1350 <p id="rfc.section.9.1.p.6">The Allow header field <em class="bcp14">MAY</em> be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not 1365 1351 required to support these methods and <em class="bcp14">SHOULD</em> include an Allow header in the response giving the actual supported methods. 1366 1352 </p> 1367 <p id="rfc.section. 10.1.p.7">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other1353 <p id="rfc.section.9.1.p.7">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other 1368 1354 means of communicating with the origin server. 1369 1355 </p> 1370 1356 <div id="rfc.iref.e.1"></div> 1371 1357 <div id="rfc.iref.h.3"></div> 1372 <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>1373 <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>1374 <div id="rfc.figure.u. 9"></div><pre class="inline"><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> Expect = "Expect" ":" 1#expectation1358 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1359 <p id="rfc.section.9.2.p.1">The Expect request-header field is used to indicate that particular server behaviors are required by the client.</p> 1360 <div id="rfc.figure.u.7"></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 1375 1361 1376 1362 expectation = "100-continue" | expectation-extension … … 1378 1364 *expect-params ] 1379 1365 expect-params = ";" token [ "=" ( token | quoted-string ) ] 1380 </pre><p id="rfc.section. 10.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with1366 </pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with 1381 1367 the request, some other 4xx status. 1382 1368 </p> 1383 <p id="rfc.section. 10.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing1369 <p id="rfc.section.9.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing 1384 1370 an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status. 1385 1371 </p> 1386 <p id="rfc.section. 10.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive1372 <p id="rfc.section.9.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive 1387 1373 for quoted-string expectation-extensions. 1388 1374 </p> 1389 <p id="rfc.section. 10.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect1375 <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect 1390 1376 request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1391 1377 </p> 1392 <p id="rfc.section. 10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>1393 <p id="rfc.section. 10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.1378 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> 1379 <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status. 1394 1380 </p> 1395 1381 <div id="rfc.iref.f.1"></div> 1396 1382 <div id="rfc.iref.h.4"></div> 1397 <h2 id="rfc.section. 10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.from" href="#header.from">From</a></h2>1398 <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>:1399 </p> 1400 <div id="rfc.figure.u. 10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> From = "From" ":" mailbox1401 </pre><p id="rfc.section. 10.3.p.3">An example is:</p>1402 <div id="rfc.figure.u. 11"></div><pre class="text"> From: webmaster@example.org1403 </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 performed1383 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.from" href="#header.from">From</a></h2> 1384 <p id="rfc.section.9.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>: 1385 </p> 1386 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.14"></span> From = "From" ":" mailbox 1387 </pre><p id="rfc.section.9.3.p.3">An example is:</p> 1388 <div id="rfc.figure.u.9"></div><pre class="text"> From: webmaster@example.org 1389 </pre><p id="rfc.section.9.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 1404 1390 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 1405 1391 end. 1406 1392 </p> 1407 <p id="rfc.section. 10.3.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original1393 <p id="rfc.section.9.3.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 1408 1394 issuer's address <em class="bcp14">SHOULD</em> be used. 1409 1395 </p> 1410 <p id="rfc.section. 10.3.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's1396 <p id="rfc.section.9.3.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 1411 1397 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 1412 1398 any time prior to a request. … … 1414 1400 <div id="rfc.iref.l.1"></div> 1415 1401 <div id="rfc.iref.h.5"></div> 1416 <h2 id="rfc.section. 10.4"><a href="#rfc.section.10.4">10.4</a> <a id="header.location" href="#header.location">Location</a></h2>1417 <p id="rfc.section. 10.4.p.1">The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion1402 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.location" href="#header.location">Location</a></h2> 1403 <p id="rfc.section.9.4.p.1">The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion 1418 1404 of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource 1419 1405 which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute 1420 1406 URI. 1421 1407 </p> 1422 <div id="rfc.figure.u.1 2"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Location = "Location" ":" absoluteURI [ "#" fragment ]1423 </pre><p id="rfc.section. 10.4.p.3">An example is:</p>1424 <div id="rfc.figure.u.1 3"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html1425 </pre><p id="rfc.section. 10.4.p.5"> </p>1408 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.15"></span> Location = "Location" ":" absoluteURI [ "#" fragment ] 1409 </pre><p id="rfc.section.9.4.p.3">An example is:</p> 1410 <div id="rfc.figure.u.11"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1411 </pre><p id="rfc.section.9.4.p.5"> </p> 1426 1412 <dl class="empty"> 1427 1413 <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</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>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. … … 1429 1415 </dd> 1430 1416 </dl> 1431 <p id="rfc.section. 10.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p>1417 <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p> 1432 1418 <ul> 1433 1419 <li>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</li> … … 1439 1425 <div id="rfc.iref.m.9"></div> 1440 1426 <div id="rfc.iref.h.6"></div> 1441 <h2 id="rfc.section. 10.5"><a href="#rfc.section.10.5">10.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>1442 <p id="rfc.section. 10.5.p.1">The Max-Forwards request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 8.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 8.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be1427 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 1428 <p id="rfc.section.9.5.p.1">The Max-Forwards request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be 1443 1429 useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. 1444 1430 </p> 1445 <div id="rfc.figure.u.1 4"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT1446 </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>1447 <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).1448 </p> 1449 <p id="rfc.section. 10.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly1431 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.16"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1432 </pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p> 1433 <p id="rfc.section.9.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). 1434 </p> 1435 <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly 1450 1436 referred to as part of that method definition. 1451 1437 </p> 1452 1438 <div id="rfc.iref.r.1"></div> 1453 1439 <div id="rfc.iref.h.7"></div> 1454 <h2 id="rfc.section. 10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2>1455 <p id="rfc.section. 10.6.p.1">The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource1440 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1441 <p id="rfc.section.9.6.p.1">The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource 1456 1442 from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header 1457 1443 allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows 1458 1444 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. 1459 1445 </p> 1460 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI )1461 </pre><p id="rfc.section. 10.6.p.3">Example:</p>1462 <div id="rfc.figure.u.1 6"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html1463 </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.1446 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1447 </pre><p id="rfc.section.9.6.p.3">Example:</p> 1448 <div id="rfc.figure.u.14"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1449 </pre><p id="rfc.section.9.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 11.2</a> for security considerations. 1464 1450 </p> 1465 1451 <div id="rfc.iref.r.2"></div> 1466 1452 <div id="rfc.iref.h.8"></div> 1467 <h2 id="rfc.section. 10.7"><a href="#rfc.section.10.7">10.7</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>1468 <p id="rfc.section. 10.7.p.1">The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service1453 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 1454 <p id="rfc.section.9.7.p.1">The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service 1469 1455 is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing 1470 1456 the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after 1471 1457 the time of the response. 1472 1458 </p> 1473 <div id="rfc.figure.u.1 7"></div><pre class="inline"><span id="rfc.iref.g.20"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )1474 </pre><p id="rfc.section. 10.7.p.3">Two examples of its use are</p>1475 <div id="rfc.figure.u.1 8"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT1459 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1460 </pre><p id="rfc.section.9.7.p.3">Two examples of its use are</p> 1461 <div id="rfc.figure.u.16"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1476 1462 Retry-After: 120 1477 </pre><p id="rfc.section. 10.7.p.5">In the latter example, the delay is 2 minutes.</p>1463 </pre><p id="rfc.section.9.7.p.5">In the latter example, the delay is 2 minutes.</p> 1478 1464 <div id="rfc.iref.s.42"></div> 1479 1465 <div id="rfc.iref.h.9"></div> 1480 <h2 id="rfc.section. 10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.server" href="#header.server">Server</a></h2>1481 <p id="rfc.section. 10.8.p.1">The Server response-header field contains information about the software used by the origin server to handle the request.1482 The field can contain multiple product tokens (<a href=" #product.tokens" title="Product Tokens">Section 2</a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance1466 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1467 <p id="rfc.section.9.8.p.1">The Server response-header field contains information about the software used by the origin server to handle the request. 1468 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance 1483 1469 for identifying the application. 1484 1470 </p> 1485 <div id="rfc.figure.u.1 9"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Server = "Server" ":" 1*( product | comment )1486 </pre><p id="rfc.section. 10.8.p.3">Example:</p>1487 <div id="rfc.figure.u. 20"></div><pre class="text"> Server: CERN/3.0 libwww/2.171488 </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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1471 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Server = "Server" ":" 1*( product | comment ) 1472 </pre><p id="rfc.section.9.8.p.3">Example:</p> 1473 <div id="rfc.figure.u.18"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1474 </pre><p id="rfc.section.9.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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1489 1475 </p> 1490 1476 <dl class="empty"> … … 1496 1482 <div id="rfc.iref.u.1"></div> 1497 1483 <div id="rfc.iref.h.10"></div> 1498 <h2 id="rfc.section. 10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>1499 <p id="rfc.section. 10.9.p.1">The User-Agent request-header field contains information about the user agent originating the request. This is for statistical1484 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 1485 <p id="rfc.section.9.9.p.1">The User-Agent request-header field contains information about the user agent originating the request. This is for statistical 1500 1486 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1501 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href=" #product.tokens" title="Product Tokens">Section 2</a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the1487 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the 1502 1488 product tokens are listed in order of their significance for identifying the application. 1503 1489 </p> 1504 <div id="rfc.figure.u. 21"></div><pre class="inline"><span id="rfc.iref.g.22"></span> User-Agent = "User-Agent" ":" 1*( product | comment )1505 </pre><p id="rfc.section. 10.9.p.3">Example:</p>1506 <div id="rfc.figure.u.2 2"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31507 </pre><h1 id="rfc.section.1 1"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1508 <p id="rfc.section.1 1.p.1">TBD.</p>1509 <h1 id="rfc.section.1 2"><a href="#rfc.section.12">12.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1510 <p id="rfc.section.1 2.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.11490 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.20"></span> User-Agent = "User-Agent" ":" 1*( product | comment ) 1491 </pre><p id="rfc.section.9.9.p.3">Example:</p> 1492 <div id="rfc.figure.u.20"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1493 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1494 <p id="rfc.section.10.p.1">TBD.</p> 1495 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1496 <p id="rfc.section.11.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 1511 1497 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 1512 1498 make some suggestions for reducing security risks. 1513 1499 </p> 1514 <h2 id="rfc.section.1 2.1"><a href="#rfc.section.12.1">12.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>1515 <p id="rfc.section.1 2.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any1500 <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2> 1501 <p id="rfc.section.11.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any 1516 1502 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 1517 1503 Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth 1518 1504 special mention in this context: Server, Via, Referer and From. 1519 1505 </p> 1520 <p id="rfc.section.1 2.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks1506 <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 1521 1507 against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option. 1522 1508 </p> 1523 <p id="rfc.section.1 2.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,1509 <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, 1524 1510 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 1525 1511 </p> 1526 <p id="rfc.section.1 2.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power1512 <p id="rfc.section.11.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power 1527 1513 can be abused if user details are not separated from the information contained in the Referer. Even when the personal information 1528 1514 has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. 1529 1515 </p> 1530 <p id="rfc.section.1 2.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and1516 <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and 1531 1517 hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration. 1532 1518 </p> 1533 <p id="rfc.section.1 2.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending1519 <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending 1534 1520 of From and Referer information. 1535 1521 </p> 1536 <p id="rfc.section.1 2.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.8</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which1522 <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 9.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 9.8</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which 1537 1523 might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently 1538 1524 has no better mechanism. 1539 1525 </p> 1540 <h2 id="rfc.section.1 2.2"><a href="#rfc.section.12.2">12.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>1541 <p id="rfc.section.1 2.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly1526 <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> 1527 <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly 1542 1528 recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could 1543 1529 have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From 1544 1530 information. 1545 1531 </p> 1546 <p id="rfc.section.1 2.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.1547 </p> 1548 <p id="rfc.section.1 2.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded1532 <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 1533 </p> 1534 <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded 1549 1535 in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might 1550 1536 be visible to third parties. Such services can use POST-based form submission instead. 1551 1537 </p> 1552 <h2 id="rfc.section.1 2.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>1553 <p id="rfc.section.1 2.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location headers in responses that are generated under control of said organizations1538 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> 1539 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location headers in responses that are generated under control of said organizations 1554 1540 to make sure that they do not attempt to invalidate resources over which they have no authority. 1555 1541 </p> 1556 <h1 id="rfc.section.1 3"><a href="#rfc.section.13">13.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1557 <h1 id="rfc.references"><a id="rfc.section.1 4" href="#rfc.section.14">14.</a> References1542 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1543 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References 1558 1544 </h1> 1559 <h2 id="rfc.references.1"><a href="#rfc.section.1 4.1" id="rfc.section.14.1">14.1</a> Normative References1545 <h2 id="rfc.references.1"><a href="#rfc.section.13.1" id="rfc.section.13.1">13.1</a> Normative References 1560 1546 </h2> 1561 1547 <table summary="Normative References"> … … 1596 1582 </tr> 1597 1583 </table> 1598 <h2 id="rfc.references.2"><a href="#rfc.section.1 4.2" id="rfc.section.14.2">14.2</a> Informative References1584 <h2 id="rfc.references.2"><a href="#rfc.section.13.2" id="rfc.section.13.2">13.2</a> Informative References 1599 1585 </h2> 1600 1586 <table summary="Informative References"> … … 1643 1629 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1644 1630 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 1645 <p id="rfc.section.A.1.p.1">Clarified which error code should be used for inbound server failures (e.g. DNS failures). (<a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 9.5.5</a>).1646 </p> 1647 <p id="rfc.section.A.1.p.2">201 (Created) had a race that required an Etag be sent when a resource is first created. (<a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 9.2.2</a>).1631 <p id="rfc.section.A.1.p.1">Clarified which error code should be used for inbound server failures (e.g. DNS failures). (<a href="#status.504" id="rfc.xref.status.504.2" title="504 Gateway Timeout">Section 8.5.5</a>). 1632 </p> 1633 <p id="rfc.section.A.1.p.2">201 (Created) had a race that required an Etag be sent when a resource is first created. (<a href="#status.201" id="rfc.xref.status.201.2" title="201 Created">Section 8.2.2</a>). 1648 1634 </p> 1649 1635 <p id="rfc.section.A.1.p.3">Rewrite of message transmission requirements to make it much harder for implementors to get it wrong, as the consequences … … 1665 1651 </ol> 1666 1652 <p id="rfc.section.A.1.p.4">This change adds the Expect header and 417 status code.</p> 1667 <p id="rfc.section.A.1.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden"> 9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>)1653 <p id="rfc.section.A.1.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">8.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">8.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">8.4.11</a>) 1668 1654 </p> 1669 1655 <p id="rfc.section.A.1.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1670 1656 </p> 1671 1657 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1672 <p id="rfc.section.A.2.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 8.5</a>)1658 <p id="rfc.section.A.2.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 7.5</a>) 1673 1659 </p> 1674 1660 <p id="rfc.section.A.2.p.2">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 1675 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently"> 9.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">9.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">9.3.8</a> )1661 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">8.3.8</a> ) 1676 1662 </p> 1677 1663 <p id="rfc.section.A.2.p.3">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications 1678 as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.4</a>)1664 as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 9.4</a>) 1679 1665 </p> 1680 1666 <p id="rfc.section.A.2.p.4">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 1681 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>)1667 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</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>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 9.8</a>) 1682 1668 </p> 1683 1669 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) … … 1720 1706 </li> 1721 1707 </ul> 1708 <p id="rfc.section.B.3.p.2">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 1709 </p> 1710 <ul> 1711 <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li> 1712 </ul> 1722 1713 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1723 1714 <p>Copyright © The IETF Trust (2008).</p> … … 1753 1744 <ul class="ind"> 1754 1745 <li class="indline0"><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul class="ind"> 1755 <li class="indline1">100 Continue (status code) <a class="iref" href="#rfc.xref.status.100.1"> 5</a>, <a class="iref" href="#rfc.iref.25"><b>9.1.1</b></a></li>1756 <li class="indline1">101 Switching Protocols (status code) <a class="iref" href="#rfc.xref.status.101.1"> 5</a>, <a class="iref" href="#rfc.iref.26"><b>9.1.2</b></a></li>1746 <li class="indline1">100 Continue (status code) <a class="iref" href="#rfc.xref.status.100.1">4</a>, <a class="iref" href="#rfc.iref.23"><b>8.1.1</b></a></li> 1747 <li class="indline1">101 Switching Protocols (status code) <a class="iref" href="#rfc.xref.status.101.1">4</a>, <a class="iref" href="#rfc.iref.24"><b>8.1.2</b></a></li> 1757 1748 </ul> 1758 1749 </li> 1759 1750 <li class="indline0"><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul class="ind"> 1760 <li class="indline1">200 OK (status code) <a class="iref" href="#rfc.xref.status.200.1"> 5</a>, <a class="iref" href="#rfc.iref.27"><b>9.2.1</b></a></li>1761 <li class="indline1">201 Created (status code) <a class="iref" href="#rfc.xref.status.201.1"> 5</a>, <a class="iref" href="#rfc.iref.28"><b>9.2.2</b></a>, <a class="iref" href="#rfc.xref.status.201.2">A.1</a></li>1762 <li class="indline1">202 Accepted (status code) <a class="iref" href="#rfc.xref.status.202.1"> 5</a>, <a class="iref" href="#rfc.iref.29"><b>9.2.3</b></a></li>1763 <li class="indline1">203 Non-Authoritative Information (status code) <a class="iref" href="#rfc.xref.status.203.1"> 5</a>, <a class="iref" href="#rfc.iref.30"><b>9.2.4</b></a></li>1764 <li class="indline1">204 No Content (status code) <a class="iref" href="#rfc.xref.status.204.1"> 5</a>, <a class="iref" href="#rfc.iref.31"><b>9.2.5</b></a></li>1765 <li class="indline1">205 Reset Content (status code) <a class="iref" href="#rfc.xref.status.205.1"> 5</a>, <a class="iref" href="#rfc.iref.32"><b>9.2.6</b></a></li>1766 <li class="indline1">206 Partial Content (status code) <a class="iref" href="#rfc.xref.status.206.1"> 5</a>, <a class="iref" href="#rfc.iref.33"><b>9.2.7</b></a></li>1751 <li class="indline1">200 OK (status code) <a class="iref" href="#rfc.xref.status.200.1">4</a>, <a class="iref" href="#rfc.iref.25"><b>8.2.1</b></a></li> 1752 <li class="indline1">201 Created (status code) <a class="iref" href="#rfc.xref.status.201.1">4</a>, <a class="iref" href="#rfc.iref.26"><b>8.2.2</b></a>, <a class="iref" href="#rfc.xref.status.201.2">A.1</a></li> 1753 <li class="indline1">202 Accepted (status code) <a class="iref" href="#rfc.xref.status.202.1">4</a>, <a class="iref" href="#rfc.iref.27"><b>8.2.3</b></a></li> 1754 <li class="indline1">203 Non-Authoritative Information (status code) <a class="iref" href="#rfc.xref.status.203.1">4</a>, <a class="iref" href="#rfc.iref.28"><b>8.2.4</b></a></li> 1755 <li class="indline1">204 No Content (status code) <a class="iref" href="#rfc.xref.status.204.1">4</a>, <a class="iref" href="#rfc.iref.29"><b>8.2.5</b></a></li> 1756 <li class="indline1">205 Reset Content (status code) <a class="iref" href="#rfc.xref.status.205.1">4</a>, <a class="iref" href="#rfc.iref.30"><b>8.2.6</b></a></li> 1757 <li class="indline1">206 Partial Content (status code) <a class="iref" href="#rfc.xref.status.206.1">4</a>, <a class="iref" href="#rfc.iref.31"><b>8.2.7</b></a></li> 1767 1758 </ul> 1768 1759 </li> 1769 1760 <li class="indline0"><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul class="ind"> 1770 <li class="indline1">300 Multiple Choices (status code) <a class="iref" href="#rfc.xref.status.300.1"> 5</a>, <a class="iref" href="#rfc.iref.34"><b>9.3.1</b></a></li>1771 <li class="indline1">301 Moved Permanently (status code) <a class="iref" href="#rfc.xref.status.301.1"> 5</a>, <a class="iref" href="#rfc.iref.35"><b>9.3.2</b></a>, <a class="iref" href="#rfc.xref.status.301.2">A.2</a></li>1772 <li class="indline1">302 Found (status code) <a class="iref" href="#rfc.xref.status.302.1"> 5</a>, <a class="iref" href="#rfc.iref.36"><b>9.3.3</b></a>, <a class="iref" href="#rfc.xref.status.302.2">A.2</a></li>1773 <li class="indline1">303 See Other (status code) <a class="iref" href="#rfc.xref.status.303.1"> 5</a>, <a class="iref" href="#rfc.iref.37"><b>9.3.4</b></a></li>1774 <li class="indline1">304 Not Modified (status code) <a class="iref" href="#rfc.xref.status.304.1"> 5</a>, <a class="iref" href="#rfc.iref.38"><b>9.3.5</b></a></li>1775 <li class="indline1">305 Use Proxy (status code) <a class="iref" href="#rfc.xref.status.305.1"> 5</a>, <a class="iref" href="#rfc.iref.39"><b>9.3.6</b></a></li>1776 <li class="indline1">306 (Unused) (status code) <a class="iref" href="#rfc.iref. 40"><b>9.3.7</b></a></li>1777 <li class="indline1">307 Temporary Redirect (status code) <a class="iref" href="#rfc.xref.status.307.1"> 5</a>, <a class="iref" href="#rfc.iref.41"><b>9.3.8</b></a>, <a class="iref" href="#rfc.xref.status.307.2">A.2</a></li>1761 <li class="indline1">300 Multiple Choices (status code) <a class="iref" href="#rfc.xref.status.300.1">4</a>, <a class="iref" href="#rfc.iref.32"><b>8.3.1</b></a></li> 1762 <li class="indline1">301 Moved Permanently (status code) <a class="iref" href="#rfc.xref.status.301.1">4</a>, <a class="iref" href="#rfc.iref.33"><b>8.3.2</b></a>, <a class="iref" href="#rfc.xref.status.301.2">A.2</a></li> 1763 <li class="indline1">302 Found (status code) <a class="iref" href="#rfc.xref.status.302.1">4</a>, <a class="iref" href="#rfc.iref.34"><b>8.3.3</b></a>, <a class="iref" href="#rfc.xref.status.302.2">A.2</a></li> 1764 <li class="indline1">303 See Other (status code) <a class="iref" href="#rfc.xref.status.303.1">4</a>, <a class="iref" href="#rfc.iref.35"><b>8.3.4</b></a></li> 1765 <li class="indline1">304 Not Modified (status code) <a class="iref" href="#rfc.xref.status.304.1">4</a>, <a class="iref" href="#rfc.iref.36"><b>8.3.5</b></a></li> 1766 <li class="indline1">305 Use Proxy (status code) <a class="iref" href="#rfc.xref.status.305.1">4</a>, <a class="iref" href="#rfc.iref.37"><b>8.3.6</b></a></li> 1767 <li class="indline1">306 (Unused) (status code) <a class="iref" href="#rfc.iref.38"><b>8.3.7</b></a></li> 1768 <li class="indline1">307 Temporary Redirect (status code) <a class="iref" href="#rfc.xref.status.307.1">4</a>, <a class="iref" href="#rfc.iref.39"><b>8.3.8</b></a>, <a class="iref" href="#rfc.xref.status.307.2">A.2</a></li> 1778 1769 </ul> 1779 1770 </li> 1780 1771 <li class="indline0"><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul class="ind"> 1781 <li class="indline1">400 Bad Request (status code) <a class="iref" href="#rfc.xref.status.400.1"> 5</a>, <a class="iref" href="#rfc.iref.42"><b>9.4.1</b></a></li>1782 <li class="indline1">401 Unauthorized (status code) <a class="iref" href="#rfc.xref.status.401.1"> 5</a>, <a class="iref" href="#rfc.iref.43"><b>9.4.2</b></a></li>1783 <li class="indline1">402 Payment Required (status code) <a class="iref" href="#rfc.xref.status.402.1"> 5</a>, <a class="iref" href="#rfc.iref.44"><b>9.4.3</b></a></li>1784 <li class="indline1">403 Forbidden (status code) <a class="iref" href="#rfc.xref.status.403.1"> 5</a>, <a class="iref" href="#rfc.iref.45"><b>9.4.4</b></a>, <a class="iref" href="#rfc.xref.status.403.2">A.1</a></li>1785 <li class="indline1">404 Not Found (status code) <a class="iref" href="#rfc.xref.status.404.1"> 5</a>, <a class="iref" href="#rfc.iref.46"><b>9.4.5</b></a>, <a class="iref" href="#rfc.xref.status.404.2">A.1</a></li>1786 <li class="indline1">405 Method Not Allowed (status code) <a class="iref" href="#rfc.xref.status.405.1"> 5</a>, <a class="iref" href="#rfc.iref.47"><b>9.4.6</b></a></li>1787 <li class="indline1">406 Not Acceptable (status code) <a class="iref" href="#rfc.xref.status.406.1"> 5</a>, <a class="iref" href="#rfc.iref.48"><b>9.4.7</b></a></li>1788 <li class="indline1">407 Proxy Authentication Required (status code) <a class="iref" href="#rfc.xref.status.407.1"> 5</a>, <a class="iref" href="#rfc.iref.49"><b>9.4.8</b></a></li>1789 <li class="indline1">408 Request Timeout (status code) <a class="iref" href="#rfc.xref.status.408.1"> 5</a>, <a class="iref" href="#rfc.iref.50"><b>9.4.9</b></a></li>1790 <li class="indline1">409 Conflict (status code) <a class="iref" href="#rfc.xref.status.409.1"> 5</a>, <a class="iref" href="#rfc.iref.51"><b>9.4.10</b></a></li>1791 <li class="indline1">410 Gone (status code) <a class="iref" href="#rfc.xref.status.410.1"> 5</a>, <a class="iref" href="#rfc.iref.52"><b>9.4.11</b></a>, <a class="iref" href="#rfc.xref.status.410.2">A.1</a></li>1792 <li class="indline1">411 Length Required (status code) <a class="iref" href="#rfc.xref.status.411.1"> 5</a>, <a class="iref" href="#rfc.iref.53"><b>9.4.12</b></a></li>1793 <li class="indline1">412 Precondition Failed (status code) <a class="iref" href="#rfc.xref.status.412.1"> 5</a>, <a class="iref" href="#rfc.iref.54"><b>9.4.13</b></a></li>1794 <li class="indline1">413 Request Entity Too Large (status code) <a class="iref" href="#rfc.xref.status.413.1"> 5</a>, <a class="iref" href="#rfc.iref.55"><b>9.4.14</b></a></li>1795 <li class="indline1">414 Request-URI Too Long (status code) <a class="iref" href="#rfc.xref.status.414.1"> 5</a>, <a class="iref" href="#rfc.iref.56"><b>9.4.15</b></a></li>1796 <li class="indline1">415 Unsupported Media Type (status code) <a class="iref" href="#rfc.xref.status.415.1"> 5</a>, <a class="iref" href="#rfc.iref.57"><b>9.4.16</b></a></li>1797 <li class="indline1">416 Requested Range Not Satisfiable (status code) <a class="iref" href="#rfc.xref.status.416.1"> 5</a>, <a class="iref" href="#rfc.iref.58"><b>9.4.17</b></a></li>1798 <li class="indline1">417 Expectation Failed (status code) <a class="iref" href="#rfc.xref.status.417.1"> 5</a>, <a class="iref" href="#rfc.iref.59"><b>9.4.18</b></a></li>1772 <li class="indline1">400 Bad Request (status code) <a class="iref" href="#rfc.xref.status.400.1">4</a>, <a class="iref" href="#rfc.iref.40"><b>8.4.1</b></a></li> 1773 <li class="indline1">401 Unauthorized (status code) <a class="iref" href="#rfc.xref.status.401.1">4</a>, <a class="iref" href="#rfc.iref.41"><b>8.4.2</b></a></li> 1774 <li class="indline1">402 Payment Required (status code) <a class="iref" href="#rfc.xref.status.402.1">4</a>, <a class="iref" href="#rfc.iref.42"><b>8.4.3</b></a></li> 1775 <li class="indline1">403 Forbidden (status code) <a class="iref" href="#rfc.xref.status.403.1">4</a>, <a class="iref" href="#rfc.iref.43"><b>8.4.4</b></a>, <a class="iref" href="#rfc.xref.status.403.2">A.1</a></li> 1776 <li class="indline1">404 Not Found (status code) <a class="iref" href="#rfc.xref.status.404.1">4</a>, <a class="iref" href="#rfc.iref.44"><b>8.4.5</b></a>, <a class="iref" href="#rfc.xref.status.404.2">A.1</a></li> 1777 <li class="indline1">405 Method Not Allowed (status code) <a class="iref" href="#rfc.xref.status.405.1">4</a>, <a class="iref" href="#rfc.iref.45"><b>8.4.6</b></a></li> 1778 <li class="indline1">406 Not Acceptable (status code) <a class="iref" href="#rfc.xref.status.406.1">4</a>, <a class="iref" href="#rfc.iref.46"><b>8.4.7</b></a></li> 1779 <li class="indline1">407 Proxy Authentication Required (status code) <a class="iref" href="#rfc.xref.status.407.1">4</a>, <a class="iref" href="#rfc.iref.47"><b>8.4.8</b></a></li> 1780 <li class="indline1">408 Request Timeout (status code) <a class="iref" href="#rfc.xref.status.408.1">4</a>, <a class="iref" href="#rfc.iref.48"><b>8.4.9</b></a></li> 1781 <li class="indline1">409 Conflict (status code) <a class="iref" href="#rfc.xref.status.409.1">4</a>, <a class="iref" href="#rfc.iref.49"><b>8.4.10</b></a></li> 1782 <li class="indline1">410 Gone (status code) <a class="iref" href="#rfc.xref.status.410.1">4</a>, <a class="iref" href="#rfc.iref.50"><b>8.4.11</b></a>, <a class="iref" href="#rfc.xref.status.410.2">A.1</a></li> 1783 <li class="indline1">411 Length Required (status code) <a class="iref" href="#rfc.xref.status.411.1">4</a>, <a class="iref" href="#rfc.iref.51"><b>8.4.12</b></a></li> 1784 <li class="indline1">412 Precondition Failed (status code) <a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.52"><b>8.4.13</b></a></li> 1785 <li class="indline1">413 Request Entity Too Large (status code) <a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.53"><b>8.4.14</b></a></li> 1786 <li class="indline1">414 Request-URI Too Long (status code) <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.54"><b>8.4.15</b></a></li> 1787 <li class="indline1">415 Unsupported Media Type (status code) <a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.55"><b>8.4.16</b></a></li> 1788 <li class="indline1">416 Requested Range Not Satisfiable (status code) <a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.17</b></a></li> 1789 <li class="indline1">417 Expectation Failed (status code) <a class="iref" href="#rfc.xref.status.417.1">4</a>, <a class="iref" href="#rfc.iref.57"><b>8.4.18</b></a></li> 1799 1790 </ul> 1800 1791 </li> 1801 1792 <li class="indline0"><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul class="ind"> 1802 <li class="indline1">500 Internal Server Error (status code) <a class="iref" href="#rfc.xref.status.500.1"> 5</a>, <a class="iref" href="#rfc.iref.60"><b>9.5.1</b></a></li>1803 <li class="indline1">501 Not Implemented (status code) <a class="iref" href="#rfc.xref.status.501.1"> 5</a>, <a class="iref" href="#rfc.iref.61"><b>9.5.2</b></a></li>1804 <li class="indline1">502 Bad Gateway (status code) <a class="iref" href="#rfc.xref.status.502.1"> 5</a>, <a class="iref" href="#rfc.iref.62"><b>9.5.3</b></a></li>1805 <li class="indline1">503 Service Unavailable (status code) <a class="iref" href="#rfc.xref.status.503.1"> 5</a>, <a class="iref" href="#rfc.iref.63"><b>9.5.4</b></a></li>1806 <li class="indline1">504 Gateway Timeout (status code) <a class="iref" href="#rfc.xref.status.504.1"> 5</a>, <a class="iref" href="#rfc.iref.64"><b>9.5.5</b></a>, <a class="iref" href="#rfc.xref.status.504.2">A.1</a></li>1807 <li class="indline1">505 HTTP Version Not Supported (status code) <a class="iref" href="#rfc.xref.status.505.1"> 5</a>, <a class="iref" href="#rfc.iref.65"><b>9.5.6</b></a></li>1793 <li class="indline1">500 Internal Server Error (status code) <a class="iref" href="#rfc.xref.status.500.1">4</a>, <a class="iref" href="#rfc.iref.58"><b>8.5.1</b></a></li> 1794 <li class="indline1">501 Not Implemented (status code) <a class="iref" href="#rfc.xref.status.501.1">4</a>, <a class="iref" href="#rfc.iref.59"><b>8.5.2</b></a></li> 1795 <li class="indline1">502 Bad Gateway (status code) <a class="iref" href="#rfc.xref.status.502.1">4</a>, <a class="iref" href="#rfc.iref.60"><b>8.5.3</b></a></li> 1796 <li class="indline1">503 Service Unavailable (status code) <a class="iref" href="#rfc.xref.status.503.1">4</a>, <a class="iref" href="#rfc.iref.61"><b>8.5.4</b></a></li> 1797 <li class="indline1">504 Gateway Timeout (status code) <a class="iref" href="#rfc.xref.status.504.1">4</a>, <a class="iref" href="#rfc.iref.62"><b>8.5.5</b></a>, <a class="iref" href="#rfc.xref.status.504.2">A.1</a></li> 1798 <li class="indline1">505 HTTP Version Not Supported (status code) <a class="iref" href="#rfc.xref.status.505.1">4</a>, <a class="iref" href="#rfc.iref.63"><b>8.5.6</b></a></li> 1808 1799 </ul> 1809 1800 </li> 1810 1801 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 1811 <li class="indline1">Allow header <a class="iref" href="#rfc.xref.header.allow.1"> 3</a>, <a class="iref" href="#rfc.iref.a.1"><b>10.1</b></a></li>1802 <li class="indline1">Allow header <a class="iref" href="#rfc.xref.header.allow.1">2</a>, <a class="iref" href="#rfc.iref.a.1"><b>9.1</b></a></li> 1812 1803 </ul> 1813 1804 </li> 1814 1805 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 1815 <li class="indline1">CONNECT method <a class="iref" href="#rfc.xref.CONNECT.1"> 3</a>, <a class="iref" href="#rfc.iref.c.1"><b>8.9</b></a></li>1806 <li class="indline1">CONNECT method <a class="iref" href="#rfc.xref.CONNECT.1">2</a>, <a class="iref" href="#rfc.iref.c.1"><b>7.9</b></a></li> 1816 1807 </ul> 1817 1808 </li> 1818 1809 <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"> 1819 <li class="indline1">DELETE method <a class="iref" href="#rfc.xref.DELETE.1"> 3</a>, <a class="iref" href="#rfc.iref.d.1"><b>8.7</b></a></li>1810 <li class="indline1">DELETE method <a class="iref" href="#rfc.xref.DELETE.1">2</a>, <a class="iref" href="#rfc.iref.d.1"><b>7.7</b></a></li> 1820 1811 </ul> 1821 1812 </li> 1822 1813 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 1823 <li class="indline1">Expect header <a class="iref" href="#rfc.xref.header.expect.1"> 4</a>, <a class="iref" href="#rfc.xref.header.expect.2">9.4.18</a>, <a class="iref" href="#rfc.iref.e.1"><b>10.2</b></a></li>1814 <li class="indline1">Expect header <a class="iref" href="#rfc.xref.header.expect.1">3</a>, <a class="iref" href="#rfc.xref.header.expect.2">8.4.18</a>, <a class="iref" href="#rfc.iref.e.1"><b>9.2</b></a></li> 1824 1815 </ul> 1825 1816 </li> 1826 1817 <li class="indline0"><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul class="ind"> 1827 <li class="indline1">From header <a class="iref" href="#rfc.xref.header.from.1"> 4</a>, <a class="iref" href="#rfc.iref.f.1"><b>10.3</b></a></li>1818 <li class="indline1">From header <a class="iref" href="#rfc.xref.header.from.1">3</a>, <a class="iref" href="#rfc.iref.f.1"><b>9.3</b></a></li> 1828 1819 </ul> 1829 1820 </li> 1830 1821 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 1831 <li class="indline1">GET method <a class="iref" href="#rfc.xref.GET.1"> 3</a>, <a class="iref" href="#rfc.iref.g.10"><b>8.3</b></a></li>1822 <li class="indline1">GET method <a class="iref" href="#rfc.xref.GET.1">2</a>, <a class="iref" href="#rfc.iref.g.8"><b>7.3</b></a></li> 1832 1823 <li class="indline1"><tt>Grammar</tt> 1833 1824 <ul class="ind"> 1834 <li class="indline1"><tt>Allow</tt> <a class="iref" href="#rfc.iref.g.11"><b>10.1</b></a></li> 1835 <li class="indline1"><tt>Expect</tt> <a class="iref" href="#rfc.iref.g.12"><b>10.2</b></a></li> 1836 <li class="indline1"><tt>expect-params</tt> <a class="iref" href="#rfc.iref.g.15"><b>10.2</b></a></li> 1837 <li class="indline1"><tt>expectation</tt> <a class="iref" href="#rfc.iref.g.13"><b>10.2</b></a></li> 1838 <li class="indline1"><tt>expectation-extension</tt> <a class="iref" href="#rfc.iref.g.14"><b>10.2</b></a></li> 1839 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.7"><b>5</b></a></li> 1840 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.4"><b>3</b></a></li> 1841 <li class="indline1"><tt>From</tt> <a class="iref" href="#rfc.iref.g.16"><b>10.3</b></a></li> 1842 <li class="indline1"><tt>Location</tt> <a class="iref" href="#rfc.iref.g.17"><b>10.4</b></a></li> 1843 <li class="indline1"><tt>Max-Forwards</tt> <a class="iref" href="#rfc.iref.g.18"><b>10.5</b></a></li> 1844 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.3"><b>3</b></a></li> 1845 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.1"><b>2</b></a></li> 1846 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.2"><b>2</b></a></li> 1847 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.8"><b>5</b></a></li> 1848 <li class="indline1"><tt>Referer</tt> <a class="iref" href="#rfc.iref.g.19"><b>10.6</b></a></li> 1849 <li class="indline1"><tt>request-header</tt> <a class="iref" href="#rfc.iref.g.5"><b>4</b></a></li> 1850 <li class="indline1"><tt>response-header</tt> <a class="iref" href="#rfc.iref.g.9"><b>6</b></a></li> 1851 <li class="indline1"><tt>Retry-After</tt> <a class="iref" href="#rfc.iref.g.20"><b>10.7</b></a></li> 1852 <li class="indline1"><tt>Server</tt> <a class="iref" href="#rfc.iref.g.21"><b>10.8</b></a></li> 1853 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.6"><b>5</b></a></li> 1854 <li class="indline1"><tt>User-Agent</tt> <a class="iref" href="#rfc.iref.g.22"><b>10.9</b></a></li> 1825 <li class="indline1"><tt>Allow</tt> <a class="iref" href="#rfc.iref.g.9"><b>9.1</b></a></li> 1826 <li class="indline1"><tt>Expect</tt> <a class="iref" href="#rfc.iref.g.10"><b>9.2</b></a></li> 1827 <li class="indline1"><tt>expect-params</tt> <a class="iref" href="#rfc.iref.g.13"><b>9.2</b></a></li> 1828 <li class="indline1"><tt>expectation</tt> <a class="iref" href="#rfc.iref.g.11"><b>9.2</b></a></li> 1829 <li class="indline1"><tt>expectation-extension</tt> <a class="iref" href="#rfc.iref.g.12"><b>9.2</b></a></li> 1830 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.5"><b>4</b></a></li> 1831 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.2"><b>2</b></a></li> 1832 <li class="indline1"><tt>From</tt> <a class="iref" href="#rfc.iref.g.14"><b>9.3</b></a></li> 1833 <li class="indline1"><tt>Location</tt> <a class="iref" href="#rfc.iref.g.15"><b>9.4</b></a></li> 1834 <li class="indline1"><tt>Max-Forwards</tt> <a class="iref" href="#rfc.iref.g.16"><b>9.5</b></a></li> 1835 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.1"><b>2</b></a></li> 1836 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.6"><b>4</b></a></li> 1837 <li class="indline1"><tt>Referer</tt> <a class="iref" href="#rfc.iref.g.17"><b>9.6</b></a></li> 1838 <li class="indline1"><tt>request-header</tt> <a class="iref" href="#rfc.iref.g.3"><b>3</b></a></li> 1839 <li class="indline1"><tt>response-header</tt> <a class="iref" href="#rfc.iref.g.7"><b>5</b></a></li> 1840 <li class="indline1"><tt>Retry-After</tt> <a class="iref" href="#rfc.iref.g.18"><b>9.7</b></a></li> 1841 <li class="indline1"><tt>Server</tt> <a class="iref" href="#rfc.iref.g.19"><b>9.8</b></a></li> 1842 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.4"><b>4</b></a></li> 1843 <li class="indline1"><tt>User-Agent</tt> <a class="iref" href="#rfc.iref.g.20"><b>9.9</b></a></li> 1855 1844 </ul> 1856 1845 </li> … … 1858 1847 </li> 1859 1848 <li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind"> 1860 <li class="indline1">HEAD method <a class="iref" href="#rfc.xref.HEAD.1"> 3</a>, <a class="iref" href="#rfc.iref.h.1"><b>8.4</b></a></li>1849 <li class="indline1">HEAD method <a class="iref" href="#rfc.xref.HEAD.1">2</a>, <a class="iref" href="#rfc.iref.h.1"><b>7.4</b></a></li> 1861 1850 <li class="indline1">Headers 1862 1851 <ul class="ind"> 1863 <li class="indline1">Allow <a class="iref" href="#rfc.xref.header.allow.1"> 3</a>, <a class="iref" href="#rfc.iref.h.2"><b>10.1</b></a></li>1864 <li class="indline1">Expect <a class="iref" href="#rfc.xref.header.expect.1"> 4</a>, <a class="iref" href="#rfc.xref.header.expect.2">9.4.18</a>, <a class="iref" href="#rfc.iref.h.3"><b>10.2</b></a></li>1865 <li class="indline1">From <a class="iref" href="#rfc.xref.header.from.1"> 4</a>, <a class="iref" href="#rfc.iref.h.4"><b>10.3</b></a></li>1866 <li class="indline1">Location <a class="iref" href="#rfc.xref.header.location.1"> 6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>10.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li>1867 <li class="indline1">Max-Forwards <a class="iref" href="#rfc.xref.header.max-forwards.1"> 4</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">8.8</a>, <a class="iref" href="#rfc.iref.h.6"><b>10.5</b></a></li>1868 <li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1"> 4</a>, <a class="iref" href="#rfc.iref.h.7"><b>10.6</b></a></li>1869 <li class="indline1">Retry-After <a class="iref" href="#rfc.xref.header.retry-after.1"> 6</a>, <a class="iref" href="#rfc.iref.h.8"><b>10.7</b></a></li>1870 <li class="indline1">Server <a class="iref" href="#rfc.xref.header.server.1"> 6</a>, <a class="iref" href="#rfc.iref.h.9"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">12.1</a>, <a class="iref" href="#rfc.xref.header.server.3">A.2</a></li>1871 <li class="indline1">User-Agent <a class="iref" href="#rfc.xref.header.user-agent.1"> 4</a>, <a class="iref" href="#rfc.iref.h.10"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">12.1</a></li>1852 <li class="indline1">Allow <a class="iref" href="#rfc.xref.header.allow.1">2</a>, <a class="iref" href="#rfc.iref.h.2"><b>9.1</b></a></li> 1853 <li class="indline1">Expect <a class="iref" href="#rfc.xref.header.expect.1">3</a>, <a class="iref" href="#rfc.xref.header.expect.2">8.4.18</a>, <a class="iref" href="#rfc.iref.h.3"><b>9.2</b></a></li> 1854 <li class="indline1">From <a class="iref" href="#rfc.xref.header.from.1">3</a>, <a class="iref" href="#rfc.iref.h.4"><b>9.3</b></a></li> 1855 <li class="indline1">Location <a class="iref" href="#rfc.xref.header.location.1">5</a>, <a class="iref" href="#rfc.xref.header.location.2">7.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li> 1856 <li class="indline1">Max-Forwards <a class="iref" href="#rfc.xref.header.max-forwards.1">3</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">7.8</a>, <a class="iref" href="#rfc.iref.h.6"><b>9.5</b></a></li> 1857 <li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.6</b></a></li> 1858 <li class="indline1">Retry-After <a class="iref" href="#rfc.xref.header.retry-after.1">5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.7</b></a></li> 1859 <li class="indline1">Server <a class="iref" href="#rfc.xref.header.server.1">5</a>, <a class="iref" href="#rfc.iref.h.9"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">11.1</a>, <a class="iref" href="#rfc.xref.header.server.3">A.2</a></li> 1860 <li class="indline1">User-Agent <a class="iref" href="#rfc.xref.header.user-agent.1">3</a>, <a class="iref" href="#rfc.iref.h.10"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">11.1</a></li> 1872 1861 </ul> 1873 1862 </li> … … 1876 1865 <li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind"> 1877 1866 <li class="indline1">LINK method <a class="iref" href="#rfc.iref.l.2"><b>A.1</b></a></li> 1878 <li class="indline1">Location header <a class="iref" href="#rfc.xref.header.location.1"> 6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.l.1"><b>10.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li>1879 <li class="indline1"><em>Luo1998</em> <a class="iref" href="#rfc.xref.Luo1998.1"> 8.9</a>, <a class="iref" href="#Luo1998"><b>14.2</b></a></li>1867 <li class="indline1">Location header <a class="iref" href="#rfc.xref.header.location.1">5</a>, <a class="iref" href="#rfc.xref.header.location.2">7.5</a>, <a class="iref" href="#rfc.iref.l.1"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li> 1868 <li class="indline1"><em>Luo1998</em> <a class="iref" href="#rfc.xref.Luo1998.1">7.9</a>, <a class="iref" href="#Luo1998"><b>13.2</b></a></li> 1880 1869 </ul> 1881 1870 </li> 1882 1871 <li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind"> 1883 <li class="indline1">Max-Forwards header <a class="iref" href="#rfc.xref.header.max-forwards.1"> 4</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">8.8</a>, <a class="iref" href="#rfc.iref.m.9"><b>10.5</b></a></li>1872 <li class="indline1">Max-Forwards header <a class="iref" href="#rfc.xref.header.max-forwards.1">3</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">7.8</a>, <a class="iref" href="#rfc.iref.m.9"><b>9.5</b></a></li> 1884 1873 <li class="indline1">Methods 1885 1874 <ul class="ind"> 1886 <li class="indline1">CONNECT <a class="iref" href="#rfc.xref.CONNECT.1"> 3</a>, <a class="iref" href="#rfc.iref.m.8"><b>8.9</b></a></li>1887 <li class="indline1">DELETE <a class="iref" href="#rfc.xref.DELETE.1"> 3</a>, <a class="iref" href="#rfc.iref.m.6"><b>8.7</b></a></li>1888 <li class="indline1">GET <a class="iref" href="#rfc.xref.GET.1"> 3</a>, <a class="iref" href="#rfc.iref.m.2"><b>8.3</b></a></li>1889 <li class="indline1">HEAD <a class="iref" href="#rfc.xref.HEAD.1"> 3</a>, <a class="iref" href="#rfc.iref.m.3"><b>8.4</b></a></li>1875 <li class="indline1">CONNECT <a class="iref" href="#rfc.xref.CONNECT.1">2</a>, <a class="iref" href="#rfc.iref.m.8"><b>7.9</b></a></li> 1876 <li class="indline1">DELETE <a class="iref" href="#rfc.xref.DELETE.1">2</a>, <a class="iref" href="#rfc.iref.m.6"><b>7.7</b></a></li> 1877 <li class="indline1">GET <a class="iref" href="#rfc.xref.GET.1">2</a>, <a class="iref" href="#rfc.iref.m.2"><b>7.3</b></a></li> 1878 <li class="indline1">HEAD <a class="iref" href="#rfc.xref.HEAD.1">2</a>, <a class="iref" href="#rfc.iref.m.3"><b>7.4</b></a></li> 1890 1879 <li class="indline1">LINK <a class="iref" href="#rfc.iref.m.11"><b>A.1</b></a></li> 1891 <li class="indline1">OPTIONS <a class="iref" href="#rfc.xref.OPTIONS.1"> 3</a>, <a class="iref" href="#rfc.iref.m.1"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.OPTIONS.2">10.5</a></li>1880 <li class="indline1">OPTIONS <a class="iref" href="#rfc.xref.OPTIONS.1">2</a>, <a class="iref" href="#rfc.iref.m.1"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.OPTIONS.2">9.5</a></li> 1892 1881 <li class="indline1">PATCH <a class="iref" href="#rfc.iref.m.10"><b>A.1</b></a></li> 1893 <li class="indline1">POST <a class="iref" href="#rfc.xref.POST.1"> 3</a>, <a class="iref" href="#rfc.iref.m.4"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.POST.2">A.2</a></li>1894 <li class="indline1">PUT <a class="iref" href="#rfc.xref.PUT.1"> 3</a>, <a class="iref" href="#rfc.iref.m.5"><b>8.6</b></a></li>1895 <li class="indline1">TRACE <a class="iref" href="#rfc.xref.TRACE.1"> 3</a>, <a class="iref" href="#rfc.iref.m.7"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.TRACE.2">10.5</a></li>1882 <li class="indline1">POST <a class="iref" href="#rfc.xref.POST.1">2</a>, <a class="iref" href="#rfc.iref.m.4"><b>7.5</b></a>, <a class="iref" href="#rfc.xref.POST.2">A.2</a></li> 1883 <li class="indline1">PUT <a class="iref" href="#rfc.xref.PUT.1">2</a>, <a class="iref" href="#rfc.iref.m.5"><b>7.6</b></a></li> 1884 <li class="indline1">TRACE <a class="iref" href="#rfc.xref.TRACE.1">2</a>, <a class="iref" href="#rfc.iref.m.7"><b>7.8</b></a>, <a class="iref" href="#rfc.xref.TRACE.2">9.5</a></li> 1896 1885 <li class="indline1">UNLINK <a class="iref" href="#rfc.iref.m.12"><b>A.1</b></a></li> 1897 1886 </ul> … … 1900 1889 </li> 1901 1890 <li class="indline0"><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul class="ind"> 1902 <li class="indline1">OPTIONS method <a class="iref" href="#rfc.xref.OPTIONS.1"> 3</a>, <a class="iref" href="#rfc.iref.o.1"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.OPTIONS.2">10.5</a></li>1891 <li class="indline1">OPTIONS method <a class="iref" href="#rfc.xref.OPTIONS.1">2</a>, <a class="iref" href="#rfc.iref.o.1"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.OPTIONS.2">9.5</a></li> 1903 1892 </ul> 1904 1893 </li> 1905 1894 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1906 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">4</a>, <a class="iref" href="#rfc.xref.Part1.4">7</a>, <a class="iref" href="#rfc.xref.Part1.5">8</a>, <a class="iref" href="#rfc.xref.Part1.6">8.8</a>, <a class="iref" href="#rfc.xref.Part1.7">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.9">10.2</a>, <a class="iref" href="#rfc.xref.Part1.10">10.8</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.11">A.2</a><ul class="ind"> 1907 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.8">9.5.6</a></li> 1908 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.4">7</a></li> 1909 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.7">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.9">10.2</a></li> 1910 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.5">8</a></li> 1911 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.3">4</a></li> 1912 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.6">8.8</a>, <a class="iref" href="#rfc.xref.Part1.10">10.8</a>, <a class="iref" href="#rfc.xref.Part1.11">A.2</a></li> 1895 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">3</a>, <a class="iref" href="#rfc.xref.Part1.3">3</a>, <a class="iref" href="#rfc.xref.Part1.4">6</a>, <a class="iref" href="#rfc.xref.Part1.5">7</a>, <a class="iref" href="#rfc.xref.Part1.6">7.8</a>, <a class="iref" href="#rfc.xref.Part1.7">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.9">9.2</a>, <a class="iref" href="#rfc.xref.Part1.10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.8</a>, <a class="iref" href="#rfc.xref.Part1.12">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.13">A.2</a><ul class="ind"> 1896 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.8">8.5.6</a></li> 1897 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1.10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.12">9.9</a></li> 1898 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.4">6</a></li> 1899 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.7">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.9">9.2</a></li> 1900 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.2">3</a>, <a class="iref" href="#rfc.xref.Part1.5">7</a></li> 1901 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.3">3</a></li> 1902 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.6">7.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.8</a>, <a class="iref" href="#rfc.xref.Part1.13">A.2</a></li> 1913 1903 </ul> 1914 1904 </li> 1915 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1"> 4</a>, <a class="iref" href="#rfc.xref.Part3.2">4</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">4</a>, <a class="iref" href="#rfc.xref.Part3.5">7</a>, <a class="iref" href="#rfc.xref.Part3.6">9.3.1</a>, <a class="iref" href="#rfc.xref.Part3.7">10.4</a>, <a class="iref" href="#Part3"><b>14.1</b></a><ul class="ind">1916 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.6"> 9.3.1</a></li>1917 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.1"> 4</a></li>1918 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part3.2"> 4</a></li>1919 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.3"> 4</a></li>1920 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part3.4"> 4</a></li>1921 <li class="indline1"><em>Section 5.7</em> <a class="iref" href="#rfc.xref.Part3.7"> 10.4</a></li>1905 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">3</a>, <a class="iref" href="#rfc.xref.Part3.2">3</a>, <a class="iref" href="#rfc.xref.Part3.3">3</a>, <a class="iref" href="#rfc.xref.Part3.4">3</a>, <a class="iref" href="#rfc.xref.Part3.5">6</a>, <a class="iref" href="#rfc.xref.Part3.6">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.7">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind"> 1906 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.6">8.3.1</a></li> 1907 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part3.1">3</a></li> 1908 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part3.2">3</a></li> 1909 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part3.3">3</a></li> 1910 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part3.4">3</a></li> 1911 <li class="indline1"><em>Section 5.7</em> <a class="iref" href="#rfc.xref.Part3.7">9.4</a></li> 1922 1912 </ul> 1923 1913 </li> 1924 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1"> 4</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a>, <a class="iref" href="#rfc.xref.Part4.3">4</a>, <a class="iref" href="#rfc.xref.Part4.4">4</a>, <a class="iref" href="#rfc.xref.Part4.5">6</a>, <a class="iref" href="#rfc.xref.Part4.6">9.2.2</a>, <a class="iref" href="#rfc.xref.Part4.7">9.3.5</a>, <a class="iref" href="#rfc.xref.Part4.8">9.4.13</a>, <a class="iref" href="#Part4"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part4.9">B.2</a><ul class="ind">1925 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part4.5"> 6</a>, <a class="iref" href="#rfc.xref.Part4.6">9.2.2</a></li>1926 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part4.1"> 4</a></li>1927 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part4.2"> 4</a></li>1928 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part4.3"> 4</a></li>1929 <li class="indline1"><em>Section 6.5</em> <a class="iref" href="#rfc.xref.Part4.4"> 4</a></li>1914 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">3</a>, <a class="iref" href="#rfc.xref.Part4.2">3</a>, <a class="iref" href="#rfc.xref.Part4.3">3</a>, <a class="iref" href="#rfc.xref.Part4.4">3</a>, <a class="iref" href="#rfc.xref.Part4.5">5</a>, <a class="iref" href="#rfc.xref.Part4.6">8.2.2</a>, <a class="iref" href="#rfc.xref.Part4.7">8.3.5</a>, <a class="iref" href="#rfc.xref.Part4.8">8.4.13</a>, <a class="iref" href="#Part4"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part4.9">B.2</a><ul class="ind"> 1915 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part4.5">5</a>, <a class="iref" href="#rfc.xref.Part4.6">8.2.2</a></li> 1916 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part4.1">3</a></li> 1917 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part4.2">3</a></li> 1918 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part4.3">3</a></li> 1919 <li class="indline1"><em>Section 6.5</em> <a class="iref" href="#rfc.xref.Part4.4">3</a></li> 1930 1920 </ul> 1931 1921 </li> 1932 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1"> 4</a>, <a class="iref" href="#rfc.xref.Part5.2">4</a>, <a class="iref" href="#rfc.xref.Part5.3">6</a>, <a class="iref" href="#rfc.xref.Part5.4">8.3</a>, <a class="iref" href="#rfc.xref.Part5.5">9.1.2</a>, <a class="iref" href="#rfc.xref.Part5.6">9.2.7</a>, <a class="iref" href="#rfc.xref.Part5.7">9.4.17</a>, <a class="iref" href="#Part5"><b>14.1</b></a><ul class="ind">1933 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part5.3"> 6</a></li>1934 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part5.1"> 4</a></li>1935 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part5.2"> 4</a>, <a class="iref" href="#rfc.xref.Part5.4">8.3</a>, <a class="iref" href="#rfc.xref.Part5.5">9.1.2</a>, <a class="iref" href="#rfc.xref.Part5.7">9.4.17</a></li>1922 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">3</a>, <a class="iref" href="#rfc.xref.Part5.2">3</a>, <a class="iref" href="#rfc.xref.Part5.3">5</a>, <a class="iref" href="#rfc.xref.Part5.4">7.3</a>, <a class="iref" href="#rfc.xref.Part5.5">8.1.2</a>, <a class="iref" href="#rfc.xref.Part5.6">8.2.7</a>, <a class="iref" href="#rfc.xref.Part5.7">8.4.17</a>, <a class="iref" href="#Part5"><b>13.1</b></a><ul class="ind"> 1923 <li class="indline1"><em>Section 5.1</em> <a class="iref" href="#rfc.xref.Part5.3">5</a></li> 1924 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part5.1">3</a></li> 1925 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part5.2">3</a>, <a class="iref" href="#rfc.xref.Part5.4">7.3</a>, <a class="iref" href="#rfc.xref.Part5.5">8.1.2</a>, <a class="iref" href="#rfc.xref.Part5.7">8.4.17</a></li> 1936 1926 </ul> 1937 1927 </li> 1938 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 6</a>, <a class="iref" href="#rfc.xref.Part6.2">6</a>, <a class="iref" href="#rfc.xref.Part6.3">8.3</a>, <a class="iref" href="#Part6"><b>14.1</b></a><ul class="ind">1939 <li class="indline1"><em>Section 15.1</em> <a class="iref" href="#rfc.xref.Part6.1"> 6</a></li>1940 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.2"> 6</a></li>1928 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">5</a>, <a class="iref" href="#rfc.xref.Part6.2">5</a>, <a class="iref" href="#rfc.xref.Part6.3">7.3</a>, <a class="iref" href="#Part6"><b>13.1</b></a><ul class="ind"> 1929 <li class="indline1"><em>Section 15.1</em> <a class="iref" href="#rfc.xref.Part6.1">5</a></li> 1930 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.2">5</a></li> 1941 1931 </ul> 1942 1932 </li> 1943 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1"> 4</a>, <a class="iref" href="#rfc.xref.Part7.2">4</a>, <a class="iref" href="#rfc.xref.Part7.3">6</a>, <a class="iref" href="#rfc.xref.Part7.4">6</a>, <a class="iref" href="#rfc.xref.Part7.5">9.4.2</a>, <a class="iref" href="#rfc.xref.Part7.6">9.4.8</a>, <a class="iref" href="#Part7"><b>14.1</b></a><ul class="ind">1944 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.1"> 4</a></li>1945 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part7.3"> 6</a></li>1946 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part7.2"> 4</a></li>1947 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part7.4"> 6</a></li>1933 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1">3</a>, <a class="iref" href="#rfc.xref.Part7.2">3</a>, <a class="iref" href="#rfc.xref.Part7.3">5</a>, <a class="iref" href="#rfc.xref.Part7.4">5</a>, <a class="iref" href="#rfc.xref.Part7.5">8.4.2</a>, <a class="iref" href="#rfc.xref.Part7.6">8.4.8</a>, <a class="iref" href="#Part7"><b>13.1</b></a><ul class="ind"> 1934 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.1">3</a></li> 1935 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part7.3">5</a></li> 1936 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part7.2">3</a></li> 1937 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part7.4">5</a></li> 1948 1938 </ul> 1949 1939 </li> 1950 1940 <li class="indline1">PATCH method <a class="iref" href="#rfc.iref.p.3"><b>A.1</b></a></li> 1951 <li class="indline1">POST method <a class="iref" href="#rfc.xref.POST.1"> 3</a>, <a class="iref" href="#rfc.iref.p.1"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.POST.2">A.2</a></li>1952 <li class="indline1">PUT method <a class="iref" href="#rfc.xref.PUT.1"> 3</a>, <a class="iref" href="#rfc.iref.p.2"><b>8.6</b></a></li>1941 <li class="indline1">POST method <a class="iref" href="#rfc.xref.POST.1">2</a>, <a class="iref" href="#rfc.iref.p.1"><b>7.5</b></a>, <a class="iref" href="#rfc.xref.POST.2">A.2</a></li> 1942 <li class="indline1">PUT method <a class="iref" href="#rfc.xref.PUT.1">2</a>, <a class="iref" href="#rfc.iref.p.2"><b>7.6</b></a></li> 1953 1943 </ul> 1954 1944 </li> 1955 1945 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1956 <li class="indline1">Referer header <a class="iref" href="#rfc.xref.header.referer.1"> 4</a>, <a class="iref" href="#rfc.iref.r.1"><b>10.6</b></a></li>1957 <li class="indline1">Retry-After header <a class="iref" href="#rfc.xref.header.retry-after.1"> 6</a>, <a class="iref" href="#rfc.iref.r.2"><b>10.7</b></a></li>1958 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1"> 9.3.3</a>, <a class="iref" href="#RFC1945"><b>14.2</b></a></li>1959 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1"> 9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A.1</a></li>1960 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>1 4.1</b></a></li>1961 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>1 4.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li>1962 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#rfc.xref.RFC2822.1"> 10.3</a>, <a class="iref" href="#RFC2822"><b>14.2</b></a><ul class="ind">1963 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC2822.1"> 10.3</a></li>1946 <li class="indline1">Referer header <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.r.1"><b>9.6</b></a></li> 1947 <li class="indline1">Retry-After header <a class="iref" href="#rfc.xref.header.retry-after.1">5</a>, <a class="iref" href="#rfc.iref.r.2"><b>9.7</b></a></li> 1948 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">8.3.3</a>, <a class="iref" href="#RFC1945"><b>13.2</b></a></li> 1949 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">8.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">8.3.6</a>, <a class="iref" href="#RFC2068"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A.1</a></li> 1950 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>13.1</b></a></li> 1951 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 1952 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#rfc.xref.RFC2822.1">9.3</a>, <a class="iref" href="#RFC2822"><b>13.2</b></a><ul class="ind"> 1953 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC2822.1">9.3</a></li> 1964 1954 </ul> 1965 1955 </li> … … 1967 1957 </li> 1968 1958 <li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind"> 1969 <li class="indline1">Server header <a class="iref" href="#rfc.xref.header.server.1"> 6</a>, <a class="iref" href="#rfc.iref.s.42"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">12.1</a>, <a class="iref" href="#rfc.xref.header.server.3">A.2</a></li>1959 <li class="indline1">Server header <a class="iref" href="#rfc.xref.header.server.1">5</a>, <a class="iref" href="#rfc.iref.s.42"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">11.1</a>, <a class="iref" href="#rfc.xref.header.server.3">A.2</a></li> 1970 1960 <li class="indline1">Status Codes 1971 1961 <ul class="ind"> 1972 <li class="indline1">100 Continue <a class="iref" href="#rfc.xref.status.100.1"> 5</a>, <a class="iref" href="#rfc.iref.s.1"><b>9.1.1</b></a></li>1973 <li class="indline1">101 Switching Protocols <a class="iref" href="#rfc.xref.status.101.1"> 5</a>, <a class="iref" href="#rfc.iref.s.2"><b>9.1.2</b></a></li>1974 <li class="indline1">200 OK <a class="iref" href="#rfc.xref.status.200.1"> 5</a>, <a class="iref" href="#rfc.iref.s.3"><b>9.2.1</b></a></li>1975 <li class="indline1">201 Created <a class="iref" href="#rfc.xref.status.201.1"> 5</a>, <a class="iref" href="#rfc.iref.s.4"><b>9.2.2</b></a>, <a class="iref" href="#rfc.xref.status.201.2">A.1</a></li>1976 <li class="indline1">202 Accepted <a class="iref" href="#rfc.xref.status.202.1"> 5</a>, <a class="iref" href="#rfc.iref.s.5"><b>9.2.3</b></a></li>1977 <li class="indline1">203 Non-Authoritative Information <a class="iref" href="#rfc.xref.status.203.1"> 5</a>, <a class="iref" href="#rfc.iref.s.6"><b>9.2.4</b></a></li>1978 <li class="indline1">204 No Content <a class="iref" href="#rfc.xref.status.204.1"> 5</a>, <a class="iref" href="#rfc.iref.s.7"><b>9.2.5</b></a></li>1979 <li class="indline1">205 Reset Content <a class="iref" href="#rfc.xref.status.205.1"> 5</a>, <a class="iref" href="#rfc.iref.s.8"><b>9.2.6</b></a></li>1980 <li class="indline1">206 Partial Content <a class="iref" href="#rfc.xref.status.206.1"> 5</a>, <a class="iref" href="#rfc.iref.s.9"><b>9.2.7</b></a></li>1981 <li class="indline1">300 Multiple Choices <a class="iref" href="#rfc.xref.status.300.1"> 5</a>, <a class="iref" href="#rfc.iref.s.10"><b>9.3.1</b></a></li>1982 <li class="indline1">301 Moved Permanently <a class="iref" href="#rfc.xref.status.301.1"> 5</a>, <a class="iref" href="#rfc.iref.s.11"><b>9.3.2</b></a>, <a class="iref" href="#rfc.xref.status.301.2">A.2</a></li>1983 <li class="indline1">302 Found <a class="iref" href="#rfc.xref.status.302.1"> 5</a>, <a class="iref" href="#rfc.iref.s.12"><b>9.3.3</b></a>, <a class="iref" href="#rfc.xref.status.302.2">A.2</a></li>1984 <li class="indline1">303 See Other <a class="iref" href="#rfc.xref.status.303.1"> 5</a>, <a class="iref" href="#rfc.iref.s.13"><b>9.3.4</b></a></li>1985 <li class="indline1">304 Not Modified <a class="iref" href="#rfc.xref.status.304.1"> 5</a>, <a class="iref" href="#rfc.iref.s.14"><b>9.3.5</b></a></li>1986 <li class="indline1">305 Use Proxy <a class="iref" href="#rfc.xref.status.305.1"> 5</a>, <a class="iref" href="#rfc.iref.s.15"><b>9.3.6</b></a></li>1987 <li class="indline1">306 (Unused) <a class="iref" href="#rfc.iref.s.16"><b> 9.3.7</b></a></li>1988 <li class="indline1">307 Temporary Redirect <a class="iref" href="#rfc.xref.status.307.1"> 5</a>, <a class="iref" href="#rfc.iref.s.17"><b>9.3.8</b></a>, <a class="iref" href="#rfc.xref.status.307.2">A.2</a></li>1989 <li class="indline1">400 Bad Request <a class="iref" href="#rfc.xref.status.400.1"> 5</a>, <a class="iref" href="#rfc.iref.s.18"><b>9.4.1</b></a></li>1990 <li class="indline1">401 Unauthorized <a class="iref" href="#rfc.xref.status.401.1"> 5</a>, <a class="iref" href="#rfc.iref.s.19"><b>9.4.2</b></a></li>1991 <li class="indline1">402 Payment Required <a class="iref" href="#rfc.xref.status.402.1"> 5</a>, <a class="iref" href="#rfc.iref.s.20"><b>9.4.3</b></a></li>1992 <li class="indline1">403 Forbidden <a class="iref" href="#rfc.xref.status.403.1"> 5</a>, <a class="iref" href="#rfc.iref.s.21"><b>9.4.4</b></a>, <a class="iref" href="#rfc.xref.status.403.2">A.1</a></li>1993 <li class="indline1">404 Not Found <a class="iref" href="#rfc.xref.status.404.1"> 5</a>, <a class="iref" href="#rfc.iref.s.22"><b>9.4.5</b></a>, <a class="iref" href="#rfc.xref.status.404.2">A.1</a></li>1994 <li class="indline1">405 Method Not Allowed <a class="iref" href="#rfc.xref.status.405.1"> 5</a>, <a class="iref" href="#rfc.iref.s.23"><b>9.4.6</b></a></li>1995 <li class="indline1">406 Not Acceptable <a class="iref" href="#rfc.xref.status.406.1"> 5</a>, <a class="iref" href="#rfc.iref.s.24"><b>9.4.7</b></a></li>1996 <li class="indline1">407 Proxy Authentication Required <a class="iref" href="#rfc.xref.status.407.1"> 5</a>, <a class="iref" href="#rfc.iref.s.25"><b>9.4.8</b></a></li>1997 <li class="indline1">408 Request Timeout <a class="iref" href="#rfc.xref.status.408.1"> 5</a>, <a class="iref" href="#rfc.iref.s.26"><b>9.4.9</b></a></li>1998 <li class="indline1">409 Conflict <a class="iref" href="#rfc.xref.status.409.1"> 5</a>, <a class="iref" href="#rfc.iref.s.27"><b>9.4.10</b></a></li>1999 <li class="indline1">410 Gone <a class="iref" href="#rfc.xref.status.410.1"> 5</a>, <a class="iref" href="#rfc.iref.s.28"><b>9.4.11</b></a>, <a class="iref" href="#rfc.xref.status.410.2">A.1</a></li>2000 <li class="indline1">411 Length Required <a class="iref" href="#rfc.xref.status.411.1"> 5</a>, <a class="iref" href="#rfc.iref.s.29"><b>9.4.12</b></a></li>2001 <li class="indline1">412 Precondition Failed <a class="iref" href="#rfc.xref.status.412.1"> 5</a>, <a class="iref" href="#rfc.iref.s.30"><b>9.4.13</b></a></li>2002 <li class="indline1">413 Request Entity Too Large <a class="iref" href="#rfc.xref.status.413.1"> 5</a>, <a class="iref" href="#rfc.iref.s.31"><b>9.4.14</b></a></li>2003 <li class="indline1">414 Request-URI Too Long <a class="iref" href="#rfc.xref.status.414.1"> 5</a>, <a class="iref" href="#rfc.iref.s.32"><b>9.4.15</b></a></li>2004 <li class="indline1">415 Unsupported Media Type <a class="iref" href="#rfc.xref.status.415.1"> 5</a>, <a class="iref" href="#rfc.iref.s.33"><b>9.4.16</b></a></li>2005 <li class="indline1">416 Requested Range Not Satisfiable <a class="iref" href="#rfc.xref.status.416.1"> 5</a>, <a class="iref" href="#rfc.iref.s.34"><b>9.4.17</b></a></li>2006 <li class="indline1">417 Expectation Failed <a class="iref" href="#rfc.xref.status.417.1"> 5</a>, <a class="iref" href="#rfc.iref.s.35"><b>9.4.18</b></a></li>2007 <li class="indline1">500 Internal Server Error <a class="iref" href="#rfc.xref.status.500.1"> 5</a>, <a class="iref" href="#rfc.iref.s.36"><b>9.5.1</b></a></li>2008 <li class="indline1">501 Not Implemented <a class="iref" href="#rfc.xref.status.501.1"> 5</a>, <a class="iref" href="#rfc.iref.s.37"><b>9.5.2</b></a></li>2009 <li class="indline1">502 Bad Gateway <a class="iref" href="#rfc.xref.status.502.1"> 5</a>, <a class="iref" href="#rfc.iref.s.38"><b>9.5.3</b></a></li>2010 <li class="indline1">503 Service Unavailable <a class="iref" href="#rfc.xref.status.503.1"> 5</a>, <a class="iref" href="#rfc.iref.s.39"><b>9.5.4</b></a></li>2011 <li class="indline1">504 Gateway Timeout <a class="iref" href="#rfc.xref.status.504.1"> 5</a>, <a class="iref" href="#rfc.iref.s.40"><b>9.5.5</b></a>, <a class="iref" href="#rfc.xref.status.504.2">A.1</a></li>2012 <li class="indline1">505 HTTP Version Not Supported <a class="iref" href="#rfc.xref.status.505.1"> 5</a>, <a class="iref" href="#rfc.iref.s.41"><b>9.5.6</b></a></li>1962 <li class="indline1">100 Continue <a class="iref" href="#rfc.xref.status.100.1">4</a>, <a class="iref" href="#rfc.iref.s.1"><b>8.1.1</b></a></li> 1963 <li class="indline1">101 Switching Protocols <a class="iref" href="#rfc.xref.status.101.1">4</a>, <a class="iref" href="#rfc.iref.s.2"><b>8.1.2</b></a></li> 1964 <li class="indline1">200 OK <a class="iref" href="#rfc.xref.status.200.1">4</a>, <a class="iref" href="#rfc.iref.s.3"><b>8.2.1</b></a></li> 1965 <li class="indline1">201 Created <a class="iref" href="#rfc.xref.status.201.1">4</a>, <a class="iref" href="#rfc.iref.s.4"><b>8.2.2</b></a>, <a class="iref" href="#rfc.xref.status.201.2">A.1</a></li> 1966 <li class="indline1">202 Accepted <a class="iref" href="#rfc.xref.status.202.1">4</a>, <a class="iref" href="#rfc.iref.s.5"><b>8.2.3</b></a></li> 1967 <li class="indline1">203 Non-Authoritative Information <a class="iref" href="#rfc.xref.status.203.1">4</a>, <a class="iref" href="#rfc.iref.s.6"><b>8.2.4</b></a></li> 1968 <li class="indline1">204 No Content <a class="iref" href="#rfc.xref.status.204.1">4</a>, <a class="iref" href="#rfc.iref.s.7"><b>8.2.5</b></a></li> 1969 <li class="indline1">205 Reset Content <a class="iref" href="#rfc.xref.status.205.1">4</a>, <a class="iref" href="#rfc.iref.s.8"><b>8.2.6</b></a></li> 1970 <li class="indline1">206 Partial Content <a class="iref" href="#rfc.xref.status.206.1">4</a>, <a class="iref" href="#rfc.iref.s.9"><b>8.2.7</b></a></li> 1971 <li class="indline1">300 Multiple Choices <a class="iref" href="#rfc.xref.status.300.1">4</a>, <a class="iref" href="#rfc.iref.s.10"><b>8.3.1</b></a></li> 1972 <li class="indline1">301 Moved Permanently <a class="iref" href="#rfc.xref.status.301.1">4</a>, <a class="iref" href="#rfc.iref.s.11"><b>8.3.2</b></a>, <a class="iref" href="#rfc.xref.status.301.2">A.2</a></li> 1973 <li class="indline1">302 Found <a class="iref" href="#rfc.xref.status.302.1">4</a>, <a class="iref" href="#rfc.iref.s.12"><b>8.3.3</b></a>, <a class="iref" href="#rfc.xref.status.302.2">A.2</a></li> 1974 <li class="indline1">303 See Other <a class="iref" href="#rfc.xref.status.303.1">4</a>, <a class="iref" href="#rfc.iref.s.13"><b>8.3.4</b></a></li> 1975 <li class="indline1">304 Not Modified <a class="iref" href="#rfc.xref.status.304.1">4</a>, <a class="iref" href="#rfc.iref.s.14"><b>8.3.5</b></a></li> 1976 <li class="indline1">305 Use Proxy <a class="iref" href="#rfc.xref.status.305.1">4</a>, <a class="iref" href="#rfc.iref.s.15"><b>8.3.6</b></a></li> 1977 <li class="indline1">306 (Unused) <a class="iref" href="#rfc.iref.s.16"><b>8.3.7</b></a></li> 1978 <li class="indline1">307 Temporary Redirect <a class="iref" href="#rfc.xref.status.307.1">4</a>, <a class="iref" href="#rfc.iref.s.17"><b>8.3.8</b></a>, <a class="iref" href="#rfc.xref.status.307.2">A.2</a></li> 1979 <li class="indline1">400 Bad Request <a class="iref" href="#rfc.xref.status.400.1">4</a>, <a class="iref" href="#rfc.iref.s.18"><b>8.4.1</b></a></li> 1980 <li class="indline1">401 Unauthorized <a class="iref" href="#rfc.xref.status.401.1">4</a>, <a class="iref" href="#rfc.iref.s.19"><b>8.4.2</b></a></li> 1981 <li class="indline1">402 Payment Required <a class="iref" href="#rfc.xref.status.402.1">4</a>, <a class="iref" href="#rfc.iref.s.20"><b>8.4.3</b></a></li> 1982 <li class="indline1">403 Forbidden <a class="iref" href="#rfc.xref.status.403.1">4</a>, <a class="iref" href="#rfc.iref.s.21"><b>8.4.4</b></a>, <a class="iref" href="#rfc.xref.status.403.2">A.1</a></li> 1983 <li class="indline1">404 Not Found <a class="iref" href="#rfc.xref.status.404.1">4</a>, <a class="iref" href="#rfc.iref.s.22"><b>8.4.5</b></a>, <a class="iref" href="#rfc.xref.status.404.2">A.1</a></li> 1984 <li class="indline1">405 Method Not Allowed <a class="iref" href="#rfc.xref.status.405.1">4</a>, <a class="iref" href="#rfc.iref.s.23"><b>8.4.6</b></a></li> 1985 <li class="indline1">406 Not Acceptable <a class="iref" href="#rfc.xref.status.406.1">4</a>, <a class="iref" href="#rfc.iref.s.24"><b>8.4.7</b></a></li> 1986 <li class="indline1">407 Proxy Authentication Required <a class="iref" href="#rfc.xref.status.407.1">4</a>, <a class="iref" href="#rfc.iref.s.25"><b>8.4.8</b></a></li> 1987 <li class="indline1">408 Request Timeout <a class="iref" href="#rfc.xref.status.408.1">4</a>, <a class="iref" href="#rfc.iref.s.26"><b>8.4.9</b></a></li> 1988 <li class="indline1">409 Conflict <a class="iref" href="#rfc.xref.status.409.1">4</a>, <a class="iref" href="#rfc.iref.s.27"><b>8.4.10</b></a></li> 1989 <li class="indline1">410 Gone <a class="iref" href="#rfc.xref.status.410.1">4</a>, <a class="iref" href="#rfc.iref.s.28"><b>8.4.11</b></a>, <a class="iref" href="#rfc.xref.status.410.2">A.1</a></li> 1990 <li class="indline1">411 Length Required <a class="iref" href="#rfc.xref.status.411.1">4</a>, <a class="iref" href="#rfc.iref.s.29"><b>8.4.12</b></a></li> 1991 <li class="indline1">412 Precondition Failed <a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.s.30"><b>8.4.13</b></a></li> 1992 <li class="indline1">413 Request Entity Too Large <a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.s.31"><b>8.4.14</b></a></li> 1993 <li class="indline1">414 Request-URI Too Long <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.32"><b>8.4.15</b></a></li> 1994 <li class="indline1">415 Unsupported Media Type <a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.16</b></a></li> 1995 <li class="indline1">416 Requested Range Not Satisfiable <a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.s.34"><b>8.4.17</b></a></li> 1996 <li class="indline1">417 Expectation Failed <a class="iref" href="#rfc.xref.status.417.1">4</a>, <a class="iref" href="#rfc.iref.s.35"><b>8.4.18</b></a></li> 1997 <li class="indline1">500 Internal Server Error <a class="iref" href="#rfc.xref.status.500.1">4</a>, <a class="iref" href="#rfc.iref.s.36"><b>8.5.1</b></a></li> 1998 <li class="indline1">501 Not Implemented <a class="iref" href="#rfc.xref.status.501.1">4</a>, <a class="iref" href="#rfc.iref.s.37"><b>8.5.2</b></a></li> 1999 <li class="indline1">502 Bad Gateway <a class="iref" href="#rfc.xref.status.502.1">4</a>, <a class="iref" href="#rfc.iref.s.38"><b>8.5.3</b></a></li> 2000 <li class="indline1">503 Service Unavailable <a class="iref" href="#rfc.xref.status.503.1">4</a>, <a class="iref" href="#rfc.iref.s.39"><b>8.5.4</b></a></li> 2001 <li class="indline1">504 Gateway Timeout <a class="iref" href="#rfc.xref.status.504.1">4</a>, <a class="iref" href="#rfc.iref.s.40"><b>8.5.5</b></a>, <a class="iref" href="#rfc.xref.status.504.2">A.1</a></li> 2002 <li class="indline1">505 HTTP Version Not Supported <a class="iref" href="#rfc.xref.status.505.1">4</a>, <a class="iref" href="#rfc.iref.s.41"><b>8.5.6</b></a></li> 2013 2003 </ul> 2014 2004 </li> … … 2016 2006 </li> 2017 2007 <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind"> 2018 <li class="indline1">TRACE method <a class="iref" href="#rfc.xref.TRACE.1"> 3</a>, <a class="iref" href="#rfc.iref.t.1"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.TRACE.2">10.5</a></li>2008 <li class="indline1">TRACE method <a class="iref" href="#rfc.xref.TRACE.1">2</a>, <a class="iref" href="#rfc.iref.t.1"><b>7.8</b></a>, <a class="iref" href="#rfc.xref.TRACE.2">9.5</a></li> 2019 2009 </ul> 2020 2010 </li> 2021 2011 <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind"> 2022 2012 <li class="indline1">UNLINK method <a class="iref" href="#rfc.iref.u.2"><b>A.1</b></a></li> 2023 <li class="indline1">User-Agent header <a class="iref" href="#rfc.xref.header.user-agent.1"> 4</a>, <a class="iref" href="#rfc.iref.u.1"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">12.1</a></li>2013 <li class="indline1">User-Agent header <a class="iref" href="#rfc.xref.header.user-agent.1">3</a>, <a class="iref" href="#rfc.iref.u.1"><b>9.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">11.1</a></li> 2024 2014 </ul> 2025 2015 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r184 r190 56 56 <!ENTITY header-www-authenticate "<xref target='Part7' x:rel='#header.www-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 57 57 <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 58 <!ENTITY product-tokens "<xref target='Part1' x:rel='#product.tokens' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 58 59 ]> 59 60 <?rfc toc="yes" ?> … … 283 284 </section> 284 285 285 <section title="Product Tokens" anchor="product.tokens">286 <t>287 Product tokens are used to allow communicating applications to288 identify themselves by software name and version. Most fields using289 product tokens also allow sub-products which form a significant part290 of the application to be listed, separated by white space. By291 convention, the products are listed in order of their significance292 for identifying the application.293 </t>294 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>295 product = token ["/" product-version]296 product-version = token297 </artwork></figure>298 <t>299 Examples:300 </t>301 <figure><artwork type="example">302 User-Agent: CERN-LineMode/2.15 libwww/2.17b3303 Server: Apache/0.8.4304 </artwork></figure>305 <t>306 Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be307 used for advertising or other non-essential information. Although any308 token character &MAY; appear in a product-version, this token &SHOULD;309 only be used for a version identifier (i.e., successive versions of310 the same product &SHOULD; only differ in the product-version portion of311 the product value).312 </t>313 </section>314 315 286 <section title="Method" anchor="method"> 316 287 <t> … … 1921 1892 The Server response-header field contains information about the 1922 1893 software used by the origin server to handle the request. The field 1923 can contain multiple product tokens ( <xref target="product.tokens"/>) and comments1894 can contain multiple product tokens (&product-tokens;) and comments 1924 1895 identifying the server and any significant subproducts. The product 1925 1896 tokens are listed in order of their significance for identifying the … … 1958 1929 agents for the sake of tailoring responses to avoid particular user 1959 1930 agent limitations. User agents &SHOULD; include this field with 1960 requests. The field can contain multiple product tokens ( <xref target="product.tokens"/>)1931 requests. The field can contain multiple product tokens (&product-tokens;) 1961 1932 and comments identifying the agent and any subproducts which form a 1962 1933 significant part of the user agent. By convention, the product tokens … … 2637 2608 </list> 2638 2609 </t> 2610 <t> 2611 Ongoing work on ABNF conversion (<eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36"/>): 2612 <list style="symbols"> 2613 <t> 2614 Move "Product Tokens" section (back) into Part 1, as "token" is used 2615 in the definition of the Upgrade header. 2616 </t> 2617 </list> 2618 </t> 2639 2619 </section> 2640 2620 -
draft-ietf-httpbis/latest/p3-payload.html
r189 r190 758 758 by the request. 759 759 </p> 760 <div id="rfc.figure.u.8"></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.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>760 <div id="rfc.figure.u.8"></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.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 9.1</a> 761 761 | Content-Encoding ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 5.5</a> 762 762 | Content-Language ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 5.6</a> … … 839 839 </ol> 840 840 <p id="rfc.section.4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent 841 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension841 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including information outside the request-header fields or within extension 842 842 header fields not defined by this specification. 843 843 </p> … … 1657 1657 </li> 1658 1658 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind"> 1659 <li class="indline1"><em>Section 10.1</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a></li>1660 <li class="indline1"><em>Section 10.9</em> <a class="iref" href="#rfc.xref.Part2.2">4.1</a></li>1659 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a></li> 1660 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part2.2">4.1</a></li> 1661 1661 </ul> 1662 1662 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r189 r190 1109 1109 <p id="rfc.section.10.p.2">We note one exception to this rule: since some applications have traditionally used GET and HEAD requests with URLs containing 1110 1110 a query part to perform operations with significant side effects, caches <em class="bcp14">MUST NOT</em> treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that 1111 responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em> be taken from a cache. See <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related information.1111 responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em> be taken from a cache. See <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related information. 1112 1112 </p> 1113 1113 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></h1> … … 2009 2009 </li> 2010 2010 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">10</a>, <a class="iref" href="#Part2"><b>19.1</b></a><ul class="ind"> 2011 <li class="indline1"><em>Section 8.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">10</a></li>2011 <li class="indline1"><em>Section 7.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">10</a></li> 2012 2012 </ul> 2013 2013 </li>
Note: See TracChangeset
for help on using the changeset viewer.
