You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/11/12 08:22:43 UTC
svn commit: r594034 [3/5] - /labs/webarch/trunk/http/draft-fielding-http/
Modified: labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml?rev=594034&r1=594033&r2=594034&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Sun Nov 11 23:22:40 2007
@@ -32,7 +32,8 @@
<!ENTITY status-414 "[Part 2]">
]>
<?rfc toc="yes" ?>
-<?rfc symrefs="no" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
@@ -40,7 +41,7 @@
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<rfc obsoletes="2068, 2616, 2617" category="std"
- ipr="full3667" docName="draft-fielding-http-p1-messaging-00"
+ ipr="full3978" docName="draft-fielding-http-p1-messaging-00"
xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
<front>
@@ -2648,6 +2649,12 @@
</t>
</section>
+</section>
+
+<section title="IANA Considerations" anchor="IANA.considerations">
+<t>
+ TBD.
+</t>
</section>
<section title="Security Considerations" anchor="security.considerations">
Modified: labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html?rev=594034&r1=594033&r2=594034&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html Sun Nov 11 23:22:40 2007
@@ -341,9 +341,10 @@
<link rel="Chapter" title="8 Method Definitions" href="#rfc.section.8">
<link rel="Chapter" title="9 Status Code Definitions" href="#rfc.section.9">
<link rel="Chapter" title="10 Header Field Definitions" href="#rfc.section.10">
- <link rel="Chapter" title="11 Security Considerations" href="#rfc.section.11">
- <link rel="Chapter" title="12 Acknowledgments" href="#rfc.section.12">
- <link rel="Chapter" href="#rfc.section.13" title="13 References">
+ <link rel="Chapter" title="11 IANA Considerations" href="#rfc.section.11">
+ <link rel="Chapter" title="12 Security Considerations" href="#rfc.section.12">
+ <link rel="Chapter" title="13 Acknowledgments" href="#rfc.section.13">
+ <link rel="Chapter" href="#rfc.section.14" title="14 References">
<link rel="Appendix" title="A Changes from RFC 2068" href="#rfc.section.A">
<meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.349, 2007/11/09 13:18:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
@@ -428,9 +429,9 @@
</table>
<p class="title">HTTP/1.1, part 2: Message Semantics<br><span class="filename">draft-fielding-http-p2-semantics-00</span></p>
<h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
- <p>This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft,
- each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed,
- and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
+ <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she
+ is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section
+ 6 of BCP 79.
</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as Internet-Drafts.
@@ -550,14 +551,15 @@
<li class="tocline1">10.9 <a href="#header.user-agent">User-Agent</a></li>
</ul>
</li>
- <li class="tocline0">11. <a href="#security.considerations">Security Considerations</a><ul class="toc">
- <li class="tocline1">11.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
- <li class="tocline1">11.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
- <li class="tocline1">11.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
+ <li class="tocline0">11. <a href="#IANA.considerations">IANA Considerations</a></li>
+ <li class="tocline0">12. <a href="#security.considerations">Security Considerations</a><ul class="toc">
+ <li class="tocline1">12.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
+ <li class="tocline1">12.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
+ <li class="tocline1">12.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
</ul>
</li>
- <li class="tocline0">12. <a href="#ack">Acknowledgments</a></li>
- <li class="tocline0">13. <a href="#rfc.references">References</a></li>
+ <li class="tocline0">13. <a href="#ack">Acknowledgments</a></li>
+ <li class="tocline0">14. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0">A. <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li>
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
@@ -794,7 +796,7 @@
held by the client.
</p>
<p id="rfc.section.8.3.p.4">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in [Part 6].</p>
- <p id="rfc.section.8.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 11.2</a> for security considerations when used for forms.
+ <p id="rfc.section.8.3.p.5">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations when used for forms.
</p>
<div id="rfc.iref.h.1"></div>
<div id="rfc.iref.m.3"></div>
@@ -833,7 +835,7 @@
</p>
<p id="rfc.section.8.5.p.6">POST requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in [message.transmission.requirements].
</p>
- <p id="rfc.section.8.5.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 11.2</a> for security considerations.
+ <p id="rfc.section.8.5.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations.
</p>
<div id="rfc.iref.p.2"></div>
<div id="rfc.iref.m.5"></div>
@@ -893,7 +895,7 @@
<div id="rfc.iref.m.8"></div>
<h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2>
<p id="rfc.section.8.9.p.1">This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g.
- SSL tunneling <a href="#Luo1998" id="rfc.xref.Luo1998.1"><cite title="Tunneling TCP based protocols through Web proxy servers">[5]</cite></a>).
+ SSL tunneling <a href="#Luo1998" id="rfc.xref.Luo1998.1"><cite title="Tunneling TCP based protocols through Web proxy servers">[Luo1998]</cite></a>).
</p>
<h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>
<p id="rfc.section.9.p.1">Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required
@@ -1149,7 +1151,7 @@
<p id="rfc.section.9.4.2.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field ([Part 7]) containing a challenge applicable to the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field ([Part 7]). If the request already included Authorization credentials,
then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the
same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP
- access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[4]</cite></a>.
+ access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
</p>
<div id="rfc.iref.44"></div>
<div id="rfc.iref.s.20"></div>
@@ -1199,7 +1201,7 @@
<p id="rfc.section.9.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The
proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field ([Part 7]) containing a challenge applicable to the proxy for the requested resource.
The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field ([Part 7]). HTTP access authentication is explained in
- "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[4]</cite></a>.
+ "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
</p>
<div id="rfc.iref.50"></div>
<div id="rfc.iref.s.26"></div>
@@ -1377,7 +1379,7 @@
<div id="rfc.iref.f.1"></div>
<div id="rfc.iref.h.4"></div>
<h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.from" href="#header.from">From</a></h2>
- <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[2]</cite></a> as updated by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[1]</cite></a>:
+ <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
</p>
<div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> From = "From" ":" mailbox
</pre><p id="rfc.section.10.3.p.3">An example is:</p>
@@ -1435,7 +1437,7 @@
<div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI )
</pre><p id="rfc.section.10.6.p.3">Example:</p>
<div id="rfc.figure.u.16"></div><pre class="text"> Referer: http://www.w3.org/hypertext/DataSources/Overview.html
-</pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 11.2</a> for security considerations.
+</pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations.
</p>
<div id="rfc.iref.r.2"></div>
<div id="rfc.iref.h.8"></div>
@@ -1479,82 +1481,84 @@
<div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span> User-Agent = "User-Agent" ":" 1*( product | comment )
</pre><p id="rfc.section.10.9.p.3">Example:</p>
<div id="rfc.figure.u.22"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
-</pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
- <p id="rfc.section.11.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
+</pre><h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
+ <p id="rfc.section.11.p.1">TBD.</p>
+ <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
+ <p id="rfc.section.12.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
make some suggestions for reducing security risks.
</p>
- <h2 id="rfc.section.11.1"><a href="#rfc.section.11.1">11.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
- <p id="rfc.section.11.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
+ <h2 id="rfc.section.12.1"><a href="#rfc.section.12.1">12.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
+ <p id="rfc.section.12.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any
a priori method of determining the sensitivity of any particular piece of information within the context of any given request.
Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth
special mention in this context: Server, Via, Referer and From.
</p>
- <p id="rfc.section.11.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
+ <p id="rfc.section.12.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Implementors <em class="bcp14">SHOULD</em> make the Server header field a configurable option.
</p>
- <p id="rfc.section.11.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
+ <p id="rfc.section.12.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular,
they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
</p>
- <p id="rfc.section.11.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power
+ <p id="rfc.section.12.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power
can be abused if user details are not separated from the information contained in the Referer. Even when the personal information
has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
</p>
- <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
+ <p id="rfc.section.12.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
hence it <em class="bcp14">SHOULD NOT</em> be transmitted without the user being able to disable, enable, and modify the contents of the field. The user <em class="bcp14">MUST</em> be able to set the contents of this field within a user preference or application defaults configuration.
</p>
- <p id="rfc.section.11.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
+ <p id="rfc.section.12.1.p.6">We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending
of From and Referer information.
</p>
- <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.8</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which
+ <p id="rfc.section.12.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 10.9</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 10.8</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which
might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently
has no better mechanism.
</p>
- <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></h2>
- <p id="rfc.section.11.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
+ <h2 id="rfc.section.12.2"><a href="#rfc.section.12.2">12.2</a> <a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></h2>
+ <p id="rfc.section.12.2.p.1">Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could
have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From
information.
</p>
- <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
+ <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
</p>
- <p id="rfc.section.11.2.p.3">Authors of services which use the HTTP protocol <em class="bcp14">SHOULD NOT</em> use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI.
+ <p id="rfc.section.12.2.p.3">Authors of services which use the HTTP protocol <em class="bcp14">SHOULD NOT</em> use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI.
Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third
parties. Servers can use POST-based form submission instead
</p>
- <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
- <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location headers in responses that are generated under control of said organizations
+ <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
+ <p id="rfc.section.12.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location headers in responses that are generated under control of said organizations
to make sure that they do not attempt to invalidate resources over which they have no authority.
</p>
- <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
- <p id="rfc.section.12.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
- <h1 id="rfc.references"><a href="#rfc.section.13" id="rfc.section.13">13.</a> References
+ <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
+ <p id="rfc.section.13.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
+ <h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References
</h1>
- <table summary="References">
+ <table summary="References">
<tr>
- <td class="reference"><b id="RFC1123">[1]</b></td>
- <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, â<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>â, STD 3, RFC 1123, October 1989.
- </td>
- </tr>
+ <td class="reference"><b id="Luo1998">[Luo1998]</b></td>
+ <td class="top">Luotonen, A., âTunneling TCP based protocols through Web proxy serversâ, Work in Progress.</td>
+ </tr>
<tr>
- <td class="reference"><b id="RFC822">[2]</b></td>
- <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, â<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>â, STD 11, RFC 822, August 1982.
+ <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
+ <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, â<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>â, STD 3, RFC 1123, October 1989.
</td>
- </tr>
+ </tr>
<tr>
- <td class="reference"><b id="RFC2068">[3]</b></td>
+ <td class="reference"><b id="RFC2068">[RFC2068]</b></td>
<td class="top"><a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, â<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>â, RFC 2068, January 1997.
</td>
- </tr>
+ </tr>
<tr>
- <td class="reference"><b id="RFC2617">[4]</b></td>
+ <td class="reference"><b id="RFC2617">[RFC2617]</b></td>
<td class="top"><a title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a title="AbiSource, Inc.">Hostetler, J.L.</a>, <a title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a title="Open Market, Inc.">L. Stewart</a>, â<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>â, RFC 2617, June 1999.
</td>
- </tr>
+ </tr>
<tr>
- <td class="reference"><b id="Luo1998">[5]</b></td>
- <td class="top">Luotonen, A., âTunneling TCP based protocols through Web proxy serversâ, Work in Progress.</td>
- </tr>
+ <td class="reference"><b id="RFC822">[RFC822]</b></td>
+ <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, â<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>â, STD 11, RFC 822, August 1982.
+ </td>
+ </tr>
</table>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span>
@@ -1591,7 +1595,7 @@
<p id="rfc.section.A.p.4">This change adds the Expect header and 417 status code.</p>
<p id="rfc.section.A.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>)
</p>
- <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[3]</cite></a>.
+ <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
</p>
<h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
<p>Copyright © The IETF Trust (2007).</p>
@@ -1741,8 +1745,8 @@
<li class="indline1">Max-Forwards <a class="iref" href="#rfc.xref.header.max-forwards.1">4</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">8.8</a>, <a class="iref" href="#rfc.iref.h.6"><b>10.5</b></a></li>
<li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1">4</a>, <a class="iref" href="#rfc.iref.h.7"><b>10.6</b></a></li>
<li class="indline1">Retry-After <a class="iref" href="#rfc.xref.header.retry-after.1">6</a>, <a class="iref" href="#rfc.iref.h.8"><b>10.7</b></a></li>
- <li class="indline1">Server <a class="iref" href="#rfc.xref.header.server.1">6</a>, <a class="iref" href="#rfc.iref.h.9"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">11.1</a></li>
- <li class="indline1">User-Agent <a class="iref" href="#rfc.xref.header.user-agent.1">4</a>, <a class="iref" href="#rfc.iref.h.10"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">11.1</a></li>
+ <li class="indline1">Server <a class="iref" href="#rfc.xref.header.server.1">6</a>, <a class="iref" href="#rfc.iref.h.9"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">12.1</a></li>
+ <li class="indline1">User-Agent <a class="iref" href="#rfc.xref.header.user-agent.1">4</a>, <a class="iref" href="#rfc.iref.h.10"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">12.1</a></li>
</ul>
</li>
</ul>
@@ -1750,7 +1754,7 @@
<li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind">
<li class="indline1">LINK method <a class="iref" href="#rfc.iref.l.2"><b>A</b></a></li>
<li class="indline1">Location header <a class="iref" href="#rfc.xref.header.location.1">6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.l.1"><b>10.4</b></a></li>
- <li class="indline1"><em>Luo1998</em> <a class="iref" href="#rfc.xref.Luo1998.1">8.9</a>, <a class="iref" href="#Luo1998"><b>13</b></a></li>
+ <li class="indline1"><em>Luo1998</em> <a class="iref" href="#rfc.xref.Luo1998.1">8.9</a>, <a class="iref" href="#Luo1998"><b>14</b></a></li>
</ul>
</li>
<li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind">
@@ -1785,17 +1789,17 @@
<li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
<li class="indline1">Referer header <a class="iref" href="#rfc.xref.header.referer.1">4</a>, <a class="iref" href="#rfc.iref.r.1"><b>10.6</b></a></li>
<li class="indline1">Retry-After header <a class="iref" href="#rfc.xref.header.retry-after.1">6</a>, <a class="iref" href="#rfc.iref.r.2"><b>10.7</b></a></li>
- <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">10.3</a>, <a class="iref" href="#RFC1123"><b>13</b></a></li>
- <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.5</a>, <a class="iref" href="#RFC2068"><b>13</b></a>, <a class="iref" href="#rfc.xref.RFC2068.2">A</a><ul class="ind">
+ <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">10.3</a>, <a class="iref" href="#RFC1123"><b>14</b></a></li>
+ <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.5</a>, <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.2">A</a><ul class="ind">
<li class="indline1"><em>Section 14.19</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.5</a></li>
</ul>
</li>
- <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">9.4.2</a>, <a class="iref" href="#rfc.xref.RFC2617.2">9.4.8</a>, <a class="iref" href="#RFC2617"><b>13</b></a></li>
- <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">10.3</a>, <a class="iref" href="#RFC822"><b>13</b></a></li>
+ <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">9.4.2</a>, <a class="iref" href="#rfc.xref.RFC2617.2">9.4.8</a>, <a class="iref" href="#RFC2617"><b>14</b></a></li>
+ <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">10.3</a>, <a class="iref" href="#RFC822"><b>14</b></a></li>
</ul>
</li>
<li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind">
- <li class="indline1">Server header <a class="iref" href="#rfc.xref.header.server.1">6</a>, <a class="iref" href="#rfc.iref.s.42"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">11.1</a></li>
+ <li class="indline1">Server header <a class="iref" href="#rfc.xref.header.server.1">6</a>, <a class="iref" href="#rfc.iref.s.42"><b>10.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">12.1</a></li>
<li class="indline1">Status Codes
<ul class="ind">
<li class="indline1">100 Continue <a class="iref" href="#rfc.xref.status.100.1">5</a>, <a class="iref" href="#rfc.iref.s.1"><b>9.1.1</b></a></li>
@@ -1849,7 +1853,7 @@
</li>
<li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind">
<li class="indline1">UNLINK method <a class="iref" href="#rfc.iref.u.2"><b>A</b></a></li>
- <li class="indline1">User-Agent header <a class="iref" href="#rfc.xref.header.user-agent.1">4</a>, <a class="iref" href="#rfc.iref.u.1"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">11.1</a></li>
+ <li class="indline1">User-Agent header <a class="iref" href="#rfc.xref.header.user-agent.1">4</a>, <a class="iref" href="#rfc.iref.u.1"><b>10.9</b></a>, <a class="iref" href="#rfc.xref.header.user-agent.2">12.1</a></li>
</ul>
</li>
</ul>
Modified: labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml?rev=594034&r1=594033&r2=594034&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml Sun Nov 11 23:22:40 2007
@@ -54,7 +54,8 @@
<!ENTITY message-body "[Part 1]">
]>
<?rfc toc="yes" ?>
-<?rfc symrefs="no" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
@@ -62,7 +63,7 @@
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
<rfc obsoletes="2068, 2616, 2617" category="std"
- ipr="full3667" docName="draft-fielding-http-p2-semantics-00"
+ ipr="full3978" docName="draft-fielding-http-p2-semantics-00"
xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
<front>
@@ -1958,6 +1959,12 @@
</artwork></figure>
</section>
+</section>
+
+<section title="IANA Considerations" anchor="IANA.considerations">
+<t>
+ TBD.
+</t>
</section>
<section title="Security Considerations" anchor="security.considerations">
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org