Changeset 994 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 07/09/10 11:46:12 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r981 r994 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-09-0 1">405 <meta name="dct.issued" scheme="ISO8601" content="2010-09-07"> 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: March 5, 2011</td>436 <td class="left">Expires: March 11, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">September 1, 2010</td>489 <td class="right">September 7, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire on March 5, 2011.</p>516 <p>This Internet-Draft will expire on March 11, 2011.</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> … … 917 917 </li> 918 918 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 919 representation of the target (see <a href="p6-cache.html#combining. headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).920 </li> 921 <li>If the response has a Content-Location header , and that URI is the same as the effective request URI, the response payload919 representation of the target (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 920 </li> 921 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload 922 922 is a representation of the target resource. 923 923 </li> 924 <li>If the response has a Content-Location header , and that URI is not the same as the effective request URI, then the response924 <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response 925 925 asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion 926 926 cannot be trusted unless it can be verified by other means (not defined by HTTP). … … 1005 1005 <div id="rfc.iref.h.1"></div> 1006 1006 <div id="rfc.iref.m.3"></div> 1007 <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP header s in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1007 <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1008 1008 representation implied by the request without transferring the representation body. This method is often used for testing 1009 1009 hypertext links for validity, accessibility, and recent modification. … … 1033 1033 </p> 1034 1034 <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1035 a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>).1036 </p> 1037 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1035 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1036 </p> 1037 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1038 1038 </p> 1039 1039 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1051 1051 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1052 1052 </p> 1053 <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <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. 1053 <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* header fields (headers starting with the prefix "Content-") that it does not understand or implement 1054 and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1054 1055 </p> 1055 1056 <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable. … … 1106 1107 <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metadata required in the response.</p> 1107 1108 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> 1108 <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header s, and is1109 terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any1110 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.1109 <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header fields, 1110 and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did 1111 not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 1111 1112 </p> 1112 1113 <p id="rfc.section.8.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 … … 1361 1362 <div id="rfc.iref.s.24"></div> 1362 1363 <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> 1363 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1364 <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource. 1364 1365 </p> 1365 1366 <div id="rfc.iref.48"></div> … … 1367 1368 <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1368 1369 <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1369 not acceptable according to the accept header s sent in the request.1370 not acceptable according to the accept header fields sent in the request. 1370 1371 </p> 1371 1372 <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user … … 1374 1375 </p> 1375 1376 <div class="note" id="rfc.section.8.4.7.p.3"> 1376 <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header s sent in the request.1377 In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the headers1378 of an incoming response to determine if it is acceptable.1377 <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the 1378 request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the 1379 header fields of an incoming response to determine if it is acceptable. 1379 1380 </p> 1380 1381 </div> … … 1490 1491 <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 1491 1492 <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication 1492 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header . If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.1493 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1493 1494 </p> 1494 1495 <div class="note" id="rfc.section.8.5.4.p.2"> … … 1551 1552 </p> 1552 1553 <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the 1553 Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.1554 </p> 1555 <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>1554 Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1555 </p> 1556 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 1556 1557 <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.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 1557 1558 </p> … … 1568 1569 <div id="rfc.figure.u.16"></div><pre class="text"> From: webmaster@example.org 1569 1570 </pre><p id="rfc.section.9.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 1570 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving1571 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving 1571 1572 end. 1572 1573 </p> … … 1596 1597 </pre><p id="rfc.section.9.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p> 1597 1598 <ul> 1598 <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li>1599 <li>With a 201 Created response, because in this usage the Location header field specifies the URI for the entire created resource.</li> 1599 1600 <li>With 305 Use Proxy.</li> 1600 1601 </ul> … … 1629 1630 URI was obtained (the "referrer", although the header field is misspelled.). 1630 1631 </p> 1631 <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.1632 It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling1632 <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 1633 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 1633 1634 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 1634 1635 </p> … … 1673 1674 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1674 1675 <div id="rfc.figure.u.27"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1675 </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.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1676 </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 field. 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.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1676 1677 </p> 1677 1678 <div class="note" id="rfc.section.9.8.p.7"> … … 2098 2099 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall. 2099 2100 </p> 2100 <p id="rfc.section.11.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power 2101 can be abused if user details are not separated from the information contained in the Referer. Even when the personal information 2102 has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. 2101 <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its 2102 power can be abused if user details are not separated from the information contained in the Referer. Even when the personal 2103 information has been removed, the Referer header field might indicate a private document's URI whose publication would be 2104 inappropriate. 2103 2105 </p> 2104 2106 <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and … … 2112 2114 has no better mechanism. 2113 2115 </p> 2114 <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 7.8</a>), expose information that was sent in request header s within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect2115 data from the client.2116 <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other header fields that might be used 2117 to collect data from the client. 2116 2118 </p> 2117 2119 <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2> … … 2128 2130 </p> 2129 2131 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> 2130 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header s in responses that are generated under control of said organizations2132 <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations 2131 2133 to make sure that they do not attempt to invalidate resources over which they have no authority. 2132 2134 </p> … … 2252 2254 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 8.3.6</a>) 2253 2255 </p> 2254 <p id="rfc.section.A.p.5">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement2255 on the contents of the Allow header and remove requirement on clients to always trust the headervalue. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>)2256 </p> 2257 <p id="rfc.section.A.p.6">Correct syntax of Location header to allow URI references (including relative references and fragments), as referred symbol2258 "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.2256 <p id="rfc.section.A.p.5">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 2257 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>) 2258 </p> 2259 <p id="rfc.section.A.p.6">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 2260 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 2259 2261 (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.4</a>) 2260 2262 </p> 2261 <p id="rfc.section.A.p.7">Allow Referer value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.6</a>)2262 </p> 2263 <p id="rfc.section.A.p.8">In the description of the Server header , the Via field was described as a SHOULD. The requirement was and is stated correctly2264 in the description of the Via headerin <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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>)2263 <p id="rfc.section.A.p.7">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.6</a>) 2264 </p> 2265 <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2266 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><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>) 2265 2267 </p> 2266 2268 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2422 2424 </p> 2423 2425 <ul> 2424 <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header .</li>2426 <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li> 2425 2427 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 2426 2428 <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li> … … 2444 2446 </li> 2445 2447 </ul> 2446 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):2448 <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 2447 2449 </p> 2448 2450 <ul> 2449 <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>2451 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 2450 2452 </ul> 2451 2453 <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): … … 2482 2484 <li>Use "/" instead of "|" for alternatives.</li> 2483 2485 <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li> 2484 <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>2486 <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li> 2485 2487 </ul> 2486 2488 <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a> <a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p2-semantics-05</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.