Changeset 1772
- Timestamp:
- 14/07/12 14:09:09 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.html
r1764 r1772 393 393 } 394 394 @bottom-center { 395 content: "Expires January 1 4, 2013";395 content: "Expires January 15, 2013"; 396 396 } 397 397 @bottom-right { … … 426 426 <meta name="dct.creator" content="Reschke, J. F."> 427 427 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest"> 428 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">428 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 429 429 <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> 430 430 <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1."> … … 446 446 </tr> 447 447 <tr> 448 <td class="left">Expires: January 1 4, 2013</td>448 <td class="left">Expires: January 15, 2013</td> 449 449 <td class="right">W3C</td> 450 450 </tr> … … 467 467 <tr> 468 468 <td class="left"></td> 469 <td class="right">July 1 3, 2012</td>469 <td class="right">July 14, 2012</td> 470 470 </tr> 471 471 </tbody> … … 490 490 in progress”. 491 491 </p> 492 <p>This Internet-Draft will expire on January 1 4, 2013.</p>492 <p>This Internet-Draft will expire on January 15, 2013.</p> 493 493 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 494 494 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 529 529 protocols. Also includes the HTTP and HTTPS URI schemes. 530 530 </li> 531 <li><a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> HTTP/1.1 Core Semantics - Protocol elements such as methods, status codes, and payload-specific header s. Also includes content532 negotiation mechanisms.531 <li><a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> HTTP/1.1 Core Semantics - Protocol elements such as methods, status codes, and payload-specific header fields. Also includes 532 content negotiation mechanisms. 533 533 </li> 534 534 <li><a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> HTTP/1.1 Conditional Requests - An extension to make requests contingent upon their current state. -
draft-ietf-httpbis/latest/p0-introduction.xml
r1764 r1772 136 136 schemes.</t> 137 137 <t><xref target="Part2"/> HTTP/1.1 Core Semantics - Protocol elements such 138 as methods, status codes, and payload-specific header s. Also includes138 as methods, status codes, and payload-specific header fields. Also includes 139 139 content negotiation mechanisms.</t> 140 140 <t><xref target="Part4"/> HTTP/1.1 Conditional Requests - An extension to -
draft-ietf-httpbis/latest/p1-messaging.html
r1771 r1772 1301 1301 (Client Error)</a> status code if the received header field(s) would be longer than the server wishes to handle. 1302 1302 </p> 1303 <p id="rfc.section.3.2.3.p.2">A client that receives response header s that are longer than it wishes to handle can only treat it as a server error.</p>1304 <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.1303 <p id="rfc.section.3.2.3.p.2">A client that receives response header fields that are longer than it wishes to handle can only treat it as a server error.</p> 1304 <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header field length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. 1305 1305 </p> 1306 1306 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.components" href="#field.components">Field value components</a></h3> … … 1609 1609 </li> 1610 1610 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable 1611 to the server where the field originated) without receiving it. In other words, the server that generated the header (often1612 but not always the origin server) is willing to accept the possibility that the trailer fields might be silently discarded1611 to the server where the field originated) without receiving it. In other words, the server that generated the header field 1612 (often but not always the origin server) is willing to accept the possibility that the trailer fields might be silently discarded 1613 1613 along the path to the client. 1614 1614 </li> … … 2976 2976 <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly 2977 2977 negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0 2978 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header to the next inbound server, which would result in a hung connection. 2979 </p> 2980 <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this 2981 was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed above. 2982 </p> 2983 <p id="rfc.section.A.1.2.p.4">As a result, clients are encouraged not to send the Proxy-Connection header in any requests.</p> 2978 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection. 2979 </p> 2980 <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header field, targeted specifically at proxies. In practice, 2981 this was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed 2982 above. 2983 </p> 2984 <p id="rfc.section.A.1.2.p.4">As a result, clients are encouraged not to send the Proxy-Connection header field in any requests.</p> 2984 2985 <p id="rfc.section.A.1.2.p.5">Clients are also encouraged to consider the use of Connection: keep-alive in requests carefully; while they can enable persistent 2985 2986 connections with HTTP/1.0 servers, clients using them need will need to monitor the connection for "hung" requests (which 2986 indicate that the client ought stop sending the header ), and this mechanism ought not be used by clients at all when a proxy2987 is being used.2987 indicate that the client ought stop sending the header field), and this mechanism ought not be used by clients at all when 2988 a proxy is being used. 2988 2989 </p> 2989 2990 <h3 id="rfc.section.A.1.3"><a href="#rfc.section.A.1.3">A.1.3</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3> … … 3258 3259 </p> 3259 3260 <ul> 3260 <li>Reference RFC 3984, and update header field registrations for header s defined in this document.</li>3261 <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li> 3261 3262 </ul> 3262 3263 <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>>): … … 3278 3279 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/128">http://tools.ietf.org/wg/httpbis/trac/ticket/128</a>>: "Cite HTTPS URI scheme definition" 3279 3280 </li> 3280 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/129">http://tools.ietf.org/wg/httpbis/trac/ticket/129</a>>: "List-type header s vs Set-Cookie"3281 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/129">http://tools.ietf.org/wg/httpbis/trac/ticket/129</a>>: "List-type header fields vs Set-Cookie" 3281 3282 </li> 3282 3283 </ul> … … 3359 3360 <p id="rfc.section.C.9.p.1">Closed issues: </p> 3360 3361 <ul> 3361 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/93">http://tools.ietf.org/wg/httpbis/trac/ticket/93</a>>: "Repeating single-value header s"3362 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/93">http://tools.ietf.org/wg/httpbis/trac/ticket/93</a>>: "Repeating single-value header fields" 3362 3363 </li> 3363 3364 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/131">http://tools.ietf.org/wg/httpbis/trac/ticket/131</a>>: "increase connection limit" … … 3393 3394 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>>: "Placement of 13.5.1 and 13.5.2" 3394 3395 </li> 3395 <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"3396 <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 field structure" 3396 3397 </li> 3397 3398 </ul> … … 3409 3410 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/165">http://tools.ietf.org/wg/httpbis/trac/ticket/165</a>>: "Case-sensitivity of HTTP-date" 3410 3411 </li> 3411 <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"3412 <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 field structure" 3412 3413 </li> 3413 3414 </ul> … … 3424 3425 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/90">http://tools.ietf.org/wg/httpbis/trac/ticket/90</a>>: "Delimiting messages with multipart/byteranges" 3425 3426 </li> 3426 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header s"3427 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header fields" 3427 3428 </li> 3428 3429 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>>: "Clarify entity / representation / variant terminology" … … 3450 3451 <p id="rfc.section.C.13.p.2">Partly resolved issues: </p> 3451 3452 <ul> 3452 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header s"3453 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header fields" 3453 3454 </li> 3454 3455 </ul> … … 3462 3463 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/210">http://tools.ietf.org/wg/httpbis/trac/ticket/210</a>>: "define 'transparent' proxy" 3463 3464 </li> 3464 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification"3465 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Field Classification" 3465 3466 </li> 3466 3467 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/233">http://tools.ietf.org/wg/httpbis/trac/ticket/233</a>>: "Is * usable as a request-uri for new methods?" … … 3478 3479 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/53">http://tools.ietf.org/wg/httpbis/trac/ticket/53</a>>: "Allow is not in 13.5.2" 3479 3480 </li> 3480 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header s"3481 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>>: "Handling multiple Content-Length header fields" 3481 3482 </li> 3482 3483 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" … … 3514 3515 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 3515 3516 </li> 3516 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>>: "Explain header registration"3517 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>>: "Explain header field registration" 3517 3518 </li> 3518 3519 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/219">http://tools.ietf.org/wg/httpbis/trac/ticket/219</a>>: "Revise Acknowledgements Sections" -
draft-ietf-httpbis/latest/p1-messaging.xml
r1771 r1772 1352 1352 </t> 1353 1353 <t> 1354 A client that receives response header s that are longer than it wishes to1355 handle can only treat it as a server error.1356 </t> 1357 <t> 1358 Various ad-hoc limitations on header length are found in practice. It is1359 &RECOMMENDED; that all HTTP senders and recipients support messages whose1354 A client that receives response header fields that are longer than it wishes 1355 to handle can only treat it as a server error. 1356 </t> 1357 <t> 1358 Various ad-hoc limitations on header field length are found in practice. It 1359 is &RECOMMENDED; that all HTTP senders and recipients support messages whose 1360 1360 combined header fields have 4000 or more octets. 1361 1361 </t> … … 1996 1996 recipient could use the message (in a manner acceptable to the server where 1997 1997 the field originated) without receiving it. In other words, the server that 1998 generated the header (often but not always the origin server) is willing to1999 accept the possibility that the trailer fields might be silently discarded2000 along the path to the client.</t>1998 generated the header field (often but not always the origin server) is 1999 willing to accept the possibility that the trailer fields might be silently 2000 discarded along the path to the client.</t> 2001 2001 </list> 2002 2002 </t> … … 4974 4974 experimental implementations of HTTP/1.0 persistent connections are faulty; 4975 4975 for example, if a HTTP/1.0 proxy server doesn't understand 4976 <x:ref>Connection</x:ref>, it will erroneously forward that header to the4977 next inbound server, which would result in a hung connection.4978 </t> 4979 <t> 4980 One attempted solution was the introduction of a Proxy-Connection header ,4981 targeted specifically at proxies. In practice, this was also unworkable,4982 because proxies are often deployed in multiple layers, bringing about the4983 same problem discussed above.4976 <x:ref>Connection</x:ref>, it will erroneously forward that header field 4977 to the next inbound server, which would result in a hung connection. 4978 </t> 4979 <t> 4980 One attempted solution was the introduction of a Proxy-Connection header 4981 field, targeted specifically at proxies. In practice, this was also 4982 unworkable, because proxies are often deployed in multiple layers, bringing 4983 about the same problem discussed above. 4984 4984 </t> 4985 4985 <t> 4986 4986 As a result, clients are encouraged not to send the Proxy-Connection header 4987 in any requests.4987 field in any requests. 4988 4988 </t> 4989 4989 <t> … … 4992 4992 HTTP/1.0 servers, clients using them need will need to monitor the 4993 4993 connection for "hung" requests (which indicate that the client ought stop 4994 sending the header ), and this mechanism ought not be used by clients at all4995 when a proxy is being used.4994 sending the header field), and this mechanism ought not be used by clients 4995 at all when a proxy is being used. 4996 4996 </t> 4997 4997 </section> … … 5431 5431 <list style="symbols"> 5432 5432 <t> 5433 Reference RFC 3984, and update header field registrations for header s defined5434 in this document.5433 Reference RFC 3984, and update header field registrations for header 5434 fields defined in this document. 5435 5435 </t> 5436 5436 </list> … … 5472 5472 <t> 5473 5473 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/129"/>: 5474 "List-type header s vs Set-Cookie"5474 "List-type header fields vs Set-Cookie" 5475 5475 </t> 5476 5476 </list> … … 5634 5634 <t> 5635 5635 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/93"/>: 5636 "Repeating single-value header s"5636 "Repeating single-value header fields" 5637 5637 </t> 5638 5638 <t> … … 5701 5701 <t> 5702 5702 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: 5703 "use of term "word" when talking about header structure"5703 "use of term "word" when talking about header field structure" 5704 5704 </t> 5705 5705 </list> … … 5733 5733 <t> 5734 5734 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: 5735 "use of term "word" when talking about header structure"5735 "use of term "word" when talking about header field structure" 5736 5736 </t> 5737 5737 </list> … … 5762 5762 <t> 5763 5763 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>: 5764 "Handling multiple Content-Length header s"5764 "Handling multiple Content-Length header fields" 5765 5765 </t> 5766 5766 <t> … … 5812 5812 <t> 5813 5813 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>: 5814 "Handling multiple Content-Length header s"5814 "Handling multiple Content-Length header fields" 5815 5815 </t> 5816 5816 </list> … … 5836 5836 <t> 5837 5837 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>: 5838 "Header Classification"5838 "Header Field Classification" 5839 5839 </t> 5840 5840 <t> … … 5868 5868 <t> 5869 5869 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>: 5870 "Handling multiple Content-Length header s"5870 "Handling multiple Content-Length header fields" 5871 5871 </t> 5872 5872 <t> … … 5940 5940 <t> 5941 5941 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>: 5942 "Explain header registration"5942 "Explain header field registration" 5943 5943 </t> 5944 5944 <t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1770 r1772 1219 1219 </li> 1220 1220 <li> 1221 <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1221 <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1222 1222 </p> 1223 1223 </li> … … 1646 1646 </p> 1647 1647 <p id="rfc.section.4.2.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status 1648 code (e.g., combinations of request header s and/or method(s)), along with any interactions with response headers (e.g., those1649 that are required, those that modify the semantics of the response).1648 code (e.g., combinations of request header fields and/or method(s)), along with any interactions with response header fields 1649 (e.g., those that are required, those that modify the semantics of the response). 1650 1650 </p> 1651 1651 <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Codes">Section 4</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate 1652 a zero-length response body. They can require the presence of one or more particular HTTP response header (s).1652 a zero-length response body. They can require the presence of one or more particular HTTP response header field(s). 1653 1653 </p> 1654 1654 <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 7.1</a>; by default, it is anonymous). … … 3668 3668 of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will 3669 3669 also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to 3670 be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could 3671 filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 3670 be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies 3671 could filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header 3672 field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 3672 3673 </p> 3673 3674 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> … … 4253 4254 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/76">http://tools.ietf.org/wg/httpbis/trac/ticket/76</a>>: "305 Use Proxy" 4254 4255 </li> 4255 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header "4256 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header field" 4256 4257 </li> 4257 4258 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>>: "PUT - 'store under' vs 'store at'" … … 4261 4262 </p> 4262 4263 <ul> 4263 <li>Reference RFC 3984, and update header field registrations for header s defined in this document.</li>4264 <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li> 4264 4265 </ul> 4265 4266 <p id="rfc.section.E.6.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>>): … … 4273 4274 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>>: "Quoting Charsets" 4274 4275 </li> 4275 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header "4276 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>>: "Classification for Allow header field" 4276 4277 </li> 4277 4278 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/115">http://tools.ietf.org/wg/httpbis/trac/ticket/115</a>>: "missing default for qvalue in description of Accept-Encoding" … … 4281 4282 </p> 4282 4283 <ul> 4283 <li>Reference RFC 3984, and update header field registrations for header s defined in this document.</li>4284 <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li> 4284 4285 </ul> 4285 4286 <h2 id="rfc.section.E.8"><a href="#rfc.section.E.8">E.8</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></h2> … … 4398 4399 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/182">http://tools.ietf.org/wg/httpbis/trac/ticket/182</a>>: "update note about redirect limit" 4399 4400 </li> 4400 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/191">http://tools.ietf.org/wg/httpbis/trac/ticket/191</a>>: "Location header ABNF should use 'URI'"4401 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/191">http://tools.ietf.org/wg/httpbis/trac/ticket/191</a>>: "Location header field ABNF should use 'URI'" 4401 4402 </li> 4402 4403 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/192">http://tools.ietf.org/wg/httpbis/trac/ticket/192</a>>: "fragments in Location vs status 303" … … 4455 4456 <p id="rfc.section.E.20.p.2">Partly resolved issues: </p> 4456 4457 <ul> 4457 <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"4458 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header field payload handling" 4458 4459 </li> 4459 4460 <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" … … 4469 4470 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>>: "Content Sniffing" 4470 4471 </li> 4471 <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"4472 <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 field structure" 4472 4473 </li> 4473 4474 </ul> … … 4548 4549 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/103">http://tools.ietf.org/wg/httpbis/trac/ticket/103</a>>: "Content-*" 4549 4550 </li> 4550 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/104">http://tools.ietf.org/wg/httpbis/trac/ticket/104</a>>: "Header type defaulting"4551 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/104">http://tools.ietf.org/wg/httpbis/trac/ticket/104</a>>: "Header field type defaulting" 4551 4552 </li> 4552 4553 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>>: "PUT - 'store under' vs 'store at'" … … 4554 4555 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/137">http://tools.ietf.org/wg/httpbis/trac/ticket/137</a>>: "duplicate ABNF for reason-phrase" 4555 4556 </li> 4556 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/180">http://tools.ietf.org/wg/httpbis/trac/ticket/180</a>>: "Note special status of Content-* prefix in header registration procedures"4557 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/180">http://tools.ietf.org/wg/httpbis/trac/ticket/180</a>>: "Note special status of Content-* prefix in header field registration procedures" 4557 4558 </li> 4558 4559 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/203">http://tools.ietf.org/wg/httpbis/trac/ticket/203</a>>: "Max-Forwards vs extension methods" … … 4560 4561 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/213">http://tools.ietf.org/wg/httpbis/trac/ticket/213</a>>: "What is the value space of HTTP status codes?" (actually fixed in draft-ietf-httpbis-p2-semantics-11) 4561 4562 </li> 4562 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification"4563 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Field Classification" 4563 4564 </li> 4564 4565 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/225">http://tools.ietf.org/wg/httpbis/trac/ticket/225</a>>: "PUT side effect: invalidation or just stale?" … … 4580 4581 <p id="rfc.section.E.27.p.1">Closed issues: </p> 4581 4582 <ul> 4582 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification"4583 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Field Classification" 4583 4584 </li> 4584 4585 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>>: "untangle ABNFs for header fields" … … 4642 4643 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 4643 4644 </li> 4644 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>>: "Considerations for new header s"4645 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>>: "Considerations for new header fields" 4645 4646 </li> 4646 4647 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>>: "clarify 303 redirect on HEAD" … … 4656 4657 <p id="rfc.section.E.36.p.1">Closed issues: </p> 4657 4658 <ul> 4658 <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"4659 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>>: "Location header field payload handling" 4659 4660 </li> 4660 4661 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>>: "Clarify status code for rate limiting" (change backed out because a new status code is being defined for this purpose) -
draft-ietf-httpbis/latest/p2-semantics.xml
r1770 r1772 1075 1075 <x:lt><t>Under what conditions intermediaries are allowed to modify the header 1076 1076 field's value, insert or delete it.</t></x:lt> 1077 <x:lt><t>How the header might interact with caching (see <xref target="Part6"/>).</t></x:lt> 1077 <x:lt><t>How the header field might interact with caching (see 1078 <xref target="Part6"/>).</t></x:lt> 1078 1079 <x:lt><t>Whether the header field is useful or allowable in trailers (see 1079 1080 &chunked-encoding;).</t></x:lt> … … 1290 1291 Definitions of new HTTP status codes typically explain the request 1291 1292 conditions that produce a response containing the status code (e.g., 1292 combinations of request header s and/or method(s)), along with any1293 interactions with response header s (e.g., those that are required, those1294 th at modify the semantics of the response).1293 combinations of request header fields and/or method(s)), along with any 1294 interactions with response header fields (e.g., those that are required, 1295 those that modify the semantics of the response). 1295 1296 </t> 1296 1297 <t> … … 1299 1300 properly handle them, new status codes cannot disallow a response body, 1300 1301 although they can mandate a zero-length response body. They can require the 1301 presence of one or more particular HTTP response header (s).1302 presence of one or more particular HTTP response header field(s). 1302 1303 </t> 1303 1304 <t> … … 4621 4622 identifier. In environments where proxies are used to enhance 4622 4623 privacy, user agents ought to be conservative in offering accept 4623 header configuration options to end users. As an extreme privacy4624 header field configuration options to end users. As an extreme privacy 4624 4625 measure, proxies could filter the accept header fields in relayed requests. 4625 General purpose user agents which provide a high degree of header 4626 General purpose user agents which provide a high degree of header field 4626 4627 configurability &SHOULD; warn users about the loss of privacy which can 4627 4628 be involved. … … 5980 5981 <t> 5981 5982 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>: 5982 "Classification for Allow header "5983 "Classification for Allow header field" 5983 5984 </t> 5984 5985 <t> … … 5992 5993 <list style="symbols"> 5993 5994 <t> 5994 Reference RFC 3984, and update header field registrations for header s defined5995 in this document.5995 Reference RFC 3984, and update header field registrations for header 5996 fields defined in this document. 5996 5997 </t> 5997 5998 </list> … … 6017 6018 <t> 6018 6019 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>: 6019 "Classification for Allow header "6020 "Classification for Allow header field" 6020 6021 </t> 6021 6022 <t> … … 6029 6030 <list style="symbols"> 6030 6031 <t> 6031 Reference RFC 3984, and update header field registrations for header s defined6032 in this document.6032 Reference RFC 3984, and update header field registrations for header 6033 fields defined in this document. 6033 6034 </t> 6034 6035 </list> … … 6265 6266 <t> 6266 6267 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/191"/>: 6267 "Location header ABNF should use 'URI'"6268 "Location header field ABNF should use 'URI'" 6268 6269 </t> 6269 6270 <t> … … 6379 6380 <t> 6380 6381 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>: 6381 "Location header payload handling"6382 "Location header field payload handling" 6382 6383 </t> 6383 6384 <t> … … 6407 6408 <t> 6408 6409 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>: 6409 "use of term "word" when talking about header structure"6410 "use of term "word" when talking about header field structure" 6410 6411 </t> 6411 6412 </list> … … 6563 6564 <t> 6564 6565 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/104"/>: 6565 "Header type defaulting"6566 "Header field type defaulting" 6566 6567 </t> 6567 6568 <t> … … 6575 6576 <t> 6576 6577 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/180"/>: 6577 "Note special status of Content-* prefix in header registration procedures"6578 "Note special status of Content-* prefix in header field registration procedures" 6578 6579 </t> 6579 6580 <t> … … 6588 6589 <t> 6589 6590 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>: 6590 "Header Classification"6591 "Header Field Classification" 6591 6592 </t> 6592 6593 <t> … … 6628 6629 <t> 6629 6630 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>: 6630 "Header Classification"6631 "Header Field Classification" 6631 6632 </t> 6632 6633 <t> … … 6754 6755 <t> 6755 6756 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/231"/>: 6756 "Considerations for new header s"6757 "Considerations for new header fields" 6757 6758 </t> 6758 6759 <t> … … 6782 6783 <t> 6783 6784 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>: 6784 "Location header payload handling"6785 "Location header field payload handling" 6785 6786 </t> 6786 6787 <t> -
draft-ietf-httpbis/latest/p4-conditional.html
r1770 r1772 794 794 <div id="rfc.iref.h.2"></div> 795 795 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 796 <p id="rfc.section.2.3.p.1">The ETagheader field provides the current entity-tag for the selected representation. An entity-tag is an opaque validator796 <p id="rfc.section.2.3.p.1">The "ETag" header field provides the current entity-tag for the selected representation. An entity-tag is an opaque validator 797 797 for differentiating between multiple representations of the same resource, regardless of whether those multiple representations 798 798 are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the -
draft-ietf-httpbis/latest/p4-conditional.xml
r1770 r1772 482 482 <x:anchor-alias value="etagc"/> 483 483 <t> 484 The ETagheader field provides the current entity-tag for the484 The "ETag" header field provides the current entity-tag for the 485 485 selected representation. 486 486 An entity-tag is an opaque validator for differentiating between -
draft-ietf-httpbis/latest/p5-range.xml
r1770 r1772 525 525 </artwork></figure> 526 526 <t> 527 527 Origin servers that accept byte-range requests &MAY; send 528 528 </t> 529 529 <figure><artwork type="example"> … … 531 531 </artwork></figure> 532 532 <t> 533 534 535 536 </t> 537 <t> 538 539 533 but are not required to do so. Clients &MAY; generate range 534 requests without having received this header field for the resource 535 involved. Range units are defined in <xref target="range.units"/>. 536 </t> 537 <t> 538 Servers that do not accept any kind of range request for a 539 resource &MAY; send 540 540 </t> 541 541 <figure><artwork type="example"> … … 543 543 </artwork></figure> 544 544 <t> 545 545 to advise the client not to attempt a range request. 546 546 </t> 547 547 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r1770 r1772 1188 1188 <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale. 1189 1189 </p> 1190 <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header s in the stored response using the following rules:1190 <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 1191 1191 </p> 1192 1192 <ul> … … 1591 1591 </p> 1592 1592 <p id="rfc.section.7.6.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New 1593 Warning header fields are added after any existing Warning header sfields.1593 Warning header fields are added after any existing Warning header fields. 1594 1594 </p> 1595 1595 <p id="rfc.section.7.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from … … 2051 2051 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/307">http://tools.ietf.org/wg/httpbis/trac/ticket/307</a>>: "untangle Cache-Control ABNF" 2052 2052 </li> 2053 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/353">http://tools.ietf.org/wg/httpbis/trac/ticket/353</a>>: "Multiple values in Cache-Control header s"2053 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/353">http://tools.ietf.org/wg/httpbis/trac/ticket/353</a>>: "Multiple values in Cache-Control header fields" 2054 2054 </li> 2055 2055 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/355">http://tools.ietf.org/wg/httpbis/trac/ticket/355</a>>: "Case sensitivity of header fields in CC values" -
draft-ietf-httpbis/latest/p6-cache.xml
r1770 r1772 1133 1133 the same as that in a selected GET response (as per 1134 1134 <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update 1135 the remaining headers in the stored response using the following rules: 1135 the remaining header fields in the stored response using the following 1136 rules: 1136 1137 <list style="symbols"> 1137 1138 <t>delete any <x:ref>Warning</x:ref> header fields in the stored response … … 1924 1925 Systems that generate multiple Warning header fields are encouraged to 1925 1926 order them with this user agent behavior in mind. New Warning header fields 1926 are added after any existing Warning header sfields.1927 are added after any existing Warning header fields. 1927 1928 </t> 1928 1929 <t> … … 2672 2673 <t> 2673 2674 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/353"/>: 2674 "Multiple values in Cache-Control header s"2675 "Multiple values in Cache-Control header fields" 2675 2676 </t> 2676 2677 <t>
Note: See TracChangeset
for help on using the changeset viewer.