Changeset 823
- Timestamp:
- 26/05/10 17:25:13 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r822 r823 573 573 </li> 574 574 <li class="tocline1">4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 575 <li class="tocline1">4.3 <a href="#effective.request.uri">Effective Request URI</a></li> 575 576 </ul> 576 577 </li> … … 1384 1385 what exact resource is being requested. 1385 1386 </p> 1387 <div id="rfc.iref.e.1"></div> 1388 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 1389 <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the resource they are intended for; instead, the value needs to be inferred from the request-target, Host header and 1390 other context. The result of this process is the "Effective Request URI". 1391 </p> 1392 <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the Effective Request URI is the request-target.</p> 1393 <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective 1394 Request URI is constructed by concatenating 1395 </p> 1396 <p id="rfc.section.4.3.p.4"> </p> 1397 <ul> 1398 <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over SSL/TLS-secured 1399 TCP connection, 1400 </li> 1401 <li>the character sequence "://",</li> 1402 <li>the authority component, as specified in the Host header (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 9.4</a>) and determined by the rules in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section 4.2</a>, <span class="comment" id="effrequri-nohost">[<a href="#effrequri-nohost" class="smpl">effrequri-nohost</a>: Do we need to include the handling of missing hosts in HTTP/1.0 messages, as described in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section 4.2</a>? --jre]</span> and 1403 </li> 1404 <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> 1405 </ul> 1406 <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p> 1407 <div id="rfc.figure.u.40"></div> 1408 <p>Example 1: the Effective Request URI for the message</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1409 Host: www.example.org:8080 1410 </pre> <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus 1411 the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 1412 </p> 1413 <div id="rfc.figure.u.41"></div> 1414 <p>Example 2: the Effective Request URI for the message</p> <pre class="text">GET * HTTP/1.1 1415 Host: www.example.org 1416 </pre> <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", 1417 thus "https://www.example.org". 1418 </p> 1419 <p id="rfc.section.4.3.p.8">Effective Request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1420 </p> 1386 1421 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1> 1387 1422 <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1388 <div id="rfc.figure.u.4 0"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a>1423 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a> 1389 1424 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.5</a> 1390 1425 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.6"><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> … … 1397 1432 CRLF sequence. 1398 1433 </p> 1399 <div id="rfc.figure.u.4 1"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1434 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1400 1435 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1401 1436 <p id="rfc.section.5.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 … … 1414 1449 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1415 1450 </ul> 1416 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1451 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1417 1452 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1418 1453 </pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> … … 1421 1456 <p id="rfc.section.6.1.p.2">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 1422 1457 </p> 1423 <div id="rfc.figure.u.4 3"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 11231458 <div id="rfc.figure.u.45"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1424 1459 </pre><p id="rfc.section.6.1.p.4">The other formats are described here only for compatibility with obsolete implementations.</p> 1425 <div id="rfc.figure.u.4 4"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format1460 <div id="rfc.figure.u.46"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1426 1461 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1427 1462 </pre><p id="rfc.section.6.1.p.6">HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. … … 1431 1466 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 1432 1467 </p> 1433 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>1468 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 1434 1469 </pre><div id="preferred.date.format"> 1435 1470 <p id="rfc.section.6.1.p.9"> Preferred format:</p> 1436 1471 </div> 1437 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><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><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1472 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><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><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span> <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1438 1473 1439 1474 <a href="#preferred.date.format" class="smpl">day-name</a> = %x4D.6F.6E ; "Mon", case-sensitive … … 1476 1511 <p id="rfc.section.6.1.p.12"> Obsolete formats:</p> 1477 1512 </div> 1478 <div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>1479 </pre><div id="rfc.figure.u. 48"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>1513 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.69"></span> <a href="#obsolete.date.formats" class="smpl">obs-date</a> = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 1514 </pre><div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.70"></span> <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 1480 1515 <a href="#obsolete.date.formats" class="smpl">date2</a> = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 1481 1516 ; day-month-year (e.g., 02-Jun-82) … … 1488 1523 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1489 1524 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1490 </pre><div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>1525 </pre><div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 1491 1526 <a href="#obsolete.date.formats" class="smpl">date3</a> = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 1492 1527 ; month day (e.g., Jun 2) … … 1506 1541 is a property of the message, not of the original entity. 1507 1542 </p> 1508 <div id="rfc.figure.u.5 0"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>1543 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a> 1509 1544 / "compress" ; <a href="#compress.coding" title="Compress Coding">Section 6.2.2.1</a> 1510 1545 / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> … … 1515 1550 <p id="rfc.section.6.2.p.3"> Parameters are in the form of attribute/value pairs.</p> 1516 1551 </div> 1517 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1552 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#rule.parameter" class="smpl">transfer-parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1518 1553 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1519 1554 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> … … 1537 1572 necessary for the recipient to verify that it has received the full message. 1538 1573 </p> 1539 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><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> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1574 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><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> <a href="#chunked.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1540 1575 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1541 1576 <a href="#chunked.encoding" class="smpl">trailer-part</a> … … 1580 1615 </p> 1581 1616 <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1582 <div id="rfc.figure.u.5 3"></div><pre class="text"> length := 01617 <div id="rfc.figure.u.55"></div><pre class="text"> length := 0 1583 1618 read chunk-size, chunk-ext (if any) and CRLF 1584 1619 while (chunk-size > 0) { … … 1649 1684 By convention, the products are listed in order of their significance for identifying the application. 1650 1685 </p> 1651 <div id="rfc.figure.u.5 4"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1686 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1652 1687 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1653 1688 </pre><p id="rfc.section.6.3.p.3">Examples:</p> 1654 <div id="rfc.figure.u.5 5"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b31689 <div id="rfc.figure.u.57"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1655 1690 Server: Apache/0.8.4 1656 1691 </pre><p id="rfc.section.6.3.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). … … 1661 1696 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1662 1697 </p> 1663 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )1698 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1664 1699 / ( "1" [ "." 0*3("0") ] ) 1665 1700 </pre><div class="note" id="rfc.section.6.4.p.3"> … … 1945 1980 </p> 1946 1981 <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p> 1947 <div id="rfc.figure.u.5 7"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1982 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1948 1983 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1949 1984 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1958 1993 of the response. For example, 1959 1994 </p> 1960 <div id="rfc.figure.u. 58"></div><pre class="text"> Connection: close1995 <div id="rfc.figure.u.60"></div><pre class="text"> Connection: close 1961 1996 </pre><p id="rfc.section.9.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. 1962 1997 </p> … … 1974 2009 to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET. 1975 2010 </p> 1976 <div id="rfc.figure.u. 59"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>2011 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1977 2012 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1978 2013 </pre><p id="rfc.section.9.2.p.3">An example is</p> 1979 <div id="rfc.figure.u.6 0"></div><pre class="text"> Content-Length: 34952014 <div id="rfc.figure.u.62"></div><pre class="text"> Content-Length: 3495 1980 2015 </pre><p id="rfc.section.9.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 3.4</a>. 1981 2016 </p> … … 1992 2027 as the Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1993 2028 </p> 1994 <div id="rfc.figure.u.6 1"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>2029 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1995 2030 <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 1996 2031 </pre><p id="rfc.section.9.3.p.3">An example is</p> 1997 <div id="rfc.figure.u.6 2"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2032 <div id="rfc.figure.u.64"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1998 2033 </pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1999 2034 </p> … … 2033 2068 resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). 2034 2069 </p> 2035 <div id="rfc.figure.u.6 3"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>2070 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 2036 2071 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 2037 2072 </pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 2038 2073 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 2039 2074 </p> 2040 <div id="rfc.figure.u.6 4"></div><pre class="text2">GET /pub/WWW/ HTTP/1.12075 <div id="rfc.figure.u.66"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2041 2076 Host: www.example.org 2042 2077 </pre><p id="rfc.section.9.4.p.6">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 … … 2055 2090 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 2056 2091 </p> 2057 <div id="rfc.figure.u.6 5"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>2092 <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 2058 2093 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 2059 2094 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) … … 2064 2099 </p> 2065 2100 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 2066 <div id="rfc.figure.u.6 6"></div><pre class="text"> TE: deflate2101 <div id="rfc.figure.u.68"></div><pre class="text"> TE: deflate 2067 2102 TE: 2068 2103 TE: trailers, deflate;q=0.5 … … 2101 2136 with chunked transfer-coding. 2102 2137 </p> 2103 <div id="rfc.figure.u.6 7"></div><pre class="inline"><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>2138 <div id="rfc.figure.u.69"></div><pre class="inline"><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 2104 2139 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 2105 2140 </pre><p id="rfc.section.9.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 … … 2122 2157 are not. 2123 2158 </p> 2124 <div id="rfc.figure.u. 68"></div><pre class="inline"><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>2159 <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 2125 2160 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 2126 2161 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 2127 2162 </pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>. An example is: 2128 2163 </p> 2129 <div id="rfc.figure.u. 69"></div><pre class="text"> Transfer-Encoding: chunked2164 <div id="rfc.figure.u.71"></div><pre class="text"> Transfer-Encoding: chunked 2130 2165 </pre><p id="rfc.section.9.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. 2131 2166 </p> … … 2138 2173 to. 2139 2174 </p> 2140 <div id="rfc.figure.u.7 0"></div><pre class="inline"><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>2175 <div id="rfc.figure.u.72"></div><pre class="inline"><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 2141 2176 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 2142 2177 </pre><p id="rfc.section.9.8.p.3">For example,</p> 2143 <div id="rfc.figure.u.7 1"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112178 <div id="rfc.figure.u.73"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2144 2179 </pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 2145 2180 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2194 2229 of all senders along the request/response chain. 2195 2230 </p> 2196 <div id="rfc.figure.u.7 2"></div><pre class="inline"><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span><span id="rfc.iref.g.120"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>2231 <div id="rfc.figure.u.74"></div><pre class="inline"><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span><span id="rfc.iref.g.120"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 2197 2232 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 2198 2233 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 2219 2254 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2220 2255 </p> 2221 <div id="rfc.figure.u.7 3"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2256 <div id="rfc.figure.u.75"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2222 2257 </pre><p id="rfc.section.9.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. 2223 2258 </p> … … 2225 2260 For example, 2226 2261 </p> 2227 <div id="rfc.figure.u.7 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2262 <div id="rfc.figure.u.76"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2228 2263 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 2229 <div id="rfc.figure.u.7 5"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2264 <div id="rfc.figure.u.77"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2230 2265 </pre><p id="rfc.section.9.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 2231 2266 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2272 2307 <td class="left">http</td> 2273 2308 <td class="left">standard</td> 2274 <td class="left"> <a href="#header.host" id="rfc.xref.header.host. 1" title="Host">Section 9.4</a>2309 <td class="left"> <a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 9.4</a> 2275 2310 </td> 2276 2311 </tr> … … 2865 2900 <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 2866 2901 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3> 2867 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host. 2" title="Host">Section 9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by this specification.2902 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 4.1.2</a>) are among the most important changes defined by this specification. 2868 2903 </p> 2869 2904 <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 2947 2982 </p> 2948 2983 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 2949 <div id="rfc.figure.u.7 6"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS2984 <div id="rfc.figure.u.78"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 2950 2985 2951 2986 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 3.4> … … 3138 3173 3139 3174 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3140 </pre> <div id="rfc.figure.u.7 7"></div>3175 </pre> <div id="rfc.figure.u.79"></div> 3141 3176 <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 3142 3177 ; Content-Length defined but not used … … 3396 3431 </li> 3397 3432 </ul> 3433 <p id="rfc.section.D.11.p.2">Partly resolved issues: </p> 3434 <ul> 3435 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 3436 </li> 3437 </ul> 3398 3438 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 3399 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index. G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>3439 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> 3400 3440 </p> 3401 3441 <div class="print2col"> … … 3432 3472 <li class="indline1">deflate (Coding Format) <a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li> 3433 3473 <li class="indline1">downstream <a class="iref" href="#rfc.iref.d.1">2.2</a></li> 3474 </ul> 3475 </li> 3476 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 3477 <li class="indline1">Effective Request URI <a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li> 3434 3478 </ul> 3435 3479 </li> … … 3570 3614 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 3571 3615 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li> 3572 <li class="indline1">Host <a class="iref" href="#rfc. iref.h.10"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">10.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>3616 <li class="indline1">Host <a class="iref" href="#rfc.xref.header.host.1">4.3</a>, <a class="iref" href="#rfc.iref.h.10"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.2">10.1</a>, <a class="iref" href="#rfc.xref.header.host.3">B.1.1</a></li> 3573 3617 <li class="indline1">TE <a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.11"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li> 3574 3618 <li class="indline1">Trailer <a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li> … … 3578 3622 </ul> 3579 3623 </li> 3580 <li class="indline1">Host header <a class="iref" href="#rfc. iref.h.9"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">10.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>3624 <li class="indline1">Host header <a class="iref" href="#rfc.xref.header.host.1">4.3</a>, <a class="iref" href="#rfc.iref.h.9"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.2">10.1</a>, <a class="iref" href="#rfc.xref.header.host.3">B.1.1</a></li> 3581 3625 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>2.6.1</b></a></li> 3582 3626 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">2.6.2</a></li> … … 3679 3723 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">3.2</a>, <a class="iref" href="#RFC2965"><b>13.2</b></a></li> 3680 3724 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">10.1</a>, <a class="iref" href="#RFC3864"><b>13.2</b></a></li> 3681 <li class="indline1"><em>RFC3986</em> <a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.6.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.18">4.1.2</a>, <a class="iref" href="# RFC3986"><b>13.1</b></a><ul class="ind">3725 <li class="indline1"><em>RFC3986</em> <a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.6.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.18">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.19">4.3</a>, <a class="iref" href="#RFC3986"><b>13.1</b></a><ul class="ind"> 3682 3726 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a></li> 3683 3727 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.RFC3986.8">2.6</a></li> … … 3689 3733 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC3986.5">2.6</a></li> 3690 3734 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.RFC3986.7">2.6</a></li> 3691 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a> </li>3735 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.19">4.3</a></li> 3692 3736 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a></li> 3693 3737 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r822 r823 1595 1595 exact resource is being requested. 1596 1596 </t> 1597 </section> 1598 1599 <section title="Effective Request URI" anchor="effective.request.uri"> 1600 <iref primary="true" item="Effective Request URI"/> 1601 <t> 1602 HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>) 1603 for the resource they are intended for; instead, the value needs to be inferred from the 1604 request-target, Host header and other context. The result of this process is 1605 the "Effective Request URI". 1606 </t> 1607 <t> 1608 If the request-target is an absolute-URI, then the Effective Request URI is 1609 the request-target. 1610 </t> 1611 <t> 1612 If the request-target uses the path-absolute (plus optional query) syntax 1613 or if it is just the asterisk "*", then the Effective Request URI is 1614 constructed by concatenating 1615 </t> 1616 <t> 1617 <list style="symbols"> 1618 <t> 1619 the scheme name: "http" if the request was received over an insecure 1620 TCP connection, or "https" when received over SSL/TLS-secured TCP 1621 connection, 1622 </t> 1623 <t> 1624 the character sequence "://", 1625 </t> 1626 <t> 1627 the authority component, as specified in the Host header 1628 (<xref target="header.host"/>) and determined by the rules in 1629 <xref target="the.resource.identified.by.a.request"/>, 1630 <cref anchor="effrequri-nohost" source="jre">Do we need to include the handling of missing hosts in HTTP/1.0 messages, as 1631 described in <xref target="the.resource.identified.by.a.request"/>?</cref> 1632 and 1633 </t> 1634 <t> 1635 the request-target obtained from the Request-Line, unless the 1636 request-target is just the asterisk "*". 1637 </t> 1638 </list> 1639 </t> 1640 <t> 1641 Otherwise, when request-target uses the authority form, the Effective 1642 Request URI is undefined. 1643 </t> 1644 <figure> 1645 <preamble> 1646 Example 1: the Effective Request URI for the message 1647 </preamble> 1648 <artwork type="example" x:indent-with=" "> 1649 GET /pub/WWW/TheProject.html HTTP/1.1 1650 Host: www.example.org:8080 1651 </artwork> 1652 <postamble> 1653 (received over an insecure TCP connection) is "http", plus "://", plus the 1654 authority component "www.example.org:8080", plus the request-target 1655 "/pub/WWW/TheProject.html", thus 1656 "http://www.example.org:8080/pub/WWW/TheProject.html". 1657 </postamble> 1658 </figure> 1659 <figure> 1660 <preamble> 1661 Example 2: the Effective Request URI for the message 1662 </preamble> 1663 <artwork type="example" x:indent-with=" "> 1664 GET * HTTP/1.1 1665 Host: www.example.org 1666 </artwork> 1667 <postamble> 1668 (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the 1669 authority component "www.example.org", thus "https://www.example.org". 1670 </postamble> 1671 </figure> 1672 <t> 1673 Effective Request URIs are compared using the rules described in 1674 <xref target="uri.comparison"/>, except that empty path components &MUST-NOT; 1675 be treated as equivalent to an absolute path of "/". 1676 </t> 1597 1677 </section> 1598 1678 … … 5556 5636 </list> 5557 5637 </t> 5638 <t> 5639 Partly resolved issues: 5640 <list style="symbols"> 5641 <t> 5642 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 5643 "Term for the requested resource's URI" 5644 </t> 5645 </list> 5646 </t> 5558 5647 </section> 5559 5648 -
draft-ietf-httpbis/latest/p2-semantics.html
r818 r823 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-05- 07">405 <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: November 8, 2010</td>436 <td class="left">Expires: November 27, 2010</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">May 7, 2010</td>489 <td class="right">May 26, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in November 8, 2010.</p>516 <p>This Internet-Draft will expire in November 27, 2010.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 753 753 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>> 754 754 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 755 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 756 </p> 756 757 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 7.2</a> 757 758 / %x47.45.54 ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 7.3</a> … … 796 797 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 797 798 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> 798 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.1 7"><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 9.4</a>799 / <a href="#abnf.dependencies" class="smpl">Host</a> ; <a href="#Part1" id="rfc.xref.Part1.18"><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 9.4</a> 799 800 / <a href="#abnf.dependencies" class="smpl">If-Match</a> ; <a href="#Part4" id="rfc.xref.Part4.6"><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> 800 801 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> … … 806 807 / <a href="#abnf.dependencies" class="smpl">Range</a> ; <a href="#Part5" id="rfc.xref.Part5.5"><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> 807 808 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 808 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.1 8"><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 9.8</a>809 / <a href="#abnf.dependencies" class="smpl">TE</a> ; <a href="#Part1" id="rfc.xref.Part1.19"><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 9.8</a> 809 810 / <a href="#header.user-agent" class="smpl">User-Agent</a> ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 9.9</a> 810 811 </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 … … 880 881 <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 881 882 Status-Line. These header fields give information about the server and about further access to the resource identified by 882 the request-target.883 the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 883 884 </p> 884 885 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.7"><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> … … 901 902 fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 902 903 </p> 903 <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 3.3</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><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 ensure904 <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 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><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 904 905 safe and proper transfer of the message. 905 906 </p> … … 907 908 <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p> 908 909 <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 909 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the request-URI. However, this is not 910 always the case. To determine the URI of the resource a response is associated with, the following rules are used (with the 911 first applicable one being selected): 910 <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 911 rules are used (with the first applicable one being selected): 912 912 </p> 913 913 <ol> 914 914 <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource 915 at the request-URI.915 at the Effective Request URI. 916 916 </li> 917 917 <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 918 of the resource at the request-URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 919 </li> 920 <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="TODO-missref-requri">[<a href="#TODO-missref-requri" class="smpl">TODO-missref-requri</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI. 921 </li> 922 <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that 923 it is a representation of the resource at the Content-Location URI (but it may not be). 918 of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 919 </li> 920 <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation 921 of the resource at the Effective Request URI. 922 </li> 923 <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts 924 that it is a representation of the resource at the Content-Location URI (but it may not be). 924 925 </li> 925 926 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> 926 927 </ol> 927 <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that "request-URI" is used here; however, we need to come up with a term to denote "the URI that can be inferred from 928 examining the request-target and the Host header." (see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>). Also, the comparison function is going to have to be defined somewhere, because we already need to compare URIs for things 929 like cache invalidation.]</span> 928 <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 929 cache invalidation.]</span> 930 930 </p> 931 931 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> … … 958 958 <div id="rfc.iref.m.1"></div> 959 959 <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 960 chain identified by the request-target. This method allows the client to determine the options and/or requirements associated961 with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.960 chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements 961 associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 962 962 </p> 963 963 <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p> … … 986 986 <div id="rfc.iref.m.2"></div> 987 987 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) currently corresponds to the resource identified 988 by the request-target.989 </p> 990 <p id="rfc.section.7.3.p.2">If the request-target identifies a data-producing process, it is the produced data which shall be returned as the entity in991 the response and not the source text of the process, unless that text happens to be the output of the process.988 by the Effective Request URI. 989 </p> 990 <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the entity 991 in the response and not the source text of the process, unless that text happens to be the output of the process. 992 992 </p> 993 993 <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, … … 1020 1020 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1021 1021 <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 1022 by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover1023 the followingfunctions:1022 by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following 1023 functions: 1024 1024 </p> 1025 1025 <ul> … … 1029 1029 <li>Extending a database through an append operation.</li> 1030 1030 </ul> 1031 <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-target.</p> 1031 <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 Effective Request 1032 URI. 1033 </p> 1032 1034 <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 1033 1035 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity … … 1043 1045 <div id="rfc.iref.m.5"></div> 1044 1046 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 1045 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied request-target. If the request-target refers to 1046 an 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-target does not point to an existing 1047 resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create 1048 the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 1049 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target, 1050 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-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1051 </p> 1052 <p id="rfc.section.7.6.p.2">If the request passes through a cache and the request-target 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. 1053 </p> 1054 <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-target. 1055 The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 1047 <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the Effective Request URI. If the Effective Request URI refers 1048 to an 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. Otherwise, if the Effective Request URI does 1049 not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, 1050 the origin server can create the resource with that URI. 1051 </p> 1052 <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 1053 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1054 </p> 1055 <p id="rfc.section.7.6.p.3">If the resource could not be created or modified with the Effective Request URI, 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-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1056 </p> 1057 <p id="rfc.section.7.6.p.4">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 1058 entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1059 </p> 1060 <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request 1061 URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 1056 1062 process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request 1057 1063 identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, 1058 1064 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. 1059 1065 </p> 1060 <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" which1066 <p id="rfc.section.7.6.p.6">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 1061 1067 is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in 1062 1068 several other URIs being defined by the origin server. 1063 1069 </p> 1064 <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>1065 <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.1070 <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 1071 <p id="rfc.section.7.6.p.8">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. 1066 1072 </p> 1067 1073 <div id="rfc.iref.d.1"></div> 1068 1074 <div id="rfc.iref.m.6"></div> 1069 1075 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1070 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the request-target. 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 operation1076 <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective 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 1071 1077 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1072 1078 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 … … 1076 1082 or 204 (No Content) if the action has been enacted but the response does not include an entity. 1077 1083 </p> 1078 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the request-target 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. 1084 <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 1085 entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1079 1086 </p> 1080 1087 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1086 1093 </p> 1087 1094 <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 1088 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><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 the1095 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1089 1096 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1090 1097 infinite loop. 1091 1098 </p> 1092 <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" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.1099 <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" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached. 1093 1100 </p> 1094 1101 <div id="rfc.iref.c.1"></div> … … 1117 1124 <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 1118 1125 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 1119 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.2 2"><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.1126 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.25"><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. 1120 1127 </p> 1121 1128 <div id="rfc.iref.26"></div> … … 1228 1235 <div id="rfc.iref.s.12"></div> 1229 1236 <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> 1230 <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-target 1231 to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. 1237 <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 Effective 1238 Request URI to one or more of the new references returned by the server, where possible. This response is cacheable unless 1239 indicated otherwise. 1232 1240 </p> 1233 1241 <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). … … 1245 1253 <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> 1246 1254 <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 1247 client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or1248 Expires header field.1255 client <em class="bcp14">SHOULD</em> continue to use the Effectice Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 1256 or Expires header field. 1249 1257 </p> 1250 1258 <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). … … 1298 1306 <div id="rfc.iref.s.18"></div> 1299 1307 <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> 1300 <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-target for future requests. This response is only cacheable if indicated by a Cache-Control or1301 Expires header field.1308 <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 Effective Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 1309 or Expires header field. 1302 1310 </p> 1303 1311 <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 … … 1341 1349 <div id="rfc.iref.s.23"></div> 1342 1350 <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> 1343 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the request-target. No indication is given of whether the condition is temporary1351 <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary 1344 1352 or 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 1345 1353 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request … … 1349 1357 <div id="rfc.iref.s.24"></div> 1350 1358 <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> 1351 <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-target. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1359 <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 Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1352 1360 </p> 1353 1361 <div id="rfc.iref.48"></div> … … 1396 1404 <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> 1397 1405 <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 1398 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the request-targetafter user approval. If the server does not know, or has no facility to determine,1406 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine, 1399 1407 whether 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. 1400 1408 </p> … … 1428 1436 <div id="rfc.iref.s.33"></div> 1429 1437 <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 URI Too Long</a></h3> 1430 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-targetis longer than the server is willing to interpret.1438 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret. 1431 1439 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 1432 1440 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 1433 1441 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 1434 in some servers using fixed-length buffers for reading or manipulating the request-target.1442 in some servers using fixed-length buffers for reading or manipulating the Effective Request URI. 1435 1443 </p> 1436 1444 <div id="rfc.iref.57"></div> … … 1498 1506 <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 1499 1507 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1500 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><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.1508 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><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. 1501 1509 </p> 1502 1510 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1508 1516 <div id="rfc.iref.h.2"></div> 1509 1517 <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> 1510 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target.1511 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.1518 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective 1519 Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. 1512 1520 </p> 1513 1521 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 1543 1551 </p> 1544 1552 <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> 1545 <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.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.1553 <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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status. 1546 1554 </p> 1547 1555 <div id="rfc.iref.f.1"></div> … … 1615 1623 <div id="rfc.iref.h.7"></div> 1616 1624 <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> 1617 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target1618 was obtained (the "referrer", although the header field is misspelled.).1625 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request 1626 URI was obtained (the "referrer", although the header field is misspelled.). 1619 1627 </p> 1620 1628 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. … … 1623 1631 contain a Referer header field. 1624 1632 </p> 1625 <p id="rfc.section.9.6.p.3">If the request-target was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the1626 Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with1633 <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), 1634 the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 1627 1635 non-HTTP URIs (e.g., FTP). 1628 1636 </p> … … 1631 1639 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1632 1640 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1633 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. 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.1641 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective 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. 1634 1642 </p> 1635 1643 <div id="rfc.iref.r.2"></div> … … 1655 1663 <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> 1656 1664 <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.</p> 1657 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for1665 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 1658 1666 identifying the application. 1659 1667 </p> … … 1663 1671 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1664 1672 <div id="rfc.figure.u.27"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1665 </pre><p id="rfc.section.9.8.p.6">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 9.9</a> of <a href="#Part1" id="rfc.xref.Part1. 27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1673 </pre><p id="rfc.section.9.8.p.6">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 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1666 1674 </p> 1667 1675 <div class="note" id="rfc.section.9.8.p.7"> … … 1678 1686 to avoid particular user agent limitations. 1679 1687 </p> 1680 <p id="rfc.section.9.9.p.2">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 6.3</a> of <a href="#Part1" id="rfc.xref.Part1. 28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens1688 <p id="rfc.section.9.9.p.2">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 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens 1681 1689 are listed in order of their significance for identifying the application. 1682 1690 </p> … … 2114 2122 </p> 2115 2123 <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 2116 in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it2124 in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it 2117 2125 might be visible to third parties. Such services can use POST-based form submission instead. 2118 2126 </p> … … 2282 2290 </p> 2283 2291 <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2284 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2292 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>) 2285 2293 </p> 2286 2294 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2565 2573 <ul> 2566 2574 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header payload handling" 2575 </li> 2576 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 2567 2577 </li> 2568 2578 </ul> … … 2735 2745 </li> 2736 2746 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2737 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17"> 3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind">2747 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.21">6</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a>, <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a><ul class="ind"> 2738 2748 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 2739 2749 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 2740 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.2 3">8.5.6</a></li>2750 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a></li> 2741 2751 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 2742 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li> 2743 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.19">6</a></li> 2752 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a></li> 2753 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.21">6</a></li> 2754 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a></li> 2744 2755 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 2745 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 5">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li>2746 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.2 2">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li>2747 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.1 7">3</a></li>2748 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.1 8">3</a></li>2749 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.2 0">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li>2750 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.2 1">7.8</a></li>2756 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a></li> 2757 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a></li> 2758 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.18">3</a></li> 2759 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a></li> 2760 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a></li> 2761 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.24">7.8</a></li> 2751 2762 </ul> 2752 2763 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r818 r823 27 27 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 30 <!ENTITY full-date "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 31 <!ENTITY http-url "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 423 424 <x:anchor-alias value="extension-method"/> 424 425 <t> 425 The Method token indicates the method to be performed on the 426 resource identified by the request-target. The method is case-sensitive. 426 The Method token indicates the method to be performed on the resource 427 identified by the Effective Request URI (&effective-request-uri;). The 428 method is case-sensitive. 427 429 </t> 428 430 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> … … 621 623 information about the response which cannot be placed in the Status-Line. 622 624 These header fields give information about the server and about 623 further access to the resource identified by the request-target. 625 further access to the resource identified by the Effective Request URI 626 (&effective-request-uri;). 624 627 </t> 625 628 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> … … 671 674 <t> 672 675 In the common case, an HTTP response is a representation of the resource 673 located at the request-URI. However, this is not always the case. To 674 determine the URI of the resource a response is associated with, the 675 following rules are used (with the first applicable one being selected): 676 located at the Effective Request URI (see &effective-request-uri;). However, 677 this is not always the case. To determine the URI of the resource a 678 response is associated with, the following rules are used (with the first 679 applicable one being selected): 676 680 </t> 677 681 <t><list style="numbers"> 678 682 <t>If the response status code is 200 or 203 and the request method was GET, 679 the response is a representation of the resource at the request-URI.</t>683 the response is a representation of the resource at the Effective Request URI.</t> 680 684 <t>If the response status is 204, 206, or 304 and the request method was GET 681 685 or HEAD, the response is a partial representation of the resource at the 682 request-URI (see &caching-combining-headers;).</t>686 Effective Request URI (see &caching-combining-headers;).</t> 683 687 <t>If the response has a Content-Location header, and that URI is the same 684 as the request-URI <cref anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the685 resource at the request-URI.</t>688 as the Effective Request URI, the response is a representation of the 689 resource at the Effective Request URI.</t> 686 690 <t>If the response has a Content-Location header, and that URI is not the 687 same as the request-URI, the response asserts that it is a representation of 688 the resource at the Content-Location URI (but it may not be).</t> 691 same as the Effective Request URI, the response asserts that it is a 692 representation of the resource at the Content-Location URI (but it may not 693 be).</t> 689 694 <t>Otherwise, the response is a representation of an anonymous (i.e., 690 695 unidentified) resource.</t> … … 692 697 <t> 693 698 <cref anchor="TODO-req-uri"> 694 Note that "request-URI" is used here; however, we need to come up with a 695 term to denote "the URI that can be inferred from examining the 696 request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />). 697 Also, the comparison function is going to have to be defined somewhere, 699 The comparison function is going to have to be defined somewhere, 698 700 because we already need to compare URIs for things like cache invalidation.</cref> 699 701 </t> … … 761 763 The OPTIONS method represents a request for information about the 762 764 communication options available on the request/response chain 763 identified by the request-target. This method allows the client to765 identified by the Effective Request URI. This method allows the client to 764 766 determine the options and/or requirements associated with a resource, 765 767 or the capabilities of a server, without implying a resource action … … 826 828 The GET method means retrieve whatever information (in the form of an 827 829 entity) currently corresponds to the resource identified by the 828 request-target.830 Effective Request URI. 829 831 </t> 830 832 <t> 831 If the request-targetidentifies a data-producing process, it is the833 If the Effective Request URI identifies a data-producing process, it is the 832 834 produced data which shall be returned as the entity in the response and not 833 835 the source text of the process, unless that text happens to be the output of … … 894 896 The POST method is used to request that the origin server accept the 895 897 entity enclosed in the request as data to be processed by the resource 896 identified by the request-target in the Request-Line. POST is designed898 identified by the Effective Request URI. POST is designed 897 899 to allow a uniform method to cover the following functions: 898 900 <list style="symbols"> … … 915 917 <t> 916 918 The actual function performed by the POST method is determined by the 917 server and is usually dependent on the request-target.919 server and is usually dependent on the Effective Request URI. 918 920 </t> 919 921 <t> … … 943 945 <t> 944 946 The PUT method requests that the enclosed entity be stored at the 945 supplied request-target. If the request-targetrefers to an already947 Effective Request URI. If the Effective Request URI refers to an already 946 948 existing resource, the enclosed entity &SHOULD; be considered as a 947 modified version of the one residing on the origin server. If the948 request-targetdoes not point to an existing resource, and that URI is949 modified version of the one residing on the origin server. Otherwise, if the 950 Effective Request URI does not point to an existing resource, and that URI is 949 951 capable of being defined as a new resource by the requesting user 950 agent, the origin server can create the resource with that URI. If a 951 new resource is created at the request-target, the origin server &MUST; 952 inform the user agent 952 agent, the origin server can create the resource with that URI. 953 </t> 954 <t> 955 If a new resource is created at the Effective Request URI, the origin 956 server &MUST; inform the user agent 953 957 via the 201 (Created) response. If an existing resource is modified, 954 958 either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent 955 to indicate successful completion of the request. If the resource 956 could not be created or modified with the request-target, an appropriate 957 error response &SHOULD; be given that reflects the nature of the 958 problem. The recipient of the entity &MUST-NOT; ignore any Content-* 959 to indicate successful completion of the request. 960 </t> 961 <t> 962 If the resource could not be created or modified with the Effective Request 963 URI, an appropriate error response &SHOULD; be given that reflects the nature 964 of the problem. The recipient of the entity &MUST-NOT; ignore any Content-* 959 965 headers (headers starting with the prefix "Content-") that it does 960 966 not understand or implement … … 962 968 </t> 963 969 <t> 964 If the request passes through a cache and the request-target identifies965 one or more currently cached entities, those entries &SHOULD; be970 If the request passes through a cache and the Effective Request URI 971 identifies one or more currently cached entities, those entries &SHOULD; be 966 972 treated as stale. Responses to this method are not cacheable. 967 973 </t> 968 974 <t> 969 975 The fundamental difference between the POST and PUT requests is 970 reflected in the different meaning of the request-target. The URI in a976 reflected in the different meaning of the Effective Request URI. The URI in a 971 977 POST request identifies the resource that will handle the enclosed 972 978 entity. That resource might be a data-accepting process, a gateway to … … 1003 1009 <t> 1004 1010 The DELETE method requests that the origin server delete the resource 1005 identified by the request-target. This method &MAY; be overridden by human1006 intervention (or other means) on the origin server. The client cannot1011 identified by the Effective Request URI. This method &MAY; be overridden by 1012 human intervention (or other means) on the origin server. The client cannot 1007 1013 be guaranteed that the operation has been carried out, even if the 1008 1014 status code returned from the origin server indicates that the action … … 1019 1025 </t> 1020 1026 <t> 1021 If the request passes through a cache and the request-target identifies1022 one or more currently cached entities, those entries &SHOULD; be1027 If the request passes through a cache and the Effective Request URI 1028 identifies one or more currently cached entities, those entries &SHOULD; be 1023 1029 treated as stale. Responses to this method are not cacheable. 1024 1030 </t> … … 1331 1337 future references to this resource &SHOULD; use one of the returned 1332 1338 URIs. Clients with link editing capabilities ought to automatically 1333 re-link references to the request-targetto one or more of the new1339 re-link references to the Effective Request URI to one or more of the new 1334 1340 references returned by the server, where possible. This response is 1335 1341 cacheable unless indicated otherwise. … … 1364 1370 The requested resource resides temporarily under a different URI. 1365 1371 Since the redirection might be altered on occasion, the client &SHOULD; 1366 continue to use the request-targetfor future requests. This response1372 continue to use the Effectice Request URI for future requests. This response 1367 1373 is only cacheable if indicated by a Cache-Control or Expires header 1368 1374 field. … … 1477 1483 The requested resource resides temporarily under a different URI. 1478 1484 Since the redirection &MAY; be altered on occasion, the client &SHOULD; 1479 continue to use the request-targetfor future requests. This response1485 continue to use the Effective Request URI for future requests. This response 1480 1486 is only cacheable if indicated by a Cache-Control or Expires header 1481 1487 field. … … 1567 1573 <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 1568 1574 <t> 1569 The server has not found anything matching the request-target. No1575 The server has not found anything matching the Effective Request URI. No 1570 1576 indication is given of whether the condition is temporary or 1571 1577 permanent. The 410 (Gone) status code &SHOULD; be used if the server … … 1583 1589 <t> 1584 1590 The method specified in the Request-Line is not allowed for the 1585 resource identified by the request-target. The response &MUST; include an1591 resource identified by the Effective Request URI. The response &MUST; include an 1586 1592 Allow header containing a list of valid methods for the requested 1587 1593 resource. … … 1674 1680 forwarding address is known. This condition is expected to be 1675 1681 considered permanent. Clients with link editing capabilities &SHOULD; 1676 delete references to the request-targetafter user approval. If the1682 delete references to the Effective Request URI after user approval. If the 1677 1683 server does not know, or has no facility to determine, whether or not 1678 1684 the condition is permanent, the status code 404 (Not Found) &SHOULD; be … … 1736 1742 <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 1737 1743 <t> 1738 The server is refusing to service the request because the request-target1744 The server is refusing to service the request because the Effective Request URI 1739 1745 is longer than the server is willing to interpret. This rare 1740 1746 condition is only likely to occur when a client has improperly … … 1744 1750 itself), or when the server is under attack by a client attempting to 1745 1751 exploit security holes present in some servers using fixed-length 1746 buffers for reading or manipulating the request-target.1752 buffers for reading or manipulating the Effective Request URI. 1747 1753 </t> 1748 1754 </section> … … 1896 1902 <t> 1897 1903 The "Allow" response-header field lists the set of methods advertised as 1898 supported by the resource identified by the request-target. The purpose of1904 supported by the resource identified by the Effective Request URI. The purpose of 1899 1905 this field is strictly to inform the recipient of valid methods 1900 1906 associated with the resource. … … 2129 2135 <t> 2130 2136 The "Referer" [sic] request-header field allows the client to specify the 2131 URI of the resource from which the request-targetwas obtained (the2137 URI of the resource from which the Effective Request URI was obtained (the 2132 2138 "referrer", although the header field is misspelled.). 2133 2139 </t> … … 2141 2147 </t> 2142 2148 <t> 2143 If the request-targetwas obtained from a source that does not have its own2149 If the Effective Request URI was obtained from a source that does not have its own 2144 2150 URI (e.g., input from the user keyboard), the Referer field &MUST; either be 2145 2151 sent with the value "about:blank", or not be sent at all. Note that this … … 2158 2164 <t> 2159 2165 If the field value is a relative URI, it &SHOULD; be interpreted 2160 relative to the request-target. The URI &MUST-NOT; include a fragment. See2166 relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See 2161 2167 <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 2162 2168 </t> … … 2702 2708 </t> 2703 2709 <t> 2704 Authors of services should not use 2705 GET-based forms for the submission of sensitive data because that 2706 data will be encoded in the Request-target. Many existing 2707 servers, proxies, and user agents log or display the Request-target in 2708 places where it might be visible to third parties. Such services can 2710 Authors of services should not use GET-based forms for the submission of 2711 sensitive data because that data will be encoded in the request-target. Many 2712 existing servers, proxies, and user agents log or display the request-target 2713 in places where it might be visible to third parties. Such services can 2709 2714 use POST-based form submission instead. 2710 2715 </t> … … 3781 3786 "Location header payload handling" 3782 3787 </t> 3788 <t> 3789 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 3790 "Term for the requested resource's URI" 3791 </t> 3783 3792 </list> 3784 3793 </t> -
draft-ietf-httpbis/latest/p3-payload.html
r814 r823 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-05- 01">403 <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: November 2 , 2010</td>429 <td class="left">Expires: November 27, 2010</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">May 1, 2010</td>486 <td class="right">May 26, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in November 2 , 2010.</p>512 <p>This Internet-Draft will expire in November 27, 2010.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1223 1223 </p> 1224 1224 <div id="rfc.figure.u.27"></div><pre class="text"> Content-Encoding: gzip 1225 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the request-target. Typically, the entity-body is stored1226 with this encoding and is only decoded before rendering or analogous usage. However,a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control1225 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However, 1226 a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 1227 1227 directive is present in the message. 1228 1228 </p> … … 1273 1273 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1274 1274 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1275 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of1276 the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-targetif the desire is to identify the source of that particular entity.1275 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. 1276 Future requests <em class="bcp14">MAY</em> may be addressed to the Content-Location URI if the desire is to identify the source of that particular entity. 1277 1277 </p> 1278 1278 <p id="rfc.section.5.7.p.5"> <a href="p2-semantics.html#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> describes how clients may process the Content-Location header field. … … 1282 1282 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1283 1283 </p> 1284 <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>1284 <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Effective Request URI.</p> 1285 1285 <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p> 1286 1286 <div id="rfc.iref.c.10"></div> … … 1450 1450 <td class="left">compress</td> 1451 1451 <td class="left">UNIX "compress" program method</td> 1452 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1452 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1453 1453 </td> 1454 1454 </tr> … … 1457 1457 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 1458 1458 </td> 1459 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1459 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1460 1460 </td> 1461 1461 </tr> … … 1463 1463 <td class="left">gzip</td> 1464 1464 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 1465 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1465 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1466 1466 </td> 1467 1467 </tr> … … 1730 1730 </p> 1731 1731 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2> 1732 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.1732 <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 1733 1733 </p> 1734 1734 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> … … 1747 1747 </p> 1748 1748 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1749 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1749 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1750 1750 </p> 1751 1751 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 1792 1792 <p id="rfc.section.C.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1793 1793 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1794 computed. (<a href="#entity.length" title="Entity Length">Section 3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1794 computed. (<a href="#entity.length" title="Entity Length">Section 3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1795 1795 </p> 1796 1796 <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 5.2</a>) … … 2052 2052 </li> 2053 2053 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>>: "use of term "word" when talking about header structure" 2054 </li> 2055 </ul> 2056 <p id="rfc.section.E.11.p.2">Partly resolved issues: </p> 2057 <ul> 2058 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 2054 2059 </li> 2055 2060 </ul> … … 2192 2197 </li> 2193 2198 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2194 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a>, <a class="iref" href="#rfc.xref.Part1.22"> 6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a>, <a class="iref" href="#rfc.xref.Part1.27">C.1</a><ul class="ind">2199 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a>, <a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.27">A.3</a>, <a class="iref" href="#rfc.xref.Part1.28">A.6</a>, <a class="iref" href="#rfc.xref.Part1.29">C.1</a><ul class="ind"> 2195 2200 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a></li> 2196 2201 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li> … … 2199 2204 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.18">3.2</a></li> 2200 2205 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a></li> 2201 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.25">A.3</a></li> 2206 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a></li> 2207 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.27">A.3</a></li> 2202 2208 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li> 2203 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 2">6.2</a></li>2209 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li> 2204 2210 <li class="indline1"><em>Section 6.2.2</em> <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li> 2205 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 3">6.2</a></li>2206 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 4">6.2</a></li>2211 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a></li> 2212 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a></li> 2207 2213 <li class="indline1"><em>Section 6.4</em> <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a></li> 2208 2214 <li class="indline1"><em>Section 9.2</em> <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li> 2209 <li class="indline1"><em>Section 9.7</em> <a class="iref" href="#rfc.xref.Part1.2 6">A.6</a></li>2215 <li class="indline1"><em>Section 9.7</em> <a class="iref" href="#rfc.xref.Part1.28">A.6</a></li> 2210 2216 </ul> 2211 2217 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r814 r823 33 33 <!ENTITY qvalue "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 34 34 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 35 36 <!ENTITY compression-codings "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 36 37 <!ENTITY transfer-codings "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1338 1339 <t> 1339 1340 The content-coding is a characteristic of the entity identified by 1340 the request-target. Typically, the entity-body is stored with this1341 the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this 1341 1342 encoding and is only decoded before rendering or analogous usage. 1342 1343 However, a non-transparent proxy &MAY; modify the content-coding if the … … 1439 1440 </artwork></figure> 1440 1441 <t> 1441 The Content-Location value is not a replacement for the original1442 requested URI; it is only a statement of the location of the resource1442 The Content-Location value is not a replacement for the Effective 1443 Request URI (&effective-request-uri;); it is only a statement of the location of the resource 1443 1444 corresponding to this particular entity at the time of the request. 1444 Future requests &MAY; specify the Content-Location URI as the request-target1445 Future requests &MAY; may be addressed to the Content-Location URI 1445 1446 if the desire is to identify the source of that particular 1446 1447 entity. … … 1458 1459 <t> 1459 1460 If the Content-Location is a relative URI, the relative URI is 1460 interpreted relative to the request-target.1461 interpreted relative to the Effective Request URI. 1461 1462 </t> 1462 1463 <t> … … 3150 3151 </list> 3151 3152 </t> 3153 <t> 3154 Partly resolved issues: 3155 <list style="symbols"> 3156 <t> 3157 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 3158 "Term for the requested resource's URI" 3159 </t> 3160 </list> 3161 </t> 3152 3162 </section> 3153 3163 -
draft-ietf-httpbis/latest/p6-cache.html
r817 r823 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-05- 07">404 <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: November 8, 2010</td>430 <td class="left">Expires: November 27, 2010</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">May 7, 2010</td>491 <td class="right">May 26, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire in November 8, 2010.</p>517 <p>This Internet-Draft will expire in November 27, 2010.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 759 759 </p> 760 760 <ul> 761 <li>The presented Request-URI and that of the stored response match (<span class="comment" id="TODO-Request-URI">[<a href="#TODO-Request-URI" class="smpl">TODO-Request-URI</a>: Need to find a new term for this, as Part 1 doesn't define Request-URI anymore; the new term request-target does not work 762 for this. (see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>)]</span>), and 761 <li>The presented Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>) and that of the stored response match, and 763 762 </li> 764 763 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 860 859 <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response 861 860 was generated. The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations. 862 See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header, and for requirements regarding responses without a Date response header.861 See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header, and for requirements regarding responses without a Date response header. 863 862 </li> 864 863 </ul> … … 936 935 <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 937 936 </p> 938 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URIas well as the URI(s) in the Location and Content-Location headers (if present):937 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present): 939 938 </p> 940 939 <ul> … … 943 942 <li>POST</li> 944 943 </ul> 945 <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service 946 attacks. 944 <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 947 945 </p> 948 946 <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span> 949 947 </p> 950 <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.951 </p> 952 <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Request-URI, or will mark these953 as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.948 <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 949 </p> 950 <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will 951 mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 954 952 </p> 955 953 <p id="rfc.section.2.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the … … 967 965 <ul> 968 966 <li>adding or removing whitespace, where allowed in the header's syntax</li> 969 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)967 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 970 968 </li> 971 969 <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification … … 1253 1251 that time. 1254 1252 </p> 1255 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.1253 <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1256 1254 </p> 1257 1255 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.expires" class="smpl">Expires</a> = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a> … … 1873 1871 </li> 1874 1872 </ul> 1873 <p id="rfc.section.C.11.p.2">Partly resolved issues: </p> 1874 <ul> 1875 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 1876 </li> 1877 </ul> 1875 1878 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1876 1879 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a> … … 2010 2013 </li> 2011 2014 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2012 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2. 3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind">2015 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.5</a>, <a class="iref" href="#rfc.xref.Part1.14">2.5</a>, <a class="iref" href="#rfc.xref.Part1.15">2.5</a>, <a class="iref" href="#rfc.xref.Part1.16">2.6</a>, <a class="iref" href="#rfc.xref.Part1.17">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 2013 2016 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.4</a></li> 2014 2017 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li> 2015 2018 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li> 2016 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a></li> 2017 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a></li> 2018 <li class="indline1"><em>Section 9.3</em> <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li> 2019 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.16">2.6</a></li> 2020 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.11">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.5</a>, <a class="iref" href="#rfc.xref.Part1.14">2.5</a>, <a class="iref" href="#rfc.xref.Part1.15">2.5</a></li> 2021 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.3</a></li> 2022 <li class="indline1"><em>Section 9.3</em> <a class="iref" href="#rfc.xref.Part1.12">2.3.2</a></li> 2019 2023 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a></li> 2020 2024 </ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r817 r823 18 18 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 21 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 478 479 For a presented request, a cache &MUST-NOT; return a stored response, unless: 479 480 <list style="symbols"> 480 <t>The presented Request-URI and that of the stored response match 481 (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part 482 1 doesn't define Request-URI anymore; the new term request-target does not 483 work for this. (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />)</cref>), and</t> 481 <t>The presented Effective Request URI (&effective-request-uri;) and that of the stored response match, and</t> 484 482 <t>the request method associated with the stored response allows it to be 485 483 used for the presented request, and</t> … … 798 796 </t> 799 797 <t> 800 The following HTTP methods &MUST; cause a cache to invalidate the Request-URIas well798 The following HTTP methods &MUST; cause a cache to invalidate the Effective Request URI (&effective-request-uri;) as well 801 799 as the URI(s) in the Location and Content-Location headers (if present): 802 800 <list style="symbols"> … … 808 806 <t> 809 807 An invalidation based on a URI from a Location or Content-Location header &MUST-NOT; 810 be performed if the host part of that URI differs from the host part in the Request-URI.808 be performed if the host part of that URI differs from the host part in the Effective Request URI (&effective-request-uri;). 811 809 This helps prevent denial of service attacks. 812 810 </t> … … 816 814 <t> 817 815 A cache that passes through requests for methods it does not understand &SHOULD; 818 invalidate the Request-URI.816 invalidate the Effective Request URI (&effective-request-uri;). 819 817 </t> 820 818 <t> 821 819 Here, "invalidate" means that the cache will either remove all stored responses related 822 to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation820 to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation 823 821 before they can be returned in response to a subsequent request. 824 822 </t> … … 2450 2448 </list> 2451 2449 </t> 2450 <t> 2451 Partly resolved issues: 2452 <list style="symbols"> 2453 <t> 2454 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 2455 "Term for the requested resource's URI" 2456 </t> 2457 </list> 2458 </t> 2452 2459 </section> 2453 2460 -
draft-ietf-httpbis/latest/p7-auth.html
r814 r823 394 394 <meta name="dct.creator" content="Reschke, J. F."> 395 395 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 396 <meta name="dct.issued" scheme="ISO8601" content="2010-05- 01">396 <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 397 397 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 398 398 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 425 425 </tr> 426 426 <tr> 427 <td class="left">Expires: November 2 , 2010</td>427 <td class="left">Expires: November 27, 2010</td> 428 428 <td class="right">HP</td> 429 429 </tr> … … 478 478 <tr> 479 479 <td class="left"></td> 480 <td class="right">May 1, 2010</td>480 <td class="right">May 26, 2010</td> 481 481 </tr> 482 482 </tbody> … … 504 504 in progress”. 505 505 </p> 506 <p>This Internet-Draft will expire in November 2 , 2010.</p>506 <p>This Internet-Draft will expire in November 27, 2010.</p> 507 507 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 508 508 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 657 657 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 658 658 <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters 659 applicable to the proxy for this request-target. It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.659 applicable to the proxy for this Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">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>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 660 660 </p> 661 661 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> … … 685 685 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 686 686 <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s) 687 and parameters applicable to the request-target. It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.687 and parameters applicable to the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 688 688 </p> 689 689 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> … … 938 938 <p id="rfc.section.C.10.p.1">No significant changes.</p> 939 939 <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a> <a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p7-auth-09</a></h2> 940 <p id="rfc.section.C.11.p.1">None yet.</p> 940 <p id="rfc.section.C.11.p.1">Partly resolved issues: </p> 941 <ul> 942 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 943 </li> 944 </ul> 941 945 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 942 946 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a> … … 982 986 </li> 983 987 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 984 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="# Part1"><b>7.1</b></a><ul class="ind">988 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a>, <a class="iref" href="#Part1"><b>7.1</b></a><ul class="ind"> 985 989 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a></li> 986 990 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a></li> 991 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.4">3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a></li> 987 992 </ul> 988 993 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r814 r823 18 18 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 21 <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 ]> … … 401 402 The "Proxy-Authenticate" response-header field consists of a challenge that 402 403 indicates the authentication scheme and parameters applicable to the proxy 403 for this request-target. It &MUST; be included as part404 for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part 404 405 of a 407 (Proxy Authentication Required) response. 405 406 </t> … … 460 461 The "WWW-Authenticate" response-header field consists of at least one 461 462 challenge that indicates the authentication scheme(s) and parameters 462 applicable to the request-target. It &MUST; be included in 401463 applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401 463 464 (Unauthorized) response messages. 464 465 </t> … … 977 978 <section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09"> 978 979 <t> 979 None yet. 980 Partly resolved issues: 981 <list style="symbols"> 982 <t> 983 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 984 "Term for the requested resource's URI" 985 </t> 986 </list> 980 987 </t> 981 988 </section>
Note: See TracChangeset
for help on using the changeset viewer.