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/09 23:03:08 UTC
svn commit: r583299 [2/2] - in /labs/webarch/trunk/http/draft-fielding-http:
p1-messaging.html p1-messaging.xml rfc2616.html rfc2616.xml
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=583299&r1=583298&r2=583299&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Tue Oct 9 14:03:07 2007
@@ -167,14 +167,14 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
<t>
This document will define aspects of HTTP related to overall network
operation, message framing, interaction with transport protocols, and
URI schemes. Right now it only includes the extracted relevant sections
of <xref target="RFC2616"/> and <xref target="RFC2617"/>.
</t>
-<section title="Purpose">
+<section title="Purpose" anchor="intro.purpose">
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
@@ -217,7 +217,7 @@
</t>
</section>
-<section title="Requirements">
+<section title="Requirements" anchor="intro.requirements">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ -234,7 +234,7 @@
</t>
</section>
-<section title="Terminology">
+<section title="Terminology" anchor="intro.terminology">
<t>
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
@@ -483,7 +483,7 @@
</t>
</section>
-<section title="Overall Operation">
+<section title="Overall Operation" anchor="intro.overall.operation">
<t>
The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and
@@ -593,9 +593,9 @@
</section>
</section>
-<section title="Notational Conventions and Generic Grammar">
+<section title="Notational Conventions and Generic Grammar" anchor="notation">
-<section title="Augmented BNF">
+<section title="Augmented BNF" anchor="notation.abnf">
<t>
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
@@ -864,7 +864,7 @@
</section>
</section>
-<section title="Protocol Parameters">
+<section title="Protocol Parameters" anchor="protocol.parameters">
<section title="HTTP Version" anchor="http.version">
<t>
@@ -1031,7 +1031,7 @@
</section>
</section>
-<section title="Date/Time Formats">
+<section title="Date/Time Formats" anchor="date.time.formats">
<section title="Full Date" anchor="full.date">
<t>
HTTP applications have historically allowed three different formats
@@ -1253,7 +1253,7 @@
<section title="HTTP Message" anchor="httpmessage">
-<section title="Message Types">
+<section title="Message Types" anchor="message.types">
<t>
HTTP messages consist of requests from client to server and responses
from server to client.
@@ -1499,11 +1499,11 @@
</section>
</section>
-<section title="Connections">
+<section title="Connections" anchor="connections">
<section title="Persistent Connections" anchor="persistent.connections">
-<section title="Purpose">
+<section title="Purpose" anchor="persistent.purpose">
<t>
Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers
@@ -1554,7 +1554,7 @@
</t>
</section>
-<section title="Overall Operation">
+<section title="Overall Operation" anchor="persistent.overall">
<t>
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
@@ -1570,7 +1570,7 @@
connection.
</t>
-<section title="Negotiation">
+<section title="Negotiation" anchor="persistent.negotiation">
<t>
An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including
@@ -1632,7 +1632,7 @@
</section>
</section>
-<section title="Proxy Servers">
+<section title="Proxy Servers" anchor="persistent.proxy">
<t>
It is especially important that proxies correctly implement the
properties of the Connection header field as specified in <xref target="header.connection"/>.
@@ -1651,7 +1651,7 @@
</t>
</section>
-<section title="Practical Considerations">
+<section title="Practical Considerations" anchor="persistent.practical">
<t>
Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make
@@ -1708,7 +1708,7 @@
<section title="Message Transmission Requirements" anchor="message.transmission.requirements">
-<section title="Persistent Connections and Flow Control">
+<section title="Persistent Connections and Flow Control" anchor="persistent.flow">
<t>
HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's
flow control mechanisms to resolve temporary overloads, rather than
@@ -1717,7 +1717,7 @@
</t>
</section>
-<section title="Monitoring Connections for Error Status Messages">
+<section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
<t>
An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor
the network connection for an error status while it is transmitting
@@ -1841,7 +1841,7 @@
</t>
</section>
-<section title="Client Behavior if Server Prematurely Closes Connection">
+<section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature">
<t>
If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header field with the
@@ -1898,7 +1898,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
@@ -2368,7 +2368,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
@@ -2377,7 +2377,7 @@
some suggestions for reducing security risks.
</t>
-<section title="Personal Information">
+<section title="Personal Information" anchor="personal.information">
<t>
HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption
@@ -2404,7 +2404,7 @@
</t>
</section>
-<section title="Attacks Based On File and Path Names">
+<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
<t>
Implementations of HTTP origin servers &SHOULD; be careful to restrict
the documents returned by HTTP requests to be only those that were
@@ -2425,7 +2425,7 @@
</t>
</section>
-<section title="DNS Spoofing">
+<section title="DNS Spoofing" anchor="dns.spoofing">
<t>
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
@@ -2463,7 +2463,7 @@
</t>
</section>
-<section title="Proxies and Caching">
+<section title="Proxies and Caching" anchor="attack.proxies">
<t>
By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise of
@@ -2500,7 +2500,7 @@
</t>
</section>
-<section title="Denial of Service Attacks on Proxies">
+<section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
<t>
They exist. They are hard to defend against. Research continues.
Beware.
@@ -2508,7 +2508,7 @@
</section>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for RFC 822 <xref target="RFC822"/>. Similarly, it
@@ -3656,7 +3656,7 @@
</t>
</section>
-<section title="Compatibility with Previous Versions">
+<section title="Compatibility with Previous Versions" anchor="compatibility">
<t>
It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately
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=583299&r1=583298&r2=583299&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/rfc2616.html (original)
+++ labs/webarch/trunk/http/draft-fielding-http/rfc2616.html Tue Oct 9 14:03:07 2007
@@ -324,7 +324,7 @@
content: normal;
}
}
-</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Index" href="#rfc.index"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"><link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3"><link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4"><link rel="Chapter" title="5 Request" href="#rfc.section.5"><link rel="Chapter" title="6 Response" href="#rfc.section.6"><link rel="Chapter" title="7 Entity" href="#rfc.section.7"><link rel="Chapter" title="8 Connections" href="#rfc.section.8"><link rel="Chapter" title="9 Method Definitions" href="#rfc.section.9"><link rel="Chapter" title="10 Status Code Definitions" href="#rfc.section.10"><link rel="Chapter" title="11 Access Authentication" href="#rfc.section.11"><link rel="Chapter" title="12 Content Negotiation" href="#r
fc.section.12"><link rel="Chapter" title="13 Caching in HTTP" href="#rfc.section.13"><link rel="Chapter" title="14 Header Field Definitions" href="#rfc.section.14"><link rel="Chapter" title="15 Security Considerations" href="#rfc.section.15"><link rel="Chapter" title="16 Acknowledgments" href="#rfc.section.16"><link rel="Chapter" href="#rfc.section.17" title="17 References"><link rel="Appendix" title="19 Appendices" href="#rfc.section.19"><link rel="Appendix" title="20 Index" href="#rfc.section.20"><link rel="Alternate" title="Authorative ASCII version" href="http://www.ietf.org/rfc/rfc2616.txt"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.346, 2007/10/07 13:54:24, XSLT vendor: SAXON 8.5.1 from Saxonica http://www.saxonica.com/"><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"><meta name="DC.Creator" content="Fielding, R."><meta name="DC.Creator" content="Gettys, J."><meta name="DC.Creator" content="Mogul, J."><meta n
ame="DC.Creator" content="Frystyk, H."><meta name="DC.Creator" content="Masinter, L."><meta name="DC.Creator" content="Leach, P."><meta name="DC.Creator" content="Berners-Lee, T."><meta name="DC.Identifier" content="urn:ietf:rfc:2616"><meta name="DC.Date.Issued" scheme="ISO8601" content="1999-06"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068"><meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiat
ive since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."></head><body><table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"><tr><td class="header left">Network Working Group</td><td class="header right">R. Fielding</td></tr><tr><td class="header left">Request for Comments: 2616</td><td class="header right">UC Irvine</td></tr><tr><td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a></td><td class="header right">J. Gettys</td></tr><tr><td class="header left">Category: Standards Track</td><td class="header right">Compaq/W3C</td></tr><tr><td class="header left"></td><td class="header right">J. Mogul</td></tr><tr><td class="header left"></td><td class="header right">Compaq</td></tr><tr><td class="header left"></td><td class="header right">H. Frystyk</td></tr><tr><td class="header left"></td><td class="header right">W3C/MIT</td></tr><tr><td c
lass="header left"></td><td class="header right">L. Masinter</td></tr><tr><td class="header left"></td><td class="header right">Xerox</td></tr><tr><td class="header left"></td><td class="header right">P. Leach</td></tr><tr><td class="header left"></td><td class="header right">Microsoft</td></tr><tr><td class="header left"></td><td class="header right">T. Berners-Lee</td></tr><tr><td class="header left"></td><td class="header right">W3C/MIT</td></tr><tr><td class="header left"></td><td class="header right">June 1999</td></tr></table><p class="title">Hypertext Transfer Protocol -- HTTP/1.1</p><h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distributi
on of this memo is unlimited.</p><h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright © The Internet Society (1999). All Rights Reserved.</p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[47]</cite></a>. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</p> <p>HTTP has been in use by the World-Wide Web global information initiative since 1990. This
specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[33]</cite></a>.</p> <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="tocline1">1.1 <a href="#rfc.section.1.1">Purpose</a></li><li class="tocline1">1.2 <a href="#rfc.section.1.2">Requirements</a></li><li class="tocline1">1.3 <a href="#rfc.section.1.3">Terminology</a></li><li class="tocline1">1.4 <a href="#rfc.section.1.4">Overall Operation</a></li></ul></li><li class="tocline0">2. <a href="#rfc.section.2">Notational Conventions and Generic Grammar</a><ul class="toc"><li class="tocline1">2.1 <a href="#rfc.section.2.1">Augmen
ted BNF</a></li><li class="tocline1">2.2 <a href="#basic.rules">Basic Rules</a></li></ul></li><li class="tocline0">3. <a href="#rfc.section.3">Protocol Parameters</a><ul class="toc"><li class="tocline1">3.1 <a href="#http.version">HTTP Version</a></li><li class="tocline1">3.2 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc"><li class="tocline1">3.2.1 <a href="#general.syntax">General Syntax</a></li><li class="tocline1">3.2.2 <a href="#http.url">http URL</a></li><li class="tocline1">3.2.3 <a href="#uri.comparison">URI Comparison</a></li></ul></li><li class="tocline1">3.3 <a href="#rfc.section.3.3">Date/Time Formats</a><ul class="toc"><li class="tocline1">3.3.1 <a href="#full.date">Full Date</a></li><li class="tocline1">3.3.2 <a href="#rfc.section.3.3.2">Delta Seconds</a></li></ul></li><li class=
"tocline1">3.4 <a href="#character.sets">Character Sets</a><ul class="toc"><li class="tocline1">3.4.1 <a href="#missing.charset">Missing Charset</a></li></ul></li><li class="tocline1">3.5 <a href="#content.codings">Content Codings</a></li><li class="tocline1">3.6 <a href="#transfer.codings">Transfer Codings</a><ul class="toc"><li class="tocline1">3.6.1 <a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li></ul></li><li class="tocline1">3.7 <a href="#media.types">Media Types</a><ul class="toc"><li class="tocline1">3.7.1 <a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li><li class="tocline1">3.7.2 <a href="#multipart.types">Multipart Types</a></li></ul></li><li class="tocline1">3.8 <a href="#product.tokens">Product Tokens</a></li><li class="tocline1">3.9 <a
href="#quality.values">Quality Values</a></li><li class="tocline1">3.10 <a href="#language.tags">Language Tags</a></li><li class="tocline1">3.11 <a href="#entity.tags">Entity Tags</a></li><li class="tocline1">3.12 <a href="#range.units">Range Units</a></li></ul></li><li class="tocline0">4. <a href="#httpmessage">HTTP Message</a><ul class="toc"><li class="tocline1">4.1 <a href="#rfc.section.4.1">Message Types</a></li><li class="tocline1">4.2 <a href="#message.headers">Message Headers</a></li><li class="tocline1">4.3 <a href="#message.body">Message Body</a></li><li class="tocline1">4.4 <a href="#message.length">Message Length</a></li><li class="tocline1">4.5 <a href="#general.header.fields">General Header Fields</a></li></ul></li><li class="tocline0">5. <a href="#request">Request</a><ul class="toc"><li class="
tocline1">5.1 <a href="#request-line">Request-Line</a><ul class="toc"><li class="tocline1">5.1.1 <a href="#method">Method</a></li><li class="tocline1">5.1.2 <a href="#request-uri">Request-URI</a></li></ul></li><li class="tocline1">5.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li><li class="tocline1">5.3 <a href="#request.header.fields">Request Header Fields</a></li></ul></li><li class="tocline0">6. <a href="#response">Response</a><ul class="toc"><li class="tocline1">6.1 <a href="#status-line">Status-Line</a><ul class="toc"><li class="tocline1">6.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li></ul></li><li class="tocline1">6.2 <a href="#response.header.fields">Response Header Fields</a></li></ul></li><li class="tocline0">7. <a
href="#entity">Entity</a><ul class="toc"><li class="tocline1">7.1 <a href="#entity.header.fields">Entity Header Fields</a></li><li class="tocline1">7.2 <a href="#entity.body">Entity Body</a><ul class="toc"><li class="tocline1">7.2.1 <a href="#type">Type</a></li><li class="tocline1">7.2.2 <a href="#entity.length">Entity Length</a></li></ul></li></ul></li><li class="tocline0">8. <a href="#rfc.section.8">Connections</a><ul class="toc"><li class="tocline1">8.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc"><li class="tocline1">8.1.1 <a href="#rfc.section.8.1.1">Purpose</a></li><li class="tocline1">8.1.2 <a href="#rfc.section.8.1.2">Overall Operation</a><ul class="toc"><li class="tocline1">8.1.2.1 <a href="#rfc.section.8.1.2.1">Negotiation</a></li><li class="tocline1">8.1.2.2 <a href
="#pipelining">Pipelining</a></li></ul></li><li class="tocline1">8.1.3 <a href="#rfc.section.8.1.3">Proxy Servers</a></li><li class="tocline1">8.1.4 <a href="#rfc.section.8.1.4">Practical Considerations</a></li></ul></li><li class="tocline1">8.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc"><li class="tocline1">8.2.1 <a href="#rfc.section.8.2.1">Persistent Connections and Flow Control</a></li><li class="tocline1">8.2.2 <a href="#rfc.section.8.2.2">Monitoring Connections for Error Status Messages</a></li><li class="tocline1">8.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li><li class="tocline1">8.2.4 <a href="#rfc.section.8.2.4">Client Behavior if Server Prematurely Closes Connection</a></li></ul></li></ul></li><li class="tocline0">9. <a href="#method.definition
s">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.1 <a href="#safe.methods">Safe Methods</a></li><li class="tocline1">9.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li></ul></li><li class="tocline1">9.2 <a href="#OPTIONS">OPTIONS</a></li><li class="tocline1">9.3 <a href="#GET">GET</a></li><li class="tocline1">9.4 <a href="#HEAD">HEAD</a></li><li class="tocline1">9.5 <a href="#POST">POST</a></li><li class="tocline1">9.6 <a href="#PUT">PUT</a></li><li class="tocline1">9.7 <a href="#DELETE">DELETE</a></li><li class="tocline1">9.8 <a href="#TRACE">TRACE</a></li><li class="tocline1">9.9 <a href="#CONNECT">CONNECT</a></li></ul></li><li class="tocline0">10. &nbs
p;<a href="#status.codes">Status Code Definitions</a><ul class="toc"><li class="tocline1">10.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc"><li class="tocline1">10.1.1 <a href="#status.100">100 Continue</a></li><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.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><li class="tocline1">10.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li><li class="tocline1">10.2.5 <a href="#status.204">204 No Content</a></li><li class="tocline1">10.2.6 <a href="#statu
s.205">205 Reset Content</a></li><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.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><li class="tocline1">10.3.4 <a href="#status.303">303 See Other</a></li><li class="tocline1">10.3.5 <a href="#status.304">304 Not Modified</a></li><li class="tocline1">10.3.6 <a href="#status.305">305 Use Proxy</a></li><li class="tocline1">10.3.7 <a href="#status.306">306 (Unused)</a></li><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.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><li class="tocline1">10.4.4 <a href="#status.403">403 Forbidden</a></li><li class="tocline1">10.4.5 <a href="#status.404">404 Not Found</a></li><li class="tocline1">10.4.6 <a href="#status.405">405 Method Not Allowed</a></li><li class="tocline1">10.4.7 <a href="#status.406">406 Not Acceptable</a></li><li class="tocline1">10.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li><li class="tocline1">10.4.9 <a href="#status.408">408 Request Timeout</a></li><li class="tocline1">10.4.10&n
bsp; <a href="#status.409">409 Conflict</a></li><li class="tocline1">10.4.11 <a href="#status.410">410 Gone</a></li><li class="tocline1">10.4.12 <a href="#status.411">411 Length Required</a></li><li class="tocline1">10.4.13 <a href="#status.412">412 Precondition Failed</a></li><li class="tocline1">10.4.14 <a href="#status.413">413 Request Entity Too Large</a></li><li class="tocline1">10.4.15 <a href="#status.414">414 Request-URI Too Long</a></li><li class="tocline1">10.4.16 <a href="#status.415">415 Unsupported Media Type</a></li><li class="tocline1">10.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li><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="t
ocline1">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><li class="tocline1">10.5.4 <a href="#status.503">503 Service Unavailable</a></li><li class="tocline1">10.5.5 <a href="#status.504">504 Gateway Timeout</a></li><li class="tocline1">10.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li class="tocline0">11. <a href="#rfc.section.11">Access Authentication</a></li><li class="tocline0">12. <a href="#content.negotiation">Content Negotiation</a><ul class="toc"><li class="tocline1">12.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li><li class="tocline1">12.2 <a href="#rfc.section.12.2"
>Agent-driven Negotiation</a></li><li class="tocline1">12.3 <a href="#rfc.section.12.3">Transparent Negotiation</a></li></ul></li><li class="tocline0">13. <a href="#caching">Caching in HTTP</a><ul class="toc"><li class="tocline1">13.1 <a href="#rfc.section.13.1"></a><ul class="toc"><li class="tocline1">13.1.1 <a href="#cache.correctness">Cache Correctness</a></li><li class="tocline1">13.1.2 <a href="#warnings">Warnings</a></li><li class="tocline1">13.1.3 <a href="#rfc.section.13.1.3">Cache-control Mechanisms</a></li><li class="tocline1">13.1.4 <a href="#rfc.section.13.1.4">Explicit User Agent Warnings</a></li><li class="tocline1">13.1.5 <a href="#exceptions.to.the.rules.and.warnings">Exceptions to the Rules and Warnings</a></li><li class="tocline1">13.1.6 <a href="#rfc.section.13.1.6">Client-controlled Behavior</a></li></ul>
</li><li class="tocline1">13.2 <a href="#expiration.model">Expiration Model</a><ul class="toc"><li class="tocline1">13.2.1 <a href="#rfc.section.13.2.1">Server-Specified Expiration</a></li><li class="tocline1">13.2.2 <a href="#rfc.section.13.2.2">Heuristic Expiration</a></li><li class="tocline1">13.2.3 <a href="#age.calculations">Age Calculations</a></li><li class="tocline1">13.2.4 <a href="#expiration.calculations">Expiration Calculations</a></li><li class="tocline1">13.2.5 <a href="#disambiguating.expiration.values">Disambiguating Expiration Values</a></li><li class="tocline1">13.2.6 <a href="#disambiguating.multiple.responses">Disambiguating Multiple Responses</a></li></ul></li><li class="tocline1">13.3 <a href="#validation.model">Validation Model</a><ul class="toc"><li class="tocline1">13.3.1 <a href="#rfc.section.13.3.1
">Last-Modified Dates</a></li><li class="tocline1">13.3.2 <a href="#rfc.section.13.3.2">Entity Tag Cache Validators</a></li><li class="tocline1">13.3.3 <a href="#weak.and.strong.validators">Weak and Strong Validators</a></li><li class="tocline1">13.3.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="tocline1">13.3.5 <a href="#rfc.section.13.3.5">Non-validating Conditionals</a></li></ul></li><li class="tocline1">13.4 <a href="#response.cacheability">Response Cacheability</a></li><li class="tocline1">13.5 <a href="#rfc.section.13.5">Constructing Responses From Caches</a><ul class="toc"><li class="tocline1">13.5.1 <a href="#end-to-end.and.hop-by-hop.headers">End-to-end and Hop-by-hop Headers</a></li><li class="tocline1">13.5.2 <a href="#non-modifia
ble.headers">Non-modifiable Headers</a></li><li class="tocline1">13.5.3 <a href="#combining.headers">Combining Headers</a></li><li class="tocline1">13.5.4 <a href="#combining.byte.ranges">Combining Byte Ranges</a></li></ul></li><li class="tocline1">13.6 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li><li class="tocline1">13.7 <a href="#shared.and.non-shared.caches">Shared and Non-Shared Caches</a></li><li class="tocline1">13.8 <a href="#errors.or.incomplete.response.cache.behavior">Errors or Incomplete Response Cache Behavior</a></li><li class="tocline1">13.9 <a href="#rfc.section.13.9">Side Effects of GET and HEAD</a></li><li class="tocline1">13.10 <a href="#invalidation.after.updates.or.deletions">Invalidation After Updates or Deletions</a></li><li class="tocline1">13.11 <a href="#write-through.mandatory">Write
-Through Mandatory</a></li><li class="tocline1">13.12 <a href="#cache.replacement">Cache Replacement</a></li><li class="tocline1">13.13 <a href="#history.lists">History Lists</a></li></ul></li><li class="tocline0">14. <a href="#rfc.section.14">Header Field Definitions</a><ul class="toc"><li class="tocline1">14.1 <a href="#header.accept">Accept</a></li><li class="tocline1">14.2 <a href="#header.accept-charset">Accept-Charset</a></li><li class="tocline1">14.3 <a href="#header.accept-encoding">Accept-Encoding</a></li><li class="tocline1">14.4 <a href="#header.accept-language">Accept-Language</a></li><li class="tocline1">14.5 <a href="#header.accept-ranges">Accept-Ranges</a></li><li class="tocline1">14.6 <a href="#header.age">Age</a></li><li class="tocline1">14.7 <a href="#header.allow">Allow</a></li><li class="
tocline1">14.8 <a href="#header.authorization">Authorization</a></li><li class="tocline1">14.9 <a href="#header.cache-control">Cache-Control</a><ul class="toc"><li class="tocline1">14.9.1 <a href="#what.is.cacheable">What is Cacheable</a></li><li class="tocline1">14.9.2 <a href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></li><li class="tocline1">14.9.3 <a href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></li><li class="tocline1">14.9.4 <a href="#cache.revalidation.and.reload.controls">Cache Revalidation and Reload Controls</a></li><li class="tocline1">14.9.5 <a href="#no-transform.directive">No-Transform Directive</a></li><li class="tocline1">14.9.6 <a href="#cache.control.extensions">Cache Control Extensions</a></li></ul></li><li class="tocline1">14.10  
; <a href="#header.connection">Connection</a></li><li class="tocline1">14.11 <a href="#header.content-encoding">Content-Encoding</a></li><li class="tocline1">14.12 <a href="#header.content-language">Content-Language</a></li><li class="tocline1">14.13 <a href="#header.content-length">Content-Length</a></li><li class="tocline1">14.14 <a href="#header.content-location">Content-Location</a></li><li class="tocline1">14.15 <a href="#header.content-md5">Content-MD5</a></li><li class="tocline1">14.16 <a href="#header.content-range">Content-Range</a></li><li class="tocline1">14.17 <a href="#header.content-type">Content-Type</a></li><li class="tocline1">14.18 <a href="#header.date">Date</a><ul class="toc"><li class="tocline1">14.18.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li></ul></li>
<li class="tocline1">14.19 <a href="#header.etag">ETag</a></li><li class="tocline1">14.20 <a href="#header.expect">Expect</a></li><li class="tocline1">14.21 <a href="#header.expires">Expires</a></li><li class="tocline1">14.22 <a href="#header.from">From</a></li><li class="tocline1">14.23 <a href="#header.host">Host</a></li><li class="tocline1">14.24 <a href="#header.if-match">If-Match</a></li><li class="tocline1">14.25 <a href="#header.if-modified-since">If-Modified-Since</a></li><li class="tocline1">14.26 <a href="#header.if-none-match">If-None-Match</a></li><li class="tocline1">14.27 <a href="#header.if-range">If-Range</a></li><li class="tocline1">14.28 <a href="#header.if-unmodified-since">If-Unmodified-Since</a></li><li class="tocline1">14.29 <a href="#header.last-modified">Last-Modified
</a></li><li class="tocline1">14.30 <a href="#header.location">Location</a></li><li class="tocline1">14.31 <a href="#header.max-forwards">Max-Forwards</a></li><li class="tocline1">14.32 <a href="#header.pragma">Pragma</a></li><li class="tocline1">14.33 <a href="#header.proxy-authenticate">Proxy-Authenticate</a></li><li class="tocline1">14.34 <a href="#header.proxy-authorization">Proxy-Authorization</a></li><li class="tocline1">14.35 <a href="#header.range">Range</a><ul class="toc"><li class="tocline1">14.35.1 <a href="#byte.ranges">Byte Ranges</a></li><li class="tocline1">14.35.2 <a href="#rfc.section.14.35.2">Range Retrieval Requests</a></li></ul></li><li class="tocline1">14.36 <a href="#header.referer">Referer</a></li><li class="tocline1">14.37 <a href="#header.retry-after">Retry-After</a></li><li class="t
ocline1">14.38 <a href="#header.server">Server</a></li><li class="tocline1">14.39 <a href="#header.te">TE</a></li><li class="tocline1">14.40 <a href="#header.trailer">Trailer</a></li><li class="tocline1">14.41 <a href="#header.transfer-encoding">Transfer-Encoding</a></li><li class="tocline1">14.42 <a href="#header.upgrade">Upgrade</a></li><li class="tocline1">14.43 <a href="#header.user-agent">User-Agent</a></li><li class="tocline1">14.44 <a href="#header.vary">Vary</a></li><li class="tocline1">14.45 <a href="#header.via">Via</a></li><li class="tocline1">14.46 <a href="#header.warning">Warning</a></li><li class="tocline1">14.47 <a href="#header.www-authenticate">WWW-Authenticate</a></li></ul></li><li class="tocline0">15. <a href="#rfc.section.15">Security Considerations</a><ul class="toc"><l
i class="tocline1">15.1 <a href="#rfc.section.15.1">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.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="#rfc.section.15.2">Attacks Based On File and Path Names</a></li><li class="tocline1">15.3 <a href="#rfc.section.15.3">DNS Spoofing</a></li><li class="tocline1">15.4 <a href="#rfc.section.15.4">Location Headers and Spoofing</a></li><li class="tocl
ine1">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="#rfc.section.15.7">Proxies and Caching</a><ul class="toc"><li class="tocline1">15.7.1 <a href="#rfc.section.15.7.1">Denial of Service Attacks on Proxies</a></li></ul></li></ul></li><li class="tocline0">16. <a href="#rfc.section.16">Acknowledgments</a></li><li class="tocline0">17. <a href="#rfc.references">References</a></li><li class="tocline0">18. <a href="#rfc.authors">Authors' Addresses</a></li><li class="tocline0">19. <a href="#rfc.section.19">Appendices</a><ul class="toc"><li class="tocline1">19.1 <a href="#internet.media.type.http">Internet Media Type message/http and application/http</a></li><li c
lass="tocline1">19.2 <a href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></li><li class="tocline1">19.3 <a href="#tolerant.applications">Tolerant Applications</a></li><li class="tocline1">19.4 <a href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc"><li class="tocline1">19.4.1 <a href="#rfc.section.19.4.1">MIME-Version</a></li><li class="tocline1">19.4.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li><li class="tocline1">19.4.3 <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li><li class="tocline1">19.4.4 <a href="#rfc.section.19.4.4">Introduction of Content-Encoding</a></li><li class="tocline1">19.4.5 <a href="#no.content-transfer-encoding">No Content-Transfer-En
coding</a></li><li class="tocline1">19.4.6 <a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li><li class="tocline1">19.4.7 <a href="#rfc.section.19.4.7">MHTML and Line Length Limitations</a></li></ul></li><li class="tocline1">19.5 <a href="#rfc.section.19.5">Additional Features</a><ul class="toc"><li class="tocline1">19.5.1 <a href="#content-disposition">Content-Disposition</a></li></ul></li><li class="tocline1">19.6 <a href="#rfc.section.19.6">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.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><li class="tocline1">19.6.2 
; <a href="#compatibility.with.http.1.0.persistent.connections">Compatibility with HTTP/1.0 Persistent Connections</a></li><li class="tocline1">19.6.3 <a href="#changes.from.rfc.2068">Changes from RFC 2068</a></li></ul></li></ul></li><li class="tocline0">20. <a href="#rfc.section.20">Index</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><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> Purpose</h2><p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol f
or raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[6]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.</p><p id="rfc.section.1.1.p.2">This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its
features.</p><p id="rfc.section.1.1.p.3">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.2"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[47]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[3]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[4]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[20]</cite></a>, for indicating t
he resource to which a method is to be applied. Messages are passed in a format similar to that used by Internet mail <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[9]</cite></a> as defined by the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[7]</cite></a>.</p><p id="rfc.section.1.1.p.4">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[16]</cite></a>, NNTP <a href="#RFC977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[13]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[18]</cite></a>, Gopher <a href="#
RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[2]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[10]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.</p><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> Requirements</h2><p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[34]</cite></a>.</p><p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp
14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant."</p><h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> Terminology</h2><p id="rfc.section.1.3.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.</p><p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span> <dfn>connection</dfn> </p><dl class="empty"><dd>A transport layer virtual circuit established between two programs for the purpose of communication.</dd></dl><p id="rfc.section.1.3
.p.3"> <span id="rfc.iref.m.1"></span> <dfn>message</dfn> </p><dl class="empty"><dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#httpmessage" title="HTTP Message">Section 4</a> and transmitted via the connection.</dd></dl><p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span> <dfn>request</dfn> </p><dl class="empty"><dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>.</dd></dl><p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span> <dfn>response</dfn> </p><dl class="empty"><dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>.</dd></dl><p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span> <dfn>resource</dfn> </p><dl class="empty"><dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section
3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.</dd></dl><p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span> <dfn>entity</dfn> </p><dl class="empty"><dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in <a href="#entity" title="Entity">Section 7</a>.</dd></dl><p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span> <dfn>representation</dfn> </p><dl class="empty"><dd>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. There may exist multiple representations associated with a particular response status.</dd></dl><p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span> <dfn>content ne
gotiation</dfn> </p><dl class="empty"><dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. The representation of entities in any response can be negotiated (including error responses).</dd></dl><p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn> </p><dl class="empty"><dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.</dd></dl><p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span> <dfn>client</dfn> </p><dl class="empty"><dd>A program that establishes connections for the purpose of sending requests.</dd></dl><p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span> <dfn>user agent</dfn> </p
><dl class="empty"><dd>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.</dd></dl><p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span> <dfn>server</dfn> </p><dl class="empty"><dd>An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.</dd></dl><p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span> <dfn>origin server</dfn> </p><dl class="empty"><dd>The server on which a given resource resides or is to be created.</dd></dl><p id="rfc.section.1.3.p.15"> <span id="rfc.iref.p.
1"></span> <dfn>proxy</dfn> </p><dl class="empty"><dd>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy <em class="bcp14">MUST</em> implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.</dd></dl><p id="rfc.section.1.3.p.16"> <span id="rfc.iref.g.1"></sp
an> <dfn>gateway</dfn> </p><dl class="empty"><dd>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.</dd></dl><p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span> <dfn>tunnel</dfn> </p><dl class="empty"><dd>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.</dd></dl><p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span> <dfn>cache</dfn> </p><dl class="empty"><dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses i
n order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.</dd></dl><p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span> <dfn>cacheable</dfn> </p><dl class="empty"><dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in <a href="#caching" title="Caching in HTTP">Section 13</a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.</dd></dl><p id="rfc.section.1.3.p.20"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> </p><dl class="empty"><dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more prox
ies. A response is also first-hand if its validity has just been checked directly with the origin server.</dd></dl><p id="rfc.section.1.3.p.21"> <span id="rfc.iref.e.2"></span> <dfn>explicit expiration time</dfn> </p><dl class="empty"><dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd></dl><p id="rfc.section.1.3.p.22"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> </p><dl class="empty"><dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd></dl><p id="rfc.section.1.3.p.23"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> </p><dl class="empty"><dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd></dl><p id="rfc.section.1.3.p.24"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> </p><dl class="empty"><dd>The length of time between the generation of a re
sponse and its expiration time.</dd></dl><p id="rfc.section.1.3.p.25"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> </p><dl class="empty"><dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd></dl><p id="rfc.section.1.3.p.26"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> </p><dl class="empty"><dd>A response is stale if its age has passed its freshness lifetime.</dd></dl><p id="rfc.section.1.3.p.27"> <span id="rfc.iref.s.3"></span> <dfn>semantically transparent</dfn> </p><dl class="empty"><dd>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.</dd></dl><p id="rfc.section.1.3.p.28"> <
span id="rfc.iref.v.2"></span> <dfn>validator</dfn> </p><dl class="empty"><dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent copy of an entity.</dd></dl><p id="rfc.section.1.3.p.29"> <span id="rfc.iref.u.2"></span> <span id="rfc.iref.d.1"></span> <dfn>upstream</dfn>/<dfn>downstream</dfn> </p><dl class="empty"><dd>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</dd></dl><p id="rfc.section.1.3.p.30"> <span id="rfc.iref.i.1"></span> <span id="rfc.iref.o.2"></span> <dfn>inbound</dfn>/<dfn>outbound</dfn> </p><dl class="empty"><dd>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"</dd></dl><h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> Overall Operation</h2><p id="rfc.section.1.4.p.1">The H
TTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. The relationship between HTTP and MIME is described in <a href="#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix 19.4</a>.</p><p id="rfc.section.1.4.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA)
and the origin server (O).</p><div id="rfc.figure.u.1"></div><pre class="drawing"> request chain ------------------------>
[... 73 lines stripped ...]
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=583299&r1=583298&r2=583299&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/rfc2616.xml Tue Oct 9 14:03:07 2007
@@ -147,9 +147,9 @@
</abstract>
</front>
<middle>
-<section title="Introduction">
+<section title="Introduction" anchor="introduction">
-<section title="Purpose">
+<section title="Purpose" anchor="intro.purpose">
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
@@ -192,7 +192,7 @@
</t>
</section>
-<section title="Requirements">
+<section title="Requirements" anchor="intro.requirements">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ -209,7 +209,7 @@
</t>
</section>
-<section title="Terminology">
+<section title="Terminology" anchor="intro.terminology">
<t>
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
@@ -555,7 +555,7 @@
</t>
</section>
-<section title="Overall Operation">
+<section title="Overall Operation" anchor="intro.overall.operation">
<t>
The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and
@@ -665,9 +665,9 @@
</section>
</section>
-<section title="Notational Conventions and Generic Grammar">
+<section title="Notational Conventions and Generic Grammar" anchor="notation">
-<section title="Augmented BNF">
+<section title="Augmented BNF" anchor="notation.abnf">
<t>
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
@@ -936,7 +936,7 @@
</section>
</section>
-<section title="Protocol Parameters">
+<section title="Protocol Parameters" anchor="protocol.parameters">
<section title="HTTP Version" anchor="http.version">
<t>
@@ -1103,7 +1103,7 @@
</section>
</section>
-<section title="Date/Time Formats">
+<section title="Date/Time Formats" anchor="date.time.formats">
<section title="Full Date" anchor="full.date">
<t>
@@ -1725,7 +1725,7 @@
<section title="HTTP Message" anchor="httpmessage">
-<section title="Message Types">
+<section title="Message Types" anchor="message.types">
<t>
HTTP messages consist of requests from client to server and responses
from server to client.
@@ -2449,11 +2449,11 @@
-<section title="Connections">
+<section title="Connections" anchor="connections">
<section title="Persistent Connections" anchor="persistent.connections">
-<section title="Purpose">
+<section title="Purpose" anchor="persistent.purpose">
<t>
Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers
@@ -2504,7 +2504,7 @@
</t>
</section>
-<section title="Overall Operation">
+<section title="Overall Operation" anchor="persistent.overall">
<t>
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
@@ -2520,7 +2520,7 @@
connection.
</t>
-<section title="Negotiation">
+<section title="Negotiation" anchor="persistent.negotiation">
<t>
An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including
@@ -2582,7 +2582,7 @@
</section>
</section>
-<section title="Proxy Servers">
+<section title="Proxy Servers" anchor="persistent.proxy">
<t>
It is especially important that proxies correctly implement the
properties of the Connection header field as specified in <xref target="header.connection"/>.
@@ -2601,7 +2601,7 @@
</t>
</section>
-<section title="Practical Considerations">
+<section title="Practical Considerations" anchor="persistent.practical">
<t>
Servers will usually have some time-out value beyond which they will
no longer maintain an inactive connection. Proxy servers might make
@@ -2658,7 +2658,7 @@
<section title="Message Transmission Requirements" anchor="message.transmission.requirements">
-<section title="Persistent Connections and Flow Control">
+<section title="Persistent Connections and Flow Control" anchor="persistent.flow">
<t>
HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's
flow control mechanisms to resolve temporary overloads, rather than
@@ -2667,7 +2667,7 @@
</t>
</section>
-<section title="Monitoring Connections for Error Status Messages">
+<section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
<t>
An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor
the network connection for an error status while it is transmitting
@@ -2791,7 +2791,7 @@
</t>
</section>
-<section title="Client Behavior if Server Prematurely Closes Connection">
+<section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature">
<t>
If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header field with the
@@ -5698,7 +5698,7 @@
-<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
@@ -8777,7 +8777,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
@@ -8786,7 +8786,7 @@
some suggestions for reducing security risks.
</t>
-<section title="Personal Information">
+<section title="Personal Information" anchor="personal.information">
<t>
HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption
@@ -8930,7 +8930,7 @@
</section>
</section>
-<section title="Attacks Based On File and Path Names">
+<section title="Attacks Based On File and Path Names" anchor="attack.pathname">
<t>
Implementations of HTTP origin servers &SHOULD; be careful to restrict
the documents returned by HTTP requests to be only those that were
@@ -8951,7 +8951,7 @@
</t>
</section>
-<section title="DNS Spoofing">
+<section title="DNS Spoofing" anchor="dns.spoofing">
<t>
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
@@ -9040,7 +9040,7 @@
</t>
</section>
-<section title="Proxies and Caching">
+<section title="Proxies and Caching" anchor="attack.proxies">
<t>
By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise of
@@ -9085,7 +9085,7 @@
cryptography is beyond the scope of the HTTP/1.1 specification.
</t>
-<section title="Denial of Service Attacks on Proxies">
+<section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">
<t>
They exist. They are hard to defend against. Research continues.
Beware.
@@ -9094,7 +9094,7 @@
</section>
</section>
-<section title="Acknowledgments">
+<section title="Acknowledgments" anchor="ack">
<t>
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for RFC 822 <xref target="RFC822"/>. Similarly, it
@@ -11074,7 +11074,7 @@
</section>
</section>
-<section title="Compatibility with Previous Versions">
+<section title="Compatibility with Previous Versions" anchor="compatibility">
<t>
It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org