Changeset 2083 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 05/01/13 07:12:36 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2082 r2083 408 408 interoperable among systems with varying native encoding formats. 409 409 Representations selected or transferred via HTTP ought to be in canonical 410 form, for many of the same reasons described by MIME411 <xref target="RFC2049"/>.410 form, for many of the same reasons described by the Multipurpose Internet 411 Mail Extensions (MIME) <xref target="RFC2045"/>. 412 412 However, the performance characteristics of email deployments (i.e., store 413 413 and forward messages to peers) are significantly different from those … … 5277 5277 </reference> 5278 5278 5279 <reference anchor="RFC2076">5280 <front>5281 <title abbrev="Internet Message Headers">Common Internet Message Headers</title>5282 <author initials="J." surname="Palme" fullname="Jacob Palme">5283 <organization>Stockholm University/KTH</organization>5284 <address><email>jpalme@dsv.su.se</email></address>5285 </author>5286 <date month="February" year="1997"/>5287 </front>5288 <seriesInfo name="RFC" value="2076"/>5289 </reference>5290 5291 5279 <reference anchor='RFC2295'> 5292 5280 <front> … … 5510 5498 </reference> 5511 5499 5512 <reference anchor="RFC6151">5513 <front>5514 <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>5515 <author initials="S." surname="Turner" fullname="S. Turner"/>5516 <author initials="L." surname="Chen" fullname="L. Chen"/>5517 <date year="2011" month="March" />5518 </front>5519 <seriesInfo name="RFC" value="6151" />5520 </reference>5521 5522 5500 <reference anchor="RFC6265"> 5523 5501 <front> … … 5567 5545 <section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime"> 5568 5546 <t> 5569 HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to 5547 HTTP/1.1 uses many of the constructs defined for the 5548 Internet Message Format <xref target="RFC5322"/> and the Multipurpose 5549 Internet Mail Extensions (MIME) <xref target="RFC2045"/> to 5570 5550 allow a message body to be transmitted in an open variety of 5571 representations and with extensible mechanisms. However, RFC 20455572 discusses mail, and HTTP has a few features that are different from5573 th ose described in MIME. These differences were carefully chosen5574 to optimize performance over binary connections, to allow greater5575 freedom in the use of new media types, to make date comparisons5576 easier, and to acknowledge the practice of some early HTTP servers5577 and clients.5551 representations and with extensible header fields. However, RFC 2045 5552 is focused only on email; applications of HTTP have many characteristics 5553 that differ from email, and hence HTTP has features that differ from MIME. 5554 These differences were carefully chosen to optimize performance over binary 5555 connections, to allow greater freedom in the use of new media types, to 5556 make date comparisons easier, and to acknowledge the practice of some early 5557 HTTP servers and clients. 5578 5558 </t> 5579 5559 <t> 5580 5560 This appendix describes specific areas where HTTP differs from MIME. 5581 Proxies and gateways to strict MIME environments &SHOULD;be5561 Proxies and gateways to and from strict MIME environments need to be 5582 5562 aware of these differences and provide the appropriate conversions 5583 where necessary. Proxies and gateways from MIME environments to HTTP 5584 also need to be aware of the differences because some conversions 5585 might be required. 5563 where necessary. 5586 5564 </t> 5587 5565 … … 5590 5568 <x:anchor-alias value="MIME-Version"/> 5591 5569 <t> 5592 HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;5570 HTTP is not a MIME-compliant protocol. However, messages can 5593 5571 include a single MIME-Version header field to indicate what 5594 5572 version of the MIME protocol was used to construct the message. Use 5595 5573 of the MIME-Version header field indicates that the message is in 5596 5574 full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>). 5597 Proxies/gateways are responsible for ensuring full conformance (where5575 Senders are responsible for ensuring full conformance (where 5598 5576 possible) when exporting HTTP messages to strict MIME environments. 5599 5577 </t> 5600 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="MIME-Version"/>5601 <x:ref>MIME-Version</x:ref> = 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>5602 </artwork></figure>5603 <t>5604 MIME version "1.0" is the default for use in HTTP/1.1. However,5605 HTTP/1.1 message parsing and semantics are defined by this document5606 and not the MIME specification.5607 </t>5608 5578 </section> 5609 5579 5610 5580 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form"> 5611 5581 <t> 5612 MIME requires that an Internet mail body-part be converted to 5613 canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>. 5614 <xref target="canonicalization.and.text.defaults"/> of this document describes the forms 5615 allowed for subtypes of the "text" media type when transmitted over 5616 HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent 5617 line breaks as CRLF and forbids the use of CR or LF outside of line 5618 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a 5619 line break within text content when a message is transmitted over 5620 HTTP. 5621 </t> 5622 <t> 5623 Where it is possible, a proxy or gateway from HTTP to a strict MIME 5624 environment &SHOULD; translate all line breaks within the text media 5582 MIME requires that an Internet mail body-part be converted to canonical 5583 form prior to being transferred, as described in <xref target="RFC2049" 5584 x:fmt="of" x:sec="4"/>. <xref target="canonicalization.and.text.defaults"/> 5585 of this document describes the forms allowed for subtypes of the "text" 5586 media type when transmitted over HTTP. <xref target="RFC2046"/> requires 5587 that content with a type of "text" represent line breaks as CRLF and 5588 forbids the use of CR or LF outside of line break sequences. HTTP allows 5589 CRLF, bare CR, and bare LF to indicate a line break within text content. 5590 </t> 5591 <t> 5592 A proxy or gateway from HTTP to a strict MIME 5593 environment ought to translate all line breaks within the text media 5625 5594 types described in <xref target="canonicalization.and.text.defaults"/> 5626 5595 of this document to the RFC 2049 canonical form of CRLF. Note, however, … … 5642 5611 HTTP/1.1 uses a restricted set of date formats (&http-date;) to 5643 5612 simplify the process of date comparison. Proxies and gateways from 5644 other protocols &SHOULD;ensure that any <x:ref>Date</x:ref> header field5613 other protocols ought to ensure that any <x:ref>Date</x:ref> header field 5645 5614 present in a message conforms to one of the HTTP/1.1 formats and rewrite 5646 5615 the date if necessary. … … 5648 5617 </section> 5649 5618 5650 <section title=" Introduction of Content-Encoding" anchor="introduction.of.content-encoding">5619 <section title="Conversion of Content-Encoding" anchor="conversion.content-encoding"> 5651 5620 <t> 5652 5621 MIME does not include any concept equivalent to HTTP/1.1's 5653 5622 <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier 5654 5623 on the media type, proxies and gateways from HTTP to MIME-compliant 5655 protocols &MUST;either change the value of the <x:ref>Content-Type</x:ref>5624 protocols ought to either change the value of the <x:ref>Content-Type</x:ref> 5656 5625 header field or decode the representation before forwarding the message. 5657 5626 (Some experimental applications of Content-Type for Internet mail have used … … 5662 5631 </section> 5663 5632 5664 <section title=" No Content-Transfer-Encoding" anchor="no.content-transfer-encoding">5633 <section title="Conversion of Content-Transfer-Encoding" anchor="conversion.content-transfer-encoding"> 5665 5634 <iref item="Content-Transfer-Encoding header field" x:for-anchor=""/> 5666 5635 <t> 5667 5636 HTTP does not use the Content-Transfer-Encoding field of MIME. 5668 Proxies and gateways from MIME-compliant protocols to HTTP &MUST;5669 remove any Content-Transfer-Encoding5670 prior to delivering the response message toan HTTP client.5637 Proxies and gateways from MIME-compliant protocols to HTTP need to remove 5638 any Content-Transfer-Encoding prior to delivering the response message to 5639 an HTTP client. 5671 5640 </t> 5672 5641 <t> … … 5675 5644 and encoding for safe transport on that protocol, where "safe 5676 5645 transport" is defined by the limitations of the protocol being used. 5677 Such a proxy or gateway &SHOULD; label the data with an appropriate5678 Content-Transfer-Encoding if doing so will improve the likelihood of5679 safe transport over the destination protocol.5646 Such a proxy or gateway ought to transform and label the data with an 5647 appropriate Content-Transfer-Encoding if doing so will improve the 5648 likelihood of safe transport over the destination protocol. 5680 5649 </t> 5681 5650 </section> … … 5683 5652 <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length"> 5684 5653 <t> 5685 HTTP implementations that share code with MHTML <xref target="RFC2557"/> implementations 5686 need to be aware of MIME line length limitations. Since HTTP does not 5687 have this limitation, HTTP does not fold long lines. MHTML messages 5688 being transported by HTTP follow all conventions of MHTML, including 5689 line length limitations and folding, canonicalization, etc., since 5690 HTTP transports all message-bodies as payload (see <xref target="multipart.types"/>) and 5691 does not interpret the content or any MIME header lines that might be 5692 contained therein. 5693 </t> 5694 </section> 5695 </section> 5696 5697 <section title="Additional Features" anchor="additional.features"> 5698 <t> 5699 <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some 5700 existing HTTP implementations, but not consistently and correctly 5701 across most HTTP/1.1 applications. Implementers are advised to be 5702 aware of these features, but cannot rely upon their presence in, or 5703 interoperability with, other HTTP/1.1 applications. Some of these 5704 describe proposed experimental features, and some describe features 5705 that experimental deployment found lacking that are now addressed in 5706 the base HTTP/1.1 specification. 5707 </t> 5708 <t> 5709 A number of other header fields, such as Content-Disposition and Title, 5710 from SMTP and MIME are also often implemented (see <xref target="RFC6266"/> 5711 and <xref target="RFC2076"/>). 5712 </t> 5713 </section> 5714 5715 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 5716 <t> 5717 Request semantics embedded in a URI should be disabled when those 5718 semantics are inconsistent with the request method, since this is a 5719 common cause of interoperability failure. 5720 </t> 5721 <t> 5722 The term "representation" is introduced, replacing both "entity" and 5723 "variant." 5724 (<xref target="representations" />) 5725 </t> 5726 <t> 5727 Rules for identifying the payload of a message have been defined. 5728 (<xref target="identifying.payload" />) 5729 </t> 5730 <t> 5731 "Server-Driven" and "agent-driven" content negotiation are now called 5732 "proactive" and "reactive" content negotiation (respectively). 5733 (<xref target="content.negotiation" />) 5734 </t> 5735 <t> 5736 <x:ref>Content-Location</x:ref> no longer sets a base URI, due to poor 5737 implementation support (which was caused by too many broken servers emitting 5738 bogus Content-Location header fields, and also the potentially undesirable 5739 effect of potentially breaking relative links in content-negotiated 5740 resources). 5741 (<xref target="header.content-location"/>) 5742 </t> 5743 <t> 5744 GET requests can have a body; it just has no meaning. 5745 (<xref target="GET"/>) 5746 </t> 5747 <t> 5748 The definition of POST has been clarified. 5749 (<xref target="POST"/>) 5750 </t> 5751 <t> 5752 Servers are no longer required to handle all Content-* header fields in 5753 requests. 5754 (<xref target="PUT"/>) 5755 </t> 5756 <t> 5757 Use of <x:ref>Content-Range</x:ref> is explicitly banned on PUT requests. 5758 (<xref target="PUT"/>) 5759 </t> 5760 <t> 5761 The CONNECT method is now defined by this specification, taking over from 5762 <xref target="RFC2817"/>. 5763 (<xref target="CONNECT"/>) 5764 </t> 5765 <t> 5766 The requirements upon and semantics of CONNECT request and response bodies 5767 have been clarified. 5768 (<xref target="CONNECT"/>) 5769 </t> 5770 <t> 5771 The <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> request methods are 5772 now defined as being safe. 5773 (<xref target="OPTIONS"/> and <xref target="TRACE"/>) 5774 </t> 5775 <t> 5776 The <x:ref>Max-Forwards</x:ref> header field is now restricted to the 5777 OPTIONS and TRACE methods (previously, extension methods could have used it 5778 as well). 5779 (<xref target="header.max-forwards"/>) 5780 </t> 5781 <t> 5782 The ABNF for the "<x:ref>Expect</x:ref>" header field has been both fixed 5783 (allowing parameters for value-less expectations as well) and simplified 5784 (allowing trailing semicolons after "100-continue" when they were invalid 5785 before). 5786 (<xref target="header.expect"/>) 5787 </t> 5788 <t> 5789 Special casing for ISO-8859-1 in <x:ref>Accept-Charset</x:ref> has been 5790 removed. 5791 (<xref target="header.accept-charset"/>) 5792 </t> 5793 <t> 5794 Requirements for sending the Date header field have been clarified. 5795 (<xref target="header.date"/>) 5796 </t> 5797 <t> 5798 The <x:ref>Referer</x:ref> header field can now have a value of 5799 "about:blank" as an alternative to not sending a Referer header field. 5800 (<xref target="header.referer"/>) 5801 </t> 5802 <t> 5803 The <x:ref>201 (Created)</x:ref> status code can indicate that more than 5804 one resource has been created (as well as just one). 5805 </t> 5806 <t> 5807 The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has 5808 been broadened to include cases of payload transformations as well. 5809 (<xref target="status.203"/>) 5810 </t> 5811 <t> 5812 Redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and 5813 <x:ref>307</x:ref> no longer have normative requirements on response 5814 payloads and user interaction. 5815 (<xref target="status.3xx"/>) 5816 </t> 5817 <t> 5818 The request methods that are safe to automatically redirect is no 5819 longer a closed set; user agents are able to make that determination 5820 based upon the request method semantics. 5821 (<xref target="status.3xx"/>) 5822 </t> 5823 <t> 5824 The syntax of the <x:ref>Location</x:ref> header field has been corrected 5825 to allow URI references (including relative references and fragments), along 5826 with some clarifications as to when use of fragments would not be 5827 appropriate. 5828 (<xref target="header.location"/>) 5829 </t> 5830 <t> 5831 The 303 (See Other) status code is now cacheable, if explicit freshness 5832 information is available. 5833 (<xref target="status.303" />) 5834 </t> 5835 <t> 5836 User agents are now allowed to rewrite the method from POST to GET 5837 for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>. 5838 (Sections <xref format="counter" target="status.301"/>, 5839 <xref format="counter" target="status.302"/> and 5840 <xref format="counter" target="status.307"/>) 5841 </t> 5842 <t> 5843 The <x:ref>305 (Use Proxy)</x:ref> status code is now deprecated, because 5844 user agents did not implement it. It used to indicate that the target 5845 resource needed to be accessed through the proxy given by the 5846 <x:ref>Location</x:ref> field. The recipient was expected to repeat this 5847 single request via the proxy. 5848 (<xref target="status.305"/>) 5849 </t> 5850 <t> 5851 The <x:ref>400 (Bad Request)</x:ref> status code has been made more generic; 5852 it isn't limited to syntax errors. 5853 (<xref target="status.400"/>) 5854 </t> 5855 <t> 5856 The <x:ref>403 (Forbidden)</x:ref> status code has been clarified, 5857 especially with regards to authentication. 5858 (<xref target="status.403"/>) 5859 </t> 5860 <t> 5861 The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated 5862 from <xref target="RFC2817"/>. 5863 (<xref target="status.426"/>) 5864 </t> 5865 <t> 5866 <x:ref>Allow</x:ref> has been reclassified as a response header field, 5867 removing the option to specify it in a PUT request. 5868 (<xref target="header.allow"/>) 5869 </t> 5870 <t> 5871 Requirements relating to the content of the Allow header have been relaxed; 5872 correspondingly, clients are not required to always trust its value. 5873 (<xref target="header.allow"/>) 5874 </t> 5875 <t> 5876 The requirement to generate a <x:ref>Via</x:ref> header field has been moved 5877 from the description of the <x:ref>Server</x:ref> header field to 5878 &header-via;. 5879 (<xref target="header.server"/>) 5880 </t> 5881 <t> 5882 The contexts that charset is used in have been clarified. 5883 (<xref target="charset"/>) 5884 </t> 5885 <t> 5886 The default charset of "ISO-8859-1" for text media types has been removed; 5887 the default now is whatever the media type definition says. 5888 (<xref target="canonicalization.and.text.defaults"/>) 5889 </t> 5890 <t> 5891 Registration of Content Codings now requires IETF Review. 5892 (<xref target="content.coding.registry"/>) 5893 </t> 5894 <t> 5895 The Content-MD5 header field has been removed, because it was inconsistently 5896 implemented with respect to partial responses, and also because of known 5897 deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for 5898 details). 5899 </t> 5900 <t> 5901 This specification introduces a Method Registry. 5902 (<xref target="method.registry"/>) 5903 </t> 5904 <t> 5905 The Status Code Registry is now defined by this specification; previously, 5906 it was defined in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 5907 (<xref target="status.code.registry"/>) 5908 </t> 5909 <t> 5910 References to the "identity" transfer coding token have been removed. 5911 (<xref target="no.content-transfer-encoding"/>) 5912 </t> 5913 <t> 5914 The Content-Disposition header field is now defined by <xref 5915 target="RFC6266"/>. 5916 (<xref target="additional.features"/>) 5654 HTTP implementations that share code with MHTML <xref target="RFC2557"/> 5655 implementations need to be aware of MIME line length limitations. 5656 Since HTTP does not have this limitation, HTTP does not fold long lines. 5657 MHTML messages being transported by HTTP follow all conventions of MHTML, 5658 including line length limitations and folding, canonicalization, etc., 5659 since HTTP transfers message-bodies as payload and, aside from the 5660 "multipart/byteranges" type (&multipart-byteranges;), does not interpret 5661 the content or any MIME header lines that might be contained therein. 5662 </t> 5663 </section> 5664 </section> 5665 5666 <section title="Significant changes from RFC 2616" anchor="changes.from.rfc.2616"> 5667 <t> 5668 The primary changes in this revision have been editorial in nature: 5669 extracting the messaging syntax and partitioning HTTP semantics into 5670 separate documents for the core features, conditional requests, partial 5671 requests, caching, and authentication. The conformance language has been 5672 revised to clearly target requirements and the terminology has been 5673 improved to distinguish payload from representations and representations 5674 from resources. 5675 An algorithm has been added for determining if a payload is associated with 5676 a specific identifier (<xref target="identifying.payload" />). 5677 </t> 5678 <t> 5679 A new requirement has been added that semantics embedded in a URI 5680 should be disabled when those semantics are inconsistent with the request 5681 method, since this is a common cause of interoperability failure. 5682 </t> 5683 <t> 5684 The default charset of ISO-8859-1 for text media types has been removed; 5685 the default is now whatever the media type definition says 5686 (<xref target="canonicalization.and.text.defaults"/>). Likewise, 5687 special treatment of ISO-8859-1 has been removed from the 5688 <x:ref>Accept-Charset</x:ref> header field 5689 (<xref target="header.accept-charset"/>). 5690 </t> 5691 <t> 5692 The Content-Disposition header field has been removed since it is now 5693 defined by <xref target="RFC6266"/>. 5694 </t> 5695 <t> 5696 The definition of <x:ref>Content-Location</x:ref> has been changed to no 5697 longer affect the base URI for resolving relative URI references, due to 5698 poor implementation support and the undesirable effect of potentially 5699 breaking relative links in content-negotiated resources 5700 (<xref target="header.content-location"/>). 5701 </t> 5702 <t> 5703 The Content-MD5 header field has been removed because it was inconsistently 5704 implemented with respect to partial responses. 5705 </t> 5706 <t> 5707 To be consistent with the method-neutral parsing algorithm of 5708 <xref target="Part1"/>, the definition of GET has been relaxed so that 5709 requests can have a body, even though a body has no meaning for GET 5710 (<xref target="GET"/>). 5711 </t> 5712 <t> 5713 Servers are no longer required to handle all Content-* header fields and 5714 use of <x:ref>Content-Range</x:ref> has been explicitly banned in PUT 5715 requests (<xref target="PUT"/>). 5716 </t> 5717 <t> 5718 Definition of the CONNECT method has been moved from 5719 <xref target="RFC2817"/> to this specification (<xref target="CONNECT"/>). 5720 </t> 5721 <t> 5722 The <x:ref>OPTIONS</x:ref> (<xref target="OPTIONS"/>) and 5723 <x:ref>TRACE</x:ref> (<xref target="TRACE"/>) request methods have been 5724 defined as being safe. 5725 </t> 5726 <t> 5727 The definition of <x:ref>Expect</x:ref> has been both fixed to allow 5728 parameters for value-less expectations and simplified to allow trailing 5729 semicolons after "100-continue" (<xref target="header.expect"/>). 5730 </t> 5731 <t> 5732 The <x:ref>Max-Forwards</x:ref> header field 5733 (<xref target="header.max-forwards"/>) has been restricted to the 5734 <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> methods; previously, 5735 extension methods could have used it as well. 5736 </t> 5737 <t> 5738 The "about:blank" URI has been suggested as a value for the 5739 <x:ref>Referer</x:ref> header field when no referring URI is applicable, 5740 which distinguishes that case from others where the Referer field is 5741 not sent or has been removed (<xref target="header.referer"/>). 5742 </t> 5743 <t> 5744 The <x:ref>201 (Created)</x:ref> status description has been changed to 5745 allow for the possibility that more than one resource has been created 5746 (<xref target="status.201"/>). 5747 </t> 5748 <t> 5749 The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has 5750 been broadened to include cases of payload transformations as well 5751 (<xref target="status.203"/>). 5752 </t> 5753 <t> 5754 The redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and 5755 <x:ref>307</x:ref> no longer have normative requirements on response 5756 payloads and user interaction (<xref target="status.3xx"/>). 5757 </t> 5758 <t> 5759 The request methods that are safe to automatically redirect is no 5760 longer a closed set; user agents are able to make that determination 5761 based upon the request method semantics (<xref target="status.3xx"/>). 5762 </t> 5763 <t> 5764 The description of 303 (See Other) status code has been changed to allow 5765 it to be cached if explicit freshness information is given, and a specific 5766 definition has been added for a 303 response to GET 5767 (<xref target="status.303"/>). 5768 </t> 5769 <t> 5770 The status codes <x:ref>301</x:ref> and <x:ref>302</x:ref> 5771 (sections <xref format="counter" target="status.301"/> and 5772 <xref format="counter" target="status.302"/>) have been changed to allow 5773 user agents to rewrite the method from POST to GET. 5774 </t> 5775 <t> 5776 The <x:ref>305 (Use Proxy)</x:ref> status code has been deprecated due to 5777 security concerns regarding in-band configuration of a proxy 5778 (<xref target="status.305"/>). 5779 </t> 5780 <t> 5781 The <x:ref>400 (Bad Request)</x:ref> status code has been relaxed so that 5782 it isn't limited to syntax errors (<xref target="status.400"/>). 5783 </t> 5784 <t> 5785 The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated 5786 from <xref target="RFC2817"/> (<xref target="status.426"/>). 5787 </t> 5788 <t> 5789 <x:ref>Allow</x:ref> has been reclassified as a response header field, 5790 removing the option to specify it in a PUT request. 5791 Requirements relating to the content of Allow have been relaxed; 5792 correspondingly, clients are not required to always trust its value 5793 (<xref target="header.allow"/>). 5794 </t> 5795 <t> 5796 The target of requirements on HTTP-date and the Date header field have been 5797 reduced to those systems generating the date, rather than all systems 5798 sending a date (<xref target="origination.date"/>). 5799 </t> 5800 <t> 5801 The syntax of the <x:ref>Location</x:ref> header field has been changed 5802 to allow all URI references, including relative references and fragments, 5803 along with some clarifications as to when use of fragments would not be 5804 appropriate (<xref target="header.location"/>). 5805 </t> 5806 <t> 5807 A Method Registry has been defined (<xref target="method.registry"/>). 5808 </t> 5809 <t> 5810 The Status Code Registry (<xref target="status.code.registry"/>) has been 5811 redefined by this specification; previously, it was defined in 5812 <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 5813 </t> 5814 <t> 5815 Registration of Content Codings has been changed to require IETF Review 5816 (<xref target="content.coding.registry"/>). 5917 5817 </t> 5918 5818 </section> … … 6001 5901 <x:ref>Location</x:ref> = URI-reference 6002 5902 6003 <x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT6004 5903 <x:ref>Max-Forwards</x:ref> = 1*DIGIT 6005 5904
Note: See TracChangeset
for help on using the changeset viewer.