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/10/10 03:33:57 UTC
svn commit: r583339 - /labs/webarch/trunk/http/draft-fielding-http/
Author: fielding
Date: Tue Oct 9 18:33:56 2007
New Revision: 583339
URL: http://svn.apache.org/viewvc?rev=583339&view=rev
Log:
add section anchors for TOC links
Modified:
labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html
labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml
labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html
labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml
labs/webarch/trunk/http/draft-fielding-http/p5-range.html
labs/webarch/trunk/http/draft-fielding-http/p5-range.xml
labs/webarch/trunk/http/draft-fielding-http/p6-cache.html
labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml
labs/webarch/trunk/http/draft-fielding-http/p7-auth.html
labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml
labs/webarch/trunk/http/draft-fielding-http/rfc2616.html
labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml
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=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.html Tue Oct 9 18:33:56 2007
@@ -459,7 +459,7 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a></li>
+ <li class="tocline0">1. <a href="#introduction">Introduction</a></li>
<li class="tocline0">2. <a href="#product.tokens">Product Tokens</a></li>
<li class="tocline0">3. <a href="#request">Request</a><ul class="toc">
<li class="tocline1">3.1 <a href="#request-line">Request-Line</a><ul class="toc">
@@ -481,7 +481,7 @@
</li>
<li class="tocline0">5. <a href="#entity">Entity</a></li>
<li class="tocline0">6. <a href="#method.definitions">Method Definitions</a><ul class="toc">
- <li class="tocline1">6.1 <a href="#rfc.section.6.1">Safe and Idempotent Methods</a><ul class="toc">
+ <li class="tocline1">6.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc">
<li class="tocline1">6.1.1 <a href="#safe.methods">Safe Methods</a></li>
<li class="tocline1">6.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li>
</ul>
@@ -502,7 +502,7 @@
<li class="tocline1">7.1.2 <a href="#status.101">101 Switching Protocols</a></li>
</ul>
</li>
- <li class="tocline1">7.2 <a href="#rfc.section.7.2">Successful 2xx</a><ul class="toc">
+ <li class="tocline1">7.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc">
<li class="tocline1">7.2.1 <a href="#status.200">200 OK</a></li>
<li class="tocline1">7.2.2 <a href="#status.201">201 Created</a></li>
<li class="tocline1">7.2.3 <a href="#status.202">202 Accepted</a></li>
@@ -512,7 +512,7 @@
<li class="tocline1">7.2.7 <a href="#status.206">206 Partial Content</a></li>
</ul>
</li>
- <li class="tocline1">7.3 <a href="#rfc.section.7.3">Redirection 3xx</a><ul class="toc">
+ <li class="tocline1">7.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc">
<li class="tocline1">7.3.1 <a href="#status.300">300 Multiple Choices</a></li>
<li class="tocline1">7.3.2 <a href="#status.301">301 Moved Permanently</a></li>
<li class="tocline1">7.3.3 <a href="#status.302">302 Found</a></li>
@@ -523,7 +523,7 @@
<li class="tocline1">7.3.8 <a href="#status.307">307 Temporary Redirect</a></li>
</ul>
</li>
- <li class="tocline1">7.4 <a href="#rfc.section.7.4">Client Error 4xx</a><ul class="toc">
+ <li class="tocline1">7.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc">
<li class="tocline1">7.4.1 <a href="#status.400">400 Bad Request</a></li>
<li class="tocline1">7.4.2 <a href="#status.401">401 Unauthorized</a></li>
<li class="tocline1">7.4.3 <a href="#status.402">402 Payment Required</a></li>
@@ -544,7 +544,7 @@
<li class="tocline1">7.4.18 <a href="#status.417">417 Expectation Failed</a></li>
</ul>
</li>
- <li class="tocline1">7.5 <a href="#rfc.section.7.5">Server Error 5xx</a><ul class="toc">
+ <li class="tocline1">7.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc">
<li class="tocline1">7.5.1 <a href="#status.500">500 Internal Server Error</a></li>
<li class="tocline1">7.5.2 <a href="#status.501">501 Not Implemented</a></li>
<li class="tocline1">7.5.3 <a href="#status.502">502 Bad Gateway</a></li>
@@ -555,7 +555,7 @@
</li>
</ul>
</li>
- <li class="tocline0">8. <a href="#rfc.section.8">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">8. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">8.1 <a href="#header.allow">Allow</a></li>
<li class="tocline1">8.2 <a href="#header.expect">Expect</a></li>
<li class="tocline1">8.3 <a href="#header.from">From</a></li>
@@ -568,16 +568,16 @@
<li class="tocline1">8.10 <a href="#header.user-agent">User-Agent</a></li>
</ul>
</li>
- <li class="tocline0">9. <a href="#rfc.section.9">Security Considerations</a><ul class="toc">
- <li class="tocline1">9.1 <a href="#rfc.section.9.1">Transfer of Sensitive Information</a></li>
+ <li class="tocline0">9. <a href="#security.considerations">Security Considerations</a><ul class="toc">
+ <li class="tocline1">9.1 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
<li class="tocline1">9.2 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
- <li class="tocline1">9.3 <a href="#rfc.section.9.3">Location Headers and Spoofing</a></li>
+ <li class="tocline1">9.3 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
</ul>
</li>
- <li class="tocline0">10. <a href="#rfc.section.10">Acknowledgments</a></li>
+ <li class="tocline0">10. <a href="#ack">Acknowledgments</a></li>
<li class="tocline0">11. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
- <li class="tocline0">A. <a href="#rfc.section.A">Changes from HTTP/1.0</a><ul class="toc">
+ <li class="tocline0">A. <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul class="toc">
<li class="tocline1">A.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li>
</ul>
</li>
@@ -585,8 +585,7 @@
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to request and response semantics. Right now it only includes the extracted
relevant sections of RFC 2616 with only minor edits.
</p>
@@ -840,8 +839,7 @@
<p id="rfc.section.6.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.4</a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
</p>
- <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> Safe and Idempotent Methods
- </h2>
+ <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
<h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
<p id="rfc.section.6.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves
@@ -1054,8 +1052,7 @@
older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use
such features.
</p>
- <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> Successful 2xx
- </h2>
+ <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
<p id="rfc.section.7.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
<div id="rfc.iref.32"></div>
<div id="rfc.iref.s.3"></div>
@@ -1129,8 +1126,7 @@
<p id="rfc.section.7.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined
in [Part 5].
</p>
- <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> Redirection 3xx
- </h2>
+ <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
<p id="rfc.section.7.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is
GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection.
@@ -1254,8 +1250,7 @@
<p id="rfc.section.7.3.8.p.3">If the 307 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
the request was issued.
</p>
- <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> Client Error 4xx
- </h2>
+ <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
<p id="rfc.section.7.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD
request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user.
@@ -1407,8 +1402,7 @@
<p id="rfc.section.7.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 8.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
not be met by the next-hop server.
</p>
- <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> Server Error 5xx
- </h2>
+ <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
<p id="rfc.section.7.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method.
@@ -1457,8 +1451,7 @@
is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
in [Part 1], other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
</p>
- <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.8.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -1629,14 +1622,12 @@
<div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.28"></span> User-Agent = "User-Agent" ":" 1*( product | comment )
</pre><p id="rfc.section.8.10.p.3">Example:</p>
<div id="rfc.figure.u.32"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
-</pre><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Security Considerations
- </h1>
+</pre><h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.9.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.9.1"><a href="#rfc.section.9.1">9.1</a> Transfer of Sensitive Information
- </h2>
+ <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h2>
<p id="rfc.section.9.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
@@ -1674,13 +1665,11 @@
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.9.3"><a href="#rfc.section.9.3">9.3</a> Location Headers and Spoofing
- </h2>
+ <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
<p id="rfc.section.9.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.10"><a href="#rfc.section.10">10.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.10.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.11" id="rfc.section.11">11.</a> References
</h1>
@@ -1723,8 +1712,7 @@
<address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">3333 Coyote Hill Road</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94034</span></span></span><span class="vcardline">EMail: <a><span class="email">masinter@parc.xerox.com</span></a></span></address>
<address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a><span class="email">paulle@microsoft.com</span></a></span></address>
<address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a><span class="email">timbl@w3.org</span></a></span></address>
- <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> Changes from HTTP/1.0
- </h1>
+ <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h1>
<p id="rfc.section.A.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
<h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h2>
<p id="rfc.section.A.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 8.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-uri" title="Request-URI">Section 3.1.2</a>) are among the most important changes defined by this specification.
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=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml Tue Oct 9 18:33:56 2007
@@ -186,7 +186,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to request and response
semantics. Right now it only includes the extracted relevant sections of
@@ -643,7 +643,7 @@
HTTP/1.1 requests.
</t>
-<section title="Safe and Idempotent Methods">
+<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
<section title="Safe Methods" anchor="safe.methods">
<t>
@@ -1075,7 +1075,7 @@
</section>
</section>
-<section title="Successful 2xx">
+<section title="Successful 2xx" anchor="status.2xx">
<t>
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
@@ -1214,7 +1214,7 @@
</section>
</section>
-<section title="Redirection 3xx">
+<section title="Redirection 3xx" anchor="status.3xx">
<t>
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
@@ -1448,7 +1448,7 @@
</section>
</section>
-<section title="Client Error 4xx">
+<section title="Client Error 4xx" anchor="status.4xx">
<t>
The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD request,
@@ -1739,7 +1739,7 @@
</section>
</section>
-<section title="Server Error 5xx">
+<section title="Server Error 5xx" anchor="status.5xx">
<t>
Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of
@@ -1831,7 +1831,7 @@
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -2200,7 +2200,7 @@
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as
@@ -2209,7 +2209,7 @@
some suggestions for reducing security risks.
</t>
-<section title="Transfer of Sensitive Information">
+<section title="Transfer of Sensitive Information" anchor="security.sensitive">
<t>
Like any generic data transfer protocol, HTTP cannot regulate the
content of the data that is transferred, nor is there any a priori
@@ -2287,7 +2287,7 @@
</t>
</section>
-<section title="Location Headers and Spoofing">
+<section title="Location Headers and Spoofing" anchor="location.spoofing">
<t>
If a single server supports multiple organizations that do not trust
one another, then it &MUST; check the values of Location and Content-Location
@@ -2299,7 +2299,7 @@
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Based on an XML translation of RFC 2616 by Julian Reschke.
</t>
@@ -2543,7 +2543,7 @@
</references>
-<section title="Changes from HTTP/1.0">
+<section title="Changes from HTTP/1.0" anchor="changes.from.1.0">
<t>
This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1.
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.html Tue Oct 9 18:33:56 2007
@@ -456,7 +456,7 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a></li>
+ <li class="tocline0">1. <a href="#introduction">Introduction</a></li>
<li class="tocline0">2. <a href="#rfc.section.2">Protocol Parameters</a><ul class="toc">
<li class="tocline1">2.1 <a href="#character.sets">Character Sets</a><ul class="toc">
<li class="tocline1">2.1.1 <a href="#missing.charset">Missing Charset</a></li>
@@ -487,7 +487,7 @@
<li class="tocline1">4.3 <a href="#rfc.section.4.3">Transparent Negotiation</a></li>
</ul>
</li>
- <li class="tocline0">5. <a href="#rfc.section.5">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">5. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">5.1 <a href="#header.accept">Accept</a></li>
<li class="tocline1">5.2 <a href="#header.accept-charset">Accept-Charset</a></li>
<li class="tocline1">5.3 <a href="#header.accept-encoding">Accept-Encoding</a></li>
@@ -499,12 +499,12 @@
<li class="tocline1">5.9 <a href="#header.content-type">Content-Type</a></li>
</ul>
</li>
- <li class="tocline0">6. <a href="#rfc.section.6">Security Considerations</a><ul class="toc">
+ <li class="tocline0">6. <a href="#security.considerations">Security Considerations</a><ul class="toc">
<li class="tocline1">6.1 <a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
<li class="tocline1">6.2 <a href="#content-disposition.issues">Content-Disposition Issues</a></li>
</ul>
</li>
- <li class="tocline0">7. <a href="#rfc.section.7">Acknowledgments</a></li>
+ <li class="tocline0">7. <a href="#ack">Acknowledgments</a></li>
<li class="tocline0">8. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0">A. <a href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc">
@@ -524,8 +524,7 @@
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to the payload of messages (message content), including metadata and media
types, along with HTTP content negotiation. Right now it only includes the extracted relevant sections of RFC 2616 without
edit.
@@ -827,8 +826,7 @@
<p id="rfc.section.4.3.p.3">This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism
from being developed as an extension that could be used within HTTP/1.1.
</p>
- <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.5.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -1126,8 +1124,7 @@
<div id="rfc.figure.u.32"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4
</pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section 3.2.1</a>.
</p>
- <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> Security Considerations
- </h1>
+ <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.6.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.
@@ -1155,8 +1152,7 @@
<p id="rfc.section.6.2.p.1">RFC 1806 <a href="#RFC1806" id="rfc.xref.RFC1806.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[12]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the
HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[19]</cite></a> (which updates RFC 1806) for details.
</p>
- <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.7.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.8" id="rfc.section.8">8.</a> References
</h1>
Modified: labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p3-payload.xml Tue Oct 9 18:33:56 2007
@@ -153,7 +153,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to the payload of
messages (message content), including metadata and media types, along
@@ -735,7 +735,7 @@
</t>
</section>
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -1297,7 +1297,7 @@
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as
@@ -1358,7 +1358,7 @@
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Based on an XML translation of RFC 2616 by Julian Reschke.
</t>
Modified: labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p4-conditional.html Tue Oct 9 18:33:56 2007
@@ -454,11 +454,11 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a></li>
+ <li class="tocline0">1. <a href="#introduction">Introduction</a></li>
<li class="tocline0">2. <a href="#entity.tags">Entity Tags</a></li>
<li class="tocline0">3. <a href="#weak.and.strong.validators">Weak and Strong Validators</a></li>
<li class="tocline0">4. <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity Tags and Last-Modified Dates</a></li>
- <li class="tocline0">5. <a href="#rfc.section.5">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">5. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">5.1 <a href="#header.etag">ETag</a></li>
<li class="tocline1">5.2 <a href="#header.if-match">If-Match</a></li>
<li class="tocline1">5.3 <a href="#header.if-modified-since">If-Modified-Since</a></li>
@@ -467,15 +467,14 @@
<li class="tocline1">5.6 <a href="#header.last-modified">Last-Modified</a></li>
</ul>
</li>
- <li class="tocline0">6. <a href="#rfc.section.6">Security Considerations</a></li>
- <li class="tocline0">7. <a href="#rfc.section.7">Acknowledgments</a></li>
+ <li class="tocline0">6. <a href="#security.considerations">Security Considerations</a></li>
+ <li class="tocline0">7. <a href="#ack">Acknowledgments</a></li>
<li class="tocline0">8. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right
now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[1]</cite> without edit.
</p>
@@ -633,8 +632,7 @@
HTTP/1.1 origin servers should not provide one.
</dd>
</dl>
- <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.5.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -806,11 +804,9 @@
</p>
<p id="rfc.section.5.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
</p>
- <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> Security Considerations
- </h1>
+ <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general [Part 1].</p>
- <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.7.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.8" id="rfc.section.8">8.</a> References
</h1>
Modified: labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml Tue Oct 9 18:33:56 2007
@@ -147,7 +147,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to conditional
request messages based on time stamps and entity-tags. Right now it
@@ -427,7 +427,7 @@
</t>
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -773,14 +773,14 @@
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
No additional security considerations have been identified beyond
those applicable to HTTP in general &messaging;.
</t>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Based on an XML translation of RFC 2616 by Julian Reschke.
</t>
Modified: labs/webarch/trunk/http/draft-fielding-http/p5-range.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p5-range.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p5-range.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p5-range.html Tue Oct 9 18:33:56 2007
@@ -456,12 +456,12 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a></li>
+ <li class="tocline0">1. <a href="#introduction">Introduction</a></li>
<li class="tocline0">2. <a href="#range.units">Range Units</a></li>
<li class="tocline0">3. <a href="#status.206">206 Partial Content</a></li>
<li class="tocline0">4. <a href="#status.416">416 Requested Range Not Satisfiable</a></li>
<li class="tocline0">5. <a href="#combining.byte.ranges">Combining Byte Ranges</a></li>
- <li class="tocline0">6. <a href="#rfc.section.6">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">6. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">6.1 <a href="#header.accept-ranges">Accept-Ranges</a></li>
<li class="tocline1">6.2 <a href="#header.content-range">Content-Range</a></li>
<li class="tocline1">6.3 <a href="#header.if-range">If-Range</a></li>
@@ -472,8 +472,8 @@
</li>
</ul>
</li>
- <li class="tocline0">7. <a href="#rfc.section.7">Acknowledgments</a></li>
- <li class="tocline0">8. <a href="#rfc.section.8">Security Considerations</a></li>
+ <li class="tocline0">7. <a href="#ack">Acknowledgments</a></li>
+ <li class="tocline0">8. <a href="#security.considerations">Security Considerations</a></li>
<li class="tocline0">9. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0">A. <a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li>
@@ -481,8 +481,7 @@
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to range requests, partial responses, and the multipart/byteranges media
type. Right now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[2]</cite> without edit.
</p>
@@ -544,8 +543,7 @@
<p id="rfc.section.5.p.3">If either requirement is not met, the cache <em class="bcp14">MUST</em> use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming
response if these values are equal or missing), and <em class="bcp14">MUST</em> discard the other partial information.
</p>
- <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.6.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -726,14 +724,12 @@
<p id="rfc.section.6.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire
entity in reply, it <em class="bcp14">SHOULD</em> only return the requested range to its client. It <em class="bcp14">SHOULD</em> store the entire received response in its cache if that is consistent with its cache allocation policies.
</p>
- <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.7.p.1">Most of the specification of ranges is based on work originally done by Ari Luotonen and John Franks, with additional input
from Steve Zilles.
</p>
<p id="rfc.section.7.p.2">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
- <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> Security Considerations
- </h1>
+ <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.8.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general [Part 1].</p>
<h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References
</h1>
Modified: labs/webarch/trunk/http/draft-fielding-http/p5-range.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p5-range.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p5-range.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p5-range.xml Tue Oct 9 18:33:56 2007
@@ -144,7 +144,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to range requests,
partial responses, and the multipart/byteranges media type. Right now
@@ -279,7 +279,7 @@
</t>
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -638,7 +638,7 @@
</section>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Most of the specification of ranges is based on work originally done
by Ari Luotonen and John Franks, with additional input from Steve
@@ -649,7 +649,7 @@
</t>
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
No additional security considerations have been identified beyond
those applicable to HTTP in general &messaging;.
Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p6-cache.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.html Tue Oct 9 18:33:56 2007
@@ -453,7 +453,7 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a><ul class="toc">
+ <li class="tocline0">1. <a href="#introduction">Introduction</a><ul class="toc">
<li class="tocline1">1.1 <a href="#rfc.section.1.1">Terminology</a></li>
<li class="tocline1">1.2 <a href="#delta.seconds">Delta Seconds</a></li>
</ul>
@@ -500,7 +500,7 @@
<li class="tocline1">2.13 <a href="#history.lists">History Lists</a></li>
</ul>
</li>
- <li class="tocline0">3. <a href="#rfc.section.3">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">3. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">3.1 <a href="#header.age">Age</a></li>
<li class="tocline1">3.2 <a href="#header.cache-control">Cache-Control</a><ul class="toc">
<li class="tocline1">3.2.1 <a href="#what.is.cacheable">What is Cacheable</a></li>
@@ -517,16 +517,15 @@
<li class="tocline1">3.6 <a href="#header.warning">Warning</a></li>
</ul>
</li>
- <li class="tocline0">4. <a href="#rfc.section.4">Security Considerations</a></li>
- <li class="tocline0">5. <a href="#rfc.section.5">Acknowledgments</a></li>
+ <li class="tocline0">4. <a href="#security.considerations">Security Considerations</a></li>
+ <li class="tocline0">5. <a href="#ack">Acknowledgments</a></li>
<li class="tocline0">6. <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>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to caching response messages. Right now it only includes the extracted relevant
sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[3]</cite> without edit.
</p>
@@ -1184,8 +1183,7 @@
in order not to suffer the effects of improperly functioning history mechanisms.
</dd>
</dl>
- <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.3.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -1685,15 +1683,13 @@
the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning
header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well.
</p>
- <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Security Considerations
- </h1>
+ <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.4.p.1">Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target
for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal
information long after a user believes that the information has been removed from the network. Therefore, cache contents should
be protected as sensitive information.
</p>
- <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.5.p.1">Much of the content and presentation of the caching design is due to suggestions and comments from individuals including:
Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
</p>
Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml Tue Oct 9 18:33:56 2007
@@ -156,7 +156,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to caching response
messages. Right now it only includes the extracted relevant sections
@@ -1456,7 +1456,7 @@
</section>
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -2347,7 +2347,7 @@
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
Caching proxies provide additional potential vulnerabilities, since
the contents of the cache represent an attractive target for
@@ -2359,7 +2359,7 @@
</t>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Much of the content and presentation of the caching design is due to
suggestions and comments from individuals including: Shel Kaphan,
Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p7-auth.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.html Tue Oct 9 18:33:56 2007
@@ -450,26 +450,25 @@
<hr class="noprint">
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
- <li class="tocline0">1. <a href="#rfc.section.1">Introduction</a></li>
- <li class="tocline0">2. <a href="#rfc.section.2">Header Field Definitions</a><ul class="toc">
+ <li class="tocline0">1. <a href="#introduction">Introduction</a></li>
+ <li class="tocline0">2. <a href="#header.fields">Header Field Definitions</a><ul class="toc">
<li class="tocline1">2.1 <a href="#header.authorization">Authorization</a></li>
<li class="tocline1">2.2 <a href="#header.proxy-authenticate">Proxy-Authenticate</a></li>
<li class="tocline1">2.3 <a href="#header.proxy-authorization">Proxy-Authorization</a></li>
<li class="tocline1">2.4 <a href="#header.www-authenticate">WWW-Authenticate</a></li>
</ul>
</li>
- <li class="tocline0">3. <a href="#rfc.section.3">Security Considerations</a><ul class="toc">
+ <li class="tocline0">3. <a href="#security.considerations">Security Considerations</a><ul class="toc">
<li class="tocline1">3.1 <a href="#rfc.section.3.1">Authentication Credentials and Idle Clients</a></li>
</ul>
</li>
- <li class="tocline0">4. <a href="#rfc.section.4">Acknowledgments</a></li>
+ <li class="tocline0">4. <a href="#ack">Acknowledgments</a></li>
<li class="tocline0">5. <a href="#rfc.references">References</a></li>
<li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
<li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
<li class="tocline0"><a href="#rfc.index">Index</a></li>
</ul>
- <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction
- </h1>
+ <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to access control and authentication. Right now it only includes the extracted
relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[1]</cite> with only minor edits.
</p>
@@ -477,8 +476,7 @@
provide authentication information. The general framework for access authentication, and the specification of "basic" and
"digest" authentication, are specified 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">[2]</cite></a>. This specification adopts the definitions of "challenge" and "credentials" from that specification.
</p>
- <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> Header Field Definitions
- </h1>
+ <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
<p id="rfc.section.2.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender
and recipient refer to either the client or the server, depending on who sends and who receives the entity.
</p>
@@ -541,8 +539,7 @@
challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
comma-separated list of authentication parameters.
</p>
- <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> Security Considerations
- </h1>
+ <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
<p id="rfc.section.3.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.
@@ -567,8 +564,7 @@
in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism
for discarding cached credentials under user control.
</p>
- <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Acknowledgments
- </h1>
+ <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>
<p id="rfc.section.4.p.1">Based on an XML translation of RFC 2616 by Julian Reschke.</p>
<h1 id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> References
</h1>
Modified: labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p7-auth.xml Tue Oct 9 18:33:56 2007
@@ -142,7 +142,7 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to access control and
authentication. Right now it only includes the extracted relevant sections
@@ -159,7 +159,7 @@
from that specification.
</t>
</section>
-<section title="Header Field Definitions">
+<section title="Header Field Definitions" anchor="header.fields">
<t>
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
@@ -297,7 +297,7 @@
</section>
-<section title="Security Considerations">
+<section title="Security Considerations" anchor="security.considerations">
<t>
This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as
@@ -337,7 +337,7 @@
</section>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
Based on an XML translation of RFC 2616 by Julian Reschke.
</t>
Modified: labs/webarch/trunk/http/draft-fielding-http/rfc2616.html
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/rfc2616.html?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/rfc2616.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/rfc2616.html Tue Oct 9 18:33:56 2007
@@ -551,7 +551,7 @@
</ul>
</li>
<li class="tocline0">9. <a href="#method.definitions">Method Definitions</a><ul class="toc">
- <li class="tocline1">9.1 <a href="#rfc.section.9.1">Safe and Idempotent Methods</a><ul class="toc">
+ <li class="tocline1">9.1 <a href="#safe.and.idempotent">Safe and Idempotent Methods</a><ul class="toc">
<li class="tocline1">9.1.1 <a href="#safe.methods">Safe Methods</a></li>
<li class="tocline1">9.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li>
</ul>
@@ -572,7 +572,7 @@
<li class="tocline1">10.1.2 <a href="#status.101">101 Switching Protocols</a></li>
</ul>
</li>
- <li class="tocline1">10.2 <a href="#rfc.section.10.2">Successful 2xx</a><ul class="toc">
+ <li class="tocline1">10.2 <a href="#status.2xx">Successful 2xx</a><ul class="toc">
<li class="tocline1">10.2.1 <a href="#status.200">200 OK</a></li>
<li class="tocline1">10.2.2 <a href="#status.201">201 Created</a></li>
<li class="tocline1">10.2.3 <a href="#status.202">202 Accepted</a></li>
@@ -582,7 +582,7 @@
<li class="tocline1">10.2.7 <a href="#status.206">206 Partial Content</a></li>
</ul>
</li>
- <li class="tocline1">10.3 <a href="#rfc.section.10.3">Redirection 3xx</a><ul class="toc">
+ <li class="tocline1">10.3 <a href="#status.3xx">Redirection 3xx</a><ul class="toc">
<li class="tocline1">10.3.1 <a href="#status.300">300 Multiple Choices</a></li>
<li class="tocline1">10.3.2 <a href="#status.301">301 Moved Permanently</a></li>
<li class="tocline1">10.3.3 <a href="#status.302">302 Found</a></li>
@@ -593,7 +593,7 @@
<li class="tocline1">10.3.8 <a href="#status.307">307 Temporary Redirect</a></li>
</ul>
</li>
- <li class="tocline1">10.4 <a href="#rfc.section.10.4">Client Error 4xx</a><ul class="toc">
+ <li class="tocline1">10.4 <a href="#status.4xx">Client Error 4xx</a><ul class="toc">
<li class="tocline1">10.4.1 <a href="#status.400">400 Bad Request</a></li>
<li class="tocline1">10.4.2 <a href="#status.401">401 Unauthorized</a></li>
<li class="tocline1">10.4.3 <a href="#status.402">402 Payment Required</a></li>
@@ -614,7 +614,7 @@
<li class="tocline1">10.4.18 <a href="#status.417">417 Expectation Failed</a></li>
</ul>
</li>
- <li class="tocline1">10.5 <a href="#rfc.section.10.5">Server Error 5xx</a><ul class="toc">
+ <li class="tocline1">10.5 <a href="#status.5xx">Server Error 5xx</a><ul class="toc">
<li class="tocline1">10.5.1 <a href="#status.500">500 Internal Server Error</a></li>
<li class="tocline1">10.5.2 <a href="#status.501">501 Not Implemented</a></li>
<li class="tocline1">10.5.3 <a href="#status.502">502 Bad Gateway</a></li>
@@ -745,14 +745,14 @@
<li class="tocline0">15. <a href="#security.considerations">Security Considerations</a><ul class="toc">
<li class="tocline1">15.1 <a href="#personal.information">Personal Information</a><ul class="toc">
<li class="tocline1">15.1.1 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>
- <li class="tocline1">15.1.2 <a href="#rfc.section.15.1.2">Transfer of Sensitive Information</a></li>
+ <li class="tocline1">15.1.2 <a href="#security.sensitive">Transfer of Sensitive Information</a></li>
<li class="tocline1">15.1.3 <a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URI's</a></li>
<li class="tocline1">15.1.4 <a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
</ul>
</li>
<li class="tocline1">15.2 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li>
<li class="tocline1">15.3 <a href="#dns.spoofing">DNS Spoofing</a></li>
- <li class="tocline1">15.4 <a href="#rfc.section.15.4">Location Headers and Spoofing</a></li>
+ <li class="tocline1">15.4 <a href="#location.spoofing">Location Headers and Spoofing</a></li>
<li class="tocline1">15.5 <a href="#content-disposition.issues">Content-Disposition Issues</a></li>
<li class="tocline1">15.6 <a href="#rfc.section.15.6">Authentication Credentials and Idle Clients</a></li>
<li class="tocline1">15.7 <a href="#attack.proxies">Proxies and Caching</a><ul class="toc">
@@ -783,7 +783,7 @@
</ul>
</li>
<li class="tocline1">19.6 <a href="#compatibility">Compatibility with Previous Versions</a><ul class="toc">
- <li class="tocline1">19.6.1 <a href="#rfc.section.19.6.1">Changes from HTTP/1.0</a><ul class="toc">
+ <li class="tocline1">19.6.1 <a href="#changes.from.1.0">Changes from HTTP/1.0</a><ul class="toc">
<li class="tocline1">19.6.1.1 <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></li>
</ul>
</li>
@@ -2170,8 +2170,7 @@
<p id="rfc.section.9.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 14.23</a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
</p>
- <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> Safe and Idempotent Methods
- </h2>
+ <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
<h3 id="rfc.section.9.1.1"><a href="#rfc.section.9.1.1">9.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
<p id="rfc.section.9.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves
@@ -2382,8 +2381,7 @@
older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use
such features.
</p>
- <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> Successful 2xx
- </h2>
+ <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
<p id="rfc.section.10.2.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
<div id="rfc.iref.144"></div>
<div id="rfc.iref.s.6"></div>
@@ -2475,8 +2473,7 @@
</p>
<p id="rfc.section.10.2.7.p.5">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> cache 206 (Partial) responses.
</p>
- <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> Redirection 3xx
- </h2>
+ <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
<p id="rfc.section.10.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is
GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection.
@@ -2600,8 +2597,7 @@
<p id="rfc.section.10.3.8.p.3">If the 307 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
the request was issued.
</p>
- <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> Client Error 4xx
- </h2>
+ <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
<p id="rfc.section.10.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD
request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entity to the user.
@@ -2754,8 +2750,7 @@
<p id="rfc.section.10.4.18.p.1">The expectation given in an Expect request-header field (see <a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 14.20</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
not be met by the next-hop server.
</p>
- <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> Server Error 5xx
- </h2>
+ <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
<p id="rfc.section.10.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
User agents <em class="bcp14">SHOULD</em> display any included entity to the user. These response codes are applicable to any request method.
@@ -5234,8 +5229,7 @@
People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without
the permission of any individuals that are identifiable by the published results.
</p>
- <h3 id="rfc.section.15.1.2"><a href="#rfc.section.15.1.2">15.1.2</a> Transfer of Sensitive Information
- </h3>
+ <h3 id="rfc.section.15.1.2"><a href="#rfc.section.15.1.2">15.1.2</a> <a id="security.sensitive" href="#security.sensitive">Transfer of Sensitive Information</a></h3>
<p id="rfc.section.15.1.2.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
@@ -5318,8 +5312,7 @@
<p id="rfc.section.15.3.p.5">This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces
the likelihood of a user's experiencing failure in accessing sites which use that strategy.
</p>
- <h2 id="rfc.section.15.4"><a href="#rfc.section.15.4">15.4</a> Location Headers and Spoofing
- </h2>
+ <h2 id="rfc.section.15.4"><a href="#rfc.section.15.4">15.4</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
<p id="rfc.section.15.4.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>
@@ -5956,8 +5949,7 @@
server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.5">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[33]</cite></a>.
</p>
- <h3 id="rfc.section.19.6.1"><a href="#rfc.section.19.6.1">19.6.1</a> Changes from HTTP/1.0
- </h3>
+ <h3 id="rfc.section.19.6.1"><a href="#rfc.section.19.6.1">19.6.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h3>
<p id="rfc.section.19.6.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
<h4 id="rfc.section.19.6.1.1"><a href="#rfc.section.19.6.1.1">19.6.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h4>
<p id="rfc.section.19.6.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section 14.23</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>) are among the most important changes defined by this specification.
Modified: labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml?rev=583339&r1=583338&r2=583339&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml Tue Oct 9 18:33:56 2007
@@ -2859,7 +2859,7 @@
HTTP/1.1 requests.
</t>
-<section title="Safe and Idempotent Methods">
+<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
<section title="Safe Methods" anchor="safe.methods">
<t>
@@ -3291,7 +3291,7 @@
</section>
</section>
-<section title="Successful 2xx">
+<section title="Successful 2xx" anchor="status.2xx">
<t>
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
@@ -3476,7 +3476,7 @@
</section>
</section>
-<section title="Redirection 3xx">
+<section title="Redirection 3xx" anchor="status.3xx">
<t>
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
@@ -3710,7 +3710,7 @@
</section>
</section>
-<section title="Client Error 4xx">
+<section title="Client Error 4xx" anchor="status.4xx">
<t>
The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD request,
@@ -4011,7 +4011,7 @@
</section>
</section>
-<section title="Server Error 5xx">
+<section title="Server Error 5xx" anchor="status.5xx">
<t>
Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of
@@ -8812,7 +8812,7 @@
</t>
</section>
-<section title="Transfer of Sensitive Information">
+<section title="Transfer of Sensitive Information" anchor="security.sensitive">
<t>
Like any generic data transfer protocol, HTTP cannot regulate the
content of the data that is transferred, nor is there any a priori
@@ -8989,7 +8989,7 @@
</t>
</section>
-<section title="Location Headers and Spoofing">
+<section title="Location Headers and Spoofing" anchor="location.spoofing">
<t>
If a single server supports multiple organizations that do not trust
one another, then it &MUST; check the values of Location and Content-Location
@@ -11110,7 +11110,7 @@
2068 <xref target="RFC2068"/>.
</t>
-<section title="Changes from HTTP/1.0">
+<section title="Changes from HTTP/1.0" anchor="changes.from.1.0">
<t>
This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1.
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org