One document matched: draft-reschke-http-status-308-04.xml


<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-reschke-http-status-308-04" category="exp">

  

	<front>
  <title abbrev="HTTP Status Code 308">The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>	
      <uri>http://greenbytes.de/tech/webdav/</uri>	
    </address>
  </author>

  <date month="February" year="2012" day="8"/>
  
  <keyword>HTTP</keyword>
  <keyword>redirect</keyword>
  <keyword>status code</keyword>

  <abstract>
    <t>
      This document specifies the additional HyperText Transfer Protocol (HTTP)
      Status Code 308 (Permanent Redirect). 
    </t>
  </abstract>
  

  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPbis Working Group, comments should be sent to the 
      Hypertext Transfer Protocol (HTTP) mailing list at <eref target="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</eref>,
      which may be joined by sending a message with subject 
      "subscribe" to <eref target="mailto:ietf-http-wg-request@w3.org?subject=subscribe">ietf-http-wg-request@w3.org</eref>.
    </t>
    <t>
      Discussions of the HTTPbis Working Group are archived at
      <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.               
    </t> 
    <t>
      XML versions, latest edits, and the issues list for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-http-status-308"/>.
    </t>
    <t>
      Test cases related to redirection in general and the status code 308
      in particular can be found at <eref target="http://greenbytes.de/tech/tc/httpredirects/#l-308"/>.
    </t>
  </note>


  </front>

  <middle>






<section title="Introduction" anchor="introduction">
<t>
  HTTP defines a set of status codes for the purpose of redirecting a request
  to a different URI (<xref target="RFC3986"/>). The history of these status codes is summarized in
  Section 7.3 of <xref target="draft-ietf-httpbis-p2-semantics"/>, which
  also classifies the existing status codes into four categories.
</t>
<t>
  The first of these categories contains the status codes 301 (Moved Permanently),
  302 (Found), and 307 (Temporary Redirect), which can be classified as below: 
</t>
<texttable align="left" suppress-title="true">
<ttcol/>
<ttcol>Permanent</ttcol>
<ttcol>Temporary</ttcol>
<c>Allows changing the request method from POST to GET</c>
<c>301</c>
<c>302</c>
<c>Does not allow changing the request method from POST to GET</c>
<c>-</c>
<c>307</c>
</texttable>
<t>
  Section 7.3.8 of <xref target="draft-ietf-httpbis-p2-semantics"/>
  states that HTTP does not define a permanent variant of status code 307;
  this specification adds 
  the status code 308, defining this missing variant (<xref target="status.308"/>).
</t>
</section>  

<section title="Notational Conventions" anchor="notational.conventions">
<t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>

<section title="308 Permanent Redirect" anchor="status.308">
<t>
  The target resource has been assigned a new permanent URI and any future
  references to this resource SHOULD use one of the returned URIs. Clients
  with link editing capabilities ought to automatically re-link references to
  the effective request URI (Section 4.3 of <xref target="draft-ietf-httpbis-p1-messaging"/>)
  to one or more of the new references returned by the server, where possible.
</t>
<t>
  The permanent URI SHOULD be given by the Location field in the response
  (<xref target="draft-ietf-httpbis-p2-semantics"/>, Section 9.5).
  A response payload can contain a short hypertext note with a hyperlink
  to the new URI(s).
</t>


</section>

<section title="Deployment Considerations" anchor="deployment.considerations">
<t>
  Section 4 of <xref target="draft-ietf-httpbis-p2-semantics"/>
  requires recipients to treat unknown 3xx status codes the same way as
  status code 300 Multiple Choices (<xref target="draft-ietf-httpbis-p2-semantics"/>, Section 7.3.1).
  Thus, servers will not be able to rely on automatic redirection happening
  similar to status codes 301, 302, or 307.
</t>
<t>
  Therefore, initial use of status code 308 will be restricted to cases where
  the server has sufficient confidence in the clients understanding the new 
  code, or when a fallback to the semantics of status code 300 is not problematic.
</t>
<t>
  Note that existing user agents will emulate a refresh when encountering
  an HTML <meta> refresh directive. This can be used as another
  fallback.
</t>
<figure>
  <preamble>For example:</preamble>
  <artwork type="message/http; msgtype="response""><![CDATA[
HTTP/1.1 308 Permanent Redirect
Content-Type: text/html; charset=UTF-8
Location: http://example.com/new
Content-Length: 443

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
                      "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
      <title>Permanent Redirect</title>
      <meta http-equiv="refresh" 
            content="0; url=http://example.com/new">
   </head>
   <body>
      <p>
         The document has been moved to
         <a href="http://example.com/new">http://example.com/new</a>.
      </p>
   </body>
</html>
]]></artwork>
</figure>

</section>

<section title="Security Considerations" anchor="security.considerations">
<t>
  All security considerations that apply to HTTP redirects apply to the
  308 status code as well (see Section 11 of <xref target="draft-ietf-httpbis-p2-semantics"/>).
</t>
</section>  

<section title="IANA Considerations" anchor="iana.considerations">
<t>
   The registration below shall be added to the HTTP Status Code Registry
   (defined in Section 4.2 of <xref target="draft-ietf-httpbis-p2-semantics"/>
   and located at <eref target="http://www.iana.org/assignments/http-status-codes"/>):
</t>
<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
   <ttcol>Value</ttcol>
   <ttcol>Description</ttcol>
   <ttcol>Reference</ttcol>
   <c>308</c>
   <c>Permanent Redirect</c>
   <c>
      <xref target="status.308"/>
   </c>
</texttable>
</section>

<section title="Acknowledgements" anchor="acknowledgements">
<t>
  The definition for the new status code 308 re-uses text from
  the HTTP/1.1 definitions of status codes 301 and 307.
</t>
<t>
  Furthermore, thanks to Bjoern Hoehrmann and Subramanian Moonesamy for feedback on this document.
</t>
</section>
  </middle>
  <back>
  
<references title="Normative References">

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner">
      <organization>Harvard University</organization>
      <address><email>sob@harvard.edu</email></address>
    </author>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>

<reference anchor="RFC3986">
 <front>
  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
    <address>
       <email>timbl@w3.org</email>
       <uri>http://www.w3.org/People/Berners-Lee/</uri>
    </address>
  </author>
  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
    <organization abbrev="Day Software">Day Software</organization>
    <address>
      <email>fielding@gbiv.com</email>
      <uri>http://roy.gbiv.com/</uri>
    </address>
  </author>
  <author initials="L." surname="Masinter" fullname="Larry Masinter">
    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
    <address>
      <email>LMM@acm.org</email>
      <uri>http://larry.masinter.net/</uri>
    </address>
  </author>
  <date month="January" year="2005"/>
 </front>
 <seriesInfo name="STD" value="66"/>
 <seriesInfo name="RFC" value="3986"/>
</reference>

<reference anchor="draft-ietf-httpbis-p1-messaging">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
      <address><email>jg@freedesktop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="January" year="2012"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-18"/>
  
</reference>

<reference anchor="draft-ietf-httpbis-p2-semantics">
  <front>
    <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
      <address><email>fielding@gbiv.com</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="Jim Gettys">
      <organization>One Laptop per Child</organization>
      <address><email>jg@laptop.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
      <organization abbrev="HP">Hewlett-Packard Company</organization>
      <address><email>JeffMogul@acm.org</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>henrikn@microsoft.com</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="Larry Masinter">
      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
      <address><email>LMM@acm.org</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="Paul J. Leach">
      <organization abbrev="Microsoft">Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
      <organization abbrev="W3C">World Wide Web Consortium</organization>
      <address><email>ylafon@w3.org</email></address>
    </author>
    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
      <organization abbrev="greenbytes">greenbytes GmbH</organization>
      <address><email>julian.reschke@greenbytes.de</email></address>
    </author>
    <date month="January" year="2012"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-18"/>
  
</reference>
  
</references>

<section title="Implementations (to be removed by RFC Editor before publication)" anchor="implementations">
<t>
  Chrome: Feature requested in Chromium Issue 109012 (<eref target="http://code.google.com/p/chromium/issues/detail?id=109012"/>).
</t>
<t>
  Curl (the library): no change was needed (test case: <eref target="https://github.com/bagder/curl/blob/master/tests/data/test1325"/>).
</t>
<t>
  Firefox: Feature requested in Bugzilla bug 714302 (<eref target="https://bugzilla.mozilla.org/show_bug.cgi?id=714302"/>), patch available.
</t>
<t>
  Safari: Safari automatically redirects 3xx status codes when a Location header field is present, thus no change is needed.
</t>
</section>

<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
<section title="Since draft-reschke-http-status-308-00">
<t>
  Updated HTTPbis reference. Added <xref target="implementations"/>.
  Added and resolved issue "refresh".
</t>
</section>

<section title="Since draft-reschke-http-status-308-01">
<t>
  Added URI spec reference.
</t>
</section>

<section title="Since draft-reschke-http-status-308-02">
<t>
  Tune HTML example. Expand "Implementations" section.
  Added and resolved issue "respformat"
  (align with new proposed text for 307 in HTTPbis P2).
</t>
</section>


<section title="Since draft-reschke-http-status-308-03">
<t>
  Added and resolved issue "uaconfirm".
</t>
</section>

</section>
  <section title="Resolved issues (to be removed by RFC Editor before publication)"><t>
          Issues that were either rejected or resolved in this version of this
          document.
        </t><section title="uaconfirm"><t>
        In Section 3:
      </t><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2012-02-03): 
    The requirement about UA prompts is subject to an open HTTPbis
    ticket (http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238), and the text should be aligned with whatever the resolution is.
  </t><t>Resolution (2012-02-08): 
    Align with the proposed fix for the HTTPbis issue by removing the text
    from the status code definition (in HTTPbis, a relaxed variant is being
    added to the description of 3xx in general).
  </t></section></section><section title="Open issues (to be removed by RFC Editor prior to publication)"><section title="edit"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2011-04-15): 
    Umbrella issue for editorial fixes/enhancements.
  </t></section></section></back>

</rfc>

PAFTECH AB 2003-20262026-04-24 04:07:57