Ignore:
Timestamp:
Jan 4, 2013, 11:12:36 PM (7 years ago)
Author:
fielding@…
Message:

Requirements are not allowed in appendices. They have been changed to prose.
Changes from RFC2616 have been rewritten for consistency and to remove changes
that are only editorial. Addresses #419

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2082 r2083  
    408408   interoperable among systems with varying native encoding formats.
    409409   Representations selected or transferred via HTTP ought to be in canonical
    410    form, for many of the same reasons described by MIME
    411    <xref target="RFC2049"/>.
     410   form, for many of the same reasons described by the Multipurpose Internet
     411   Mail Extensions (MIME) <xref target="RFC2045"/>.
    412412   However, the performance characteristics of email deployments (i.e., store
    413413   and forward messages to peers) are significantly different from those
    … …  
    52775277</reference>
    52785278
    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 
    52915279<reference anchor='RFC2295'>
    52925280  <front>
    … …  
    55105498</reference>
    55115499
    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 
    55225500<reference anchor="RFC6265">
    55235501  <front>
    … …  
    55675545<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
    55685546<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
    55705550   allow a message body to be transmitted in an open variety of
    5571    representations and with extensible mechanisms. However, RFC 2045
    5572    discusses mail, and HTTP has a few features that are different from
    5573    those described in MIME. These differences were carefully chosen
    5574    to optimize performance over binary connections, to allow greater
    5575    freedom in the use of new media types, to make date comparisons
    5576    easier, and to acknowledge the practice of some early HTTP servers
    5577    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.
    55785558</t>
    55795559<t>
    55805560   This appendix describes specific areas where HTTP differs from MIME.
    5581    Proxies and gateways to strict MIME environments &SHOULD; be
     5561   Proxies and gateways to and from strict MIME environments need to be
    55825562   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.
    55865564</t>
    55875565
    … …  
    55905568  <x:anchor-alias value="MIME-Version"/>
    55915569<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
    55935571   include a single MIME-Version header field to indicate what
    55945572   version of the MIME protocol was used to construct the message. Use
    55955573   of the MIME-Version header field indicates that the message is in
    55965574   full conformance with the MIME protocol (as defined in <xref target="RFC2045"/>).
    5597    Proxies/gateways are responsible for ensuring full conformance (where
     5575   Senders are responsible for ensuring full conformance (where
    55985576   possible) when exporting HTTP messages to strict MIME environments.
    55995577</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 document
    5606    and not the MIME specification.
    5607 </t>
    56085578</section>
    56095579
    56105580<section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
    56115581<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
    56255594   types described in <xref target="canonicalization.and.text.defaults"/>
    56265595   of this document to the RFC 2049 canonical form of CRLF. Note, however,
    … …  
    56425611   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
    56435612   simplify the process of date comparison. Proxies and gateways from
    5644    other protocols &SHOULD; ensure that any <x:ref>Date</x:ref> header field
     5613   other protocols ought to ensure that any <x:ref>Date</x:ref> header field
    56455614   present in a message conforms to one of the HTTP/1.1 formats and rewrite
    56465615   the date if necessary.
    … …  
    56485617</section>
    56495618
    5650 <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding">
     5619<section title="Conversion of Content-Encoding" anchor="conversion.content-encoding">
    56515620<t>
    56525621   MIME does not include any concept equivalent to HTTP/1.1's
    56535622   <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier
    56545623   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>
    56565625   header field or decode the representation before forwarding the message.
    56575626   (Some experimental applications of Content-Type for Internet mail have used
    … …  
    56625631</section>
    56635632
    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">
    56655634  <iref item="Content-Transfer-Encoding header field" x:for-anchor=""/>
    56665635<t>
    56675636   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-Encoding
    5670    prior to delivering the response message to an 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.
    56715640</t>
    56725641<t>
    … …  
    56755644   and encoding for safe transport on that protocol, where "safe
    56765645   transport" is defined by the limitations of the protocol being used.
    5677    Such a proxy or gateway &SHOULD; label the data with an appropriate
    5678    Content-Transfer-Encoding if doing so will improve the likelihood of
    5679    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.
    56805649</t>
    56815650</section>
    … …  
    56835652<section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
    56845653<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"/>).
    59175817</t>
    59185818</section>
    … …  
    60015901<x:ref>Location</x:ref> = URI-reference
    60025902
    6003 <x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT
    60045903<x:ref>Max-Forwards</x:ref> = 1*DIGIT
    60055904
Note: See TracChangeset for help on using the changeset viewer.