Changeset 911 for draft-ietf-httpbis
- Timestamp:
- 24/07/10 09:23:44 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r901 r911 4884 4884 </section> 4885 4885 4886 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">4887 <t>4888 This specification has been carefully audited to correct and4889 disambiguate key word usage; RFC 2068 had many problems in respect to4890 the conventions laid out in <xref target="RFC2119"/>.4891 </t>4892 <t>4893 Transfer-coding and message lengths all interact in ways that4894 required fixing exactly when chunked encoding is used (to allow for4895 transfer encoding that might not be self delimiting); it was important4896 to straighten out exactly how message lengths are computed. (Sections4897 <xref target="transfer.codings" format="counter"/>, <xref target="message.body" format="counter"/>,4898 <xref target="header.content-length" format="counter"/>,4899 see also <xref target="Part5"/>)4900 </t>4901 <t>4902 The use and interpretation of HTTP version numbers has been clarified4903 by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol4904 version they support to deal with problems discovered in HTTP/1.04905 implementations (<xref target="http.version"/>)4906 </t>4907 <t>4908 Quality Values of zero should indicate that "I don't want something"4909 to allow clients to refuse a representation. (<xref target="quality.values"/>)4910 </t>4911 <t>4912 Transfer-coding had significant problems, particularly with4913 interactions with chunked encoding. The solution is that transfer-codings4914 become as full fledged as content-codings. This involves4915 adding an IANA registry for transfer-codings (separate from content4916 codings), a new header field (TE) and enabling trailer headers in the4917 future. Transfer encoding is a major performance benefit, so it was4918 worth fixing <xref target="Nie1997"/>. TE also solves another, obscure, downward4919 interoperability problem that could have occurred due to interactions4920 between authentication trailers, chunked encoding and HTTP/1.04921 clients.(Section4922 <xref target="transfer.codings" format="counter"/>,4923 <xref target="chunked.encoding" format="counter"/>,4924 <xref target="non-modifiable.headers" format="counter"/>,4925 and <xref target="header.te" format="counter"/>)4926 </t>4927 <t>4928 Proxies should be able to add Content-Length when appropriate.4929 (<xref target="non-modifiable.headers"/>)4930 </t>4931 </section>4932 4933 4886 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 4934 4887 <t> … … 5716 5669 "HTTP(s) URI scheme definitions" 5717 5670 </t> 5671 <t> 5672 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 5673 "consider removing the 'changes from 2068' sections" 5674 </t> 5718 5675 </list> 5719 5676 </t> -
draft-ietf-httpbis/latest/p2-semantics.xml
r910 r911 3268 3268 </references> 3269 3269 3270 <section title="Compatibility with Previous Versions" anchor="compatibility">3271 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">3272 <t>3273 Clarified which error code should be used for inbound server failures3274 (e.g., DNS failures). (<xref target="status.504"/>).3275 </t>3276 <t>3277 201 (Created) had a race that required an ETag be sent when a resource is3278 first created. (<xref target="status.201"/>).3279 </t>3280 <t>3281 303 (See Also) and 307 (Temporary Redirect) added to address user agent3282 failure to implement status code 302 properly.3283 (Section <xref target="status.303" format="counter"/> and <xref target="status.307" format="counter"/>)3284 </t>3285 <t>3286 Rewrite of message transmission requirements to make it much harder3287 for implementors to get it wrong, as the consequences of errors here3288 can have significant impact on the Internet, and to deal with the3289 following problems:3290 <list style="numbers">3291 <t>Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where3292 this was incorrectly placing a requirement on the behavior of3293 an implementation of a future version of HTTP/1.x</t>3294 3295 <t>Made it clear that user-agents should retry requests, not3296 "clients" in general.</t>3297 3298 <t>Converted requirements for clients to ignore unexpected 1003299 (Continue) responses, and for proxies to forward 100 responses,3300 into a general requirement for 1xx responses.</t>3301 3302 <t>Modified some TCP-specific language, to make it clearer that3303 non-TCP transports are possible for HTTP.</t>3304 3305 <t>Require that the origin server &MUST-NOT; wait for the request3306 body before it sends a required 100 (Continue) response.</t>3307 3308 <t>Allow, rather than require, a server to omit 100 (Continue) if3309 it has already seen some of the request body.</t>3310 3311 <t>Allow servers to defend against denial-of-service attacks and3312 broken clients.</t>3313 </list>3314 </t>3315 <t>3316 This change adds the Expect header and 417 status code.3317 </t>3318 <t>3319 Clean up confusion between 403 and 404 responses. (Section <xref target="status.403" format="counter"/>,3320 <xref target="status.404" format="counter"/>, and <xref target="status.410" format="counter"/>)3321 </t>3322 <t>3323 The PATCH<iref item="PATCH method" primary="true"/><iref item="Methods" subitem="PATCH" primary="true"/>, LINK<iref item="LINK method" primary="true"/><iref item="Methods" subitem="LINK" primary="true"/>, UNLINK<iref item="UNLINK method" primary="true"/><iref item="Methods" subitem="UNLINK" primary="true"/> methods were defined but not commonly3324 implemented in previous versions of this specification. See <xref target="RFC2068" x:fmt="of" x:sec="19.6.1"/>.3325 </t>3326 </section>3327 3328 3270 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 3329 3271 <t> … … 3376 3318 (<xref target="header.server"/>) 3377 3319 </t> 3378 </section>3379 3380 3320 </section> 3381 3321 … … 3859 3799 "Status codes and caching" 3860 3800 </t> 3801 <t> 3802 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 3803 "consider removing the 'changes from 2068' sections" 3804 </t> 3861 3805 </list> 3862 3806 </t> -
draft-ietf-httpbis/latest/p3-payload.xml
r908 r911 2739 2739 </section> 2740 2740 2741 <section title="Compatibility with Previous Versions" anchor="compatibility">2742 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">2743 <t>2744 Charset wildcarding is introduced to avoid explosion of character set2745 names in accept headers. (<xref target="header.accept-charset"/>)2746 </t>2747 <t>2748 Content-Base was deleted from the specification: it was not2749 implemented widely, and there is no simple, safe way to introduce it2750 without a robust extension mechanism. In addition, it is used in a2751 similar, but not identical fashion in MHTML <xref target="RFC2557"/>.2752 </t>2753 <t>2754 A content-coding of "identity" was introduced, to solve problems2755 discovered in caching. (<xref target="content.codings"/>)2756 </t>2757 <t>2758 The Alternates<iref item="Alternates header" primary="true"/><iref item="Headers" subitem="Alternate" primary="true"/>, Content-Version<iref item="Content-Version header" primary="true"/><iref item="Headers" subitem="Content-Version" primary="true"/>, Derived-From<iref item="Derived-From header" primary="true"/><iref item="Headers" subitem="Derived-From" primary="true"/>, Link<iref item="Link header" primary="true"/><iref item="Headers" subitem="Link" primary="true"/>, URI<iref item="URI header" primary="true"/><iref item="Headers" subitem="URI" primary="true"/>, Public<iref item="Public header" primary="true"/><iref item="Headers" subitem="Public" primary="true"/> and2759 Content-Base<iref item="Content-Base header" primary="true"/><iref item="Headers" subitem="Content-Base" primary="true"/> header fields were defined in previous versions of this2760 specification, but not commonly implemented. See <xref target="RFC2068" x:fmt="of" x:sec="19.6.2"/>.2761 </t>2762 </section>2763 2764 2741 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 2765 2742 <t> … … 2778 2755 (<xref target="no.content-transfer-encoding"/>) 2779 2756 </t> 2780 </section>2781 2782 2757 </section> 2783 2758 … … 3215 3190 "'requested resource' in content-encoding definition" 3216 3191 </t> 3192 <t> 3193 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 3194 "consider removing the 'changes from 2068' sections" 3195 </t> 3217 3196 </list> 3218 3197 </t> -
draft-ietf-httpbis/latest/p4-conditional.xml
r908 r911 1486 1486 </references> 1487 1487 1488 <section title="Compatibility with Previous Versions" anchor="compatibility">1489 1490 1488 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1491 1489 <t> … … 1494 1492 <xref target="header.if-none-match" format="counter"/>). 1495 1493 </t> 1496 </section>1497 1498 1494 </section> 1499 1495 … … 1706 1702 "Clarify entity / representation / variant terminology" 1707 1703 </t> 1704 <t> 1705 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 1706 "consider removing the 'changes from 2068' sections" 1707 </t> 1708 1708 </list> 1709 1709 </t> -
draft-ietf-httpbis/latest/p5-range.xml
r908 r911 598 598 ranges), these are transmitted as a multipart message. The multipart 599 599 media type used for this purpose is "multipart/byteranges" as defined 600 in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue.600 in <xref target="internet.media.type.multipart.byteranges"/>. 601 601 </t> 602 602 <t> … … 1302 1302 1303 1303 <section title="Compatibility with Previous Versions" anchor="compatibility"> 1304 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">1305 <t>1306 Transfer-coding and message lengths all interact in ways that1307 required fixing exactly when chunked encoding is used (to allow for1308 transfer encoding that may not be self delimiting); it was important1309 to straighten out exactly how message lengths are computed.1310 (<xref target="header.content-range"/>,1311 see also <xref target="Part1"/>)1312 </t>1313 <t>1314 There are situations where a server (especially a proxy) does not1315 know the full length of a response but is capable of serving a1316 byterange request. We therefore need a mechanism to allow byteranges1317 with a content-range not indicating the full length of the message.1318 (<xref target="header.content-range"/>)1319 </t>1320 <t>1321 Range request responses would become very verbose if all meta-data1322 were always returned; by allowing the server to only send needed1323 headers in a 206 response, this problem can be avoided.1324 (Section <xref target="status.206" format="counter"/>1325 and <xref target="header.if-range" format="counter"/>)1326 </t>1327 <t>1328 Fix problem with unsatisfiable range requests; there are two cases:1329 syntactic problems, and range doesn't exist in the document. The 4161330 status code was needed to resolve this ambiguity needed to indicate1331 an error for a byte range request that falls outside of the actual1332 contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>)1333 </t>1334 </section>1335 1336 1304 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1337 1305 <t> … … 1594 1562 "Clarify entity / representation / variant terminology" 1595 1563 </t> 1564 <t> 1565 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 1566 "Clarify entity / representation / variant terminology" 1567 </t> 1568 <t> 1569 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 1570 "consider removing the 'changes from 2068' sections" 1571 </t> 1596 1572 </list> 1597 1573 </t> -
draft-ietf-httpbis/latest/p6-cache.xml
r908 r911 2138 2138 </references> 2139 2139 2140 <section anchor="compatibility" title="Compatibility with Previous Versions">2141 2142 <section anchor="changes.from.rfc.2068" title="Changes from RFC 2068">2143 <t>2144 A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add2145 this missing case.2146 (Sections <xref format="counter" target="response.cacheability" />, <xref format="counter" target="header.cache-control" />).2147 </t>2148 <t>2149 Range request responses would become very verbose if all meta-data were always returned;2150 by allowing the server to only send needed headers in a 206 response, this problem can be2151 avoided.2152 (<xref target="combining.headers" />)2153 </t>2154 <t>2155 The Cache-Control: max-age directive was not properly defined for responses.2156 (<xref target="cache-response-directive"/>)2157 </t>2158 <t>2159 Warnings could be cached incorrectly, or not updated appropriately. (Section <xref2160 format="counter" target="expiration.model" />, <xref format="counter"2161 target="combining.headers" />, <xref format="counter" target="header.cache-control" />,2162 and <xref format="counter" target="header.warning" />) Warning also needed to be a general2163 header, as PUT or other methods may have need for it in requests.2164 </t>2165 </section>2166 2167 2140 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616"> 2168 2141 <t> … … 2185 2158 </t> 2186 2159 </section> 2187 2188 </section>2189 2160 2190 2161 <?BEGININC p6-cache.abnf-appendix ?> … … 2507 2478 <section title="Since draft-ietf-httpbis-p6-cache-10" anchor="changes.since.10"> 2508 2479 <t> 2509 None yet. 2480 Closed issues: 2481 <list style="symbols"> 2482 <t> 2483 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 2484 "consider removing the 'changes from 2068' sections" 2485 </t> 2486 </list> 2510 2487 </t> 2511 2488 </section> -
draft-ietf-httpbis/latest/p7-auth.xml
r874 r911 831 831 </references> 832 832 833 834 <section title="Compatibility with Previous Versions" anchor="compatibility"> 835 833 <!-- re-add this once we have changes 836 834 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 837 835 </section> 838 839 </section> 840 836 --> 837 841 838 <?BEGININC p7-auth.abnf-appendix ?> 842 839 <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
Note: See TracChangeset
for help on using the changeset viewer.