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 01:56:03 UTC
svn commit: r583326 [3/14] - /labs/webarch/trunk/http/draft-fielding-http/
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=583326&r1=583325&r2=583326&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 16:56:02 2007
@@ -1,6 +1,9 @@
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html lang="en"><head profile="http://www.w3.org/2006/03/hcard"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>HTTP/1.1, part 2: Semantics</title><style type="text/css" title="Xml2Rfc (sans serif)">
+<html lang="en">
+ <head profile="http://www.w3.org/2006/03/hcard">
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <title>HTTP/1.1, part 2: Semantics</title><style type="text/css" title="Xml2Rfc (sans serif)">
a {
text-decoration: none;
}
@@ -324,22 +327,305 @@
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 Product Tokens" href="#rfc.section.2"><link rel="Chapter" title="3 Request" href="#rfc.section.3"><link rel="Chapter" title="4 Response" href="#rfc.section.4"><link rel="Chapter" title="5 Entity" href="#rfc.section.5"><link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6"><link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7"><link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8"><link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"><link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"><link rel="Chapter" href="#rfc.section.11" title="11 References"><link rel="Appendix" title="A Changes from HTTP/1.0" href="#rfc.section.A"><li
nk rel="Appendix" title="B Changes from RFC 2068" href="#rfc.section.B"><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 name="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:id:draft-fielding-http-p2-semantics-00"><meta name="DC.Date.Issued" scheme="ISO8601" content="2007-09"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"><meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2617"><meta name="DC.De
scription.Abstract" content="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. This document is Part 2 of the eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."></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">Internet Draft</td><td class="header right">UC Irvine</td></tr><tr><td class="header left">
- <draft-fielding-http-p2-semantics-00>
- </td><td class="header right">J. Gettys</td></tr><tr><td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a>,
- <a href="http://tools.ietf.org/html/rfc2616">2616</a>,
- <a href="http://tools.ietf.org/html/rfc2617">2617</a> (if approved)</td><td class="header right">Compaq/W3C</td></tr><tr><td class="header left">Intended status: Standards Track</td><td class="header right">J. Mogul</td></tr><tr><td class="header left">Expires: March 2008</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 class="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">September 2007</td></tr></table><p class="title">HTTP/1.1, part 2: Semantics<br><span class="filename">draft-fielding-http-p2-semantics-00</span></p><h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.</p><p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.</p><p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as referenc
e material or to cite them other than as “work in progress”.</p><p>The list of current Internet-Drafts can be accessed at <<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>>.</p><p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>.</p><p>This Internet-Draft will expire in March 2008.</p><h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1><p>Copyright © The IETF Trust (2007). 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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the eight-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.</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></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"><li class="tocline1">3.1.1 <a href="#method">Method</a></li><li class="tocline1">3.1.2 <a href="#request-uri">Request-URI</a></li></ul></li><li class="tocline1">3.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Requ
est</a></li><li class="tocline1">3.3 <a href="#request.header.fields">Request Header Fields</a></li></ul></li><li class="tocline0">4. <a href="#response">Response</a><ul class="toc"><li class="tocline1">4.1 <a href="#status-line">Status-Line</a><ul class="toc"><li class="tocline1">4.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li></ul></li><li class="tocline1">4.2 <a href="#response.header.fields">Response Header Fields</a></li></ul></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.1 <a href="#safe.methods">Safe Methods</a></li><li class="tocline1">6.1.2 &
nbsp;<a href="#idempotent.methods">Idempotent Methods</a></li></ul></li><li class="tocline1">6.2 <a href="#OPTIONS">OPTIONS</a></li><li class="tocline1">6.3 <a href="#GET">GET</a></li><li class="tocline1">6.4 <a href="#HEAD">HEAD</a></li><li class="tocline1">6.5 <a href="#POST">POST</a></li><li class="tocline1">6.6 <a href="#PUT">PUT</a></li><li class="tocline1">6.7 <a href="#DELETE">DELETE</a></li><li class="tocline1">6.8 <a href="#TRACE">TRACE</a></li><li class="tocline1">6.9 <a href="#CONNECT">CONNECT</a></li></ul></li><li class="tocline0">7. <a href="#status.codes">Status Code Definitions</a><ul class="toc"><li class="tocline1">7.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc"><li class="tocline1">7.1.1 <a href="#status.100">100 Continue</a></li><li class="tocline1">7.1.2&nb
sp; <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.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><li class="tocline1">7.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li><li class="tocline1">7.2.5 <a href="#status.204">204 No Content</a></li><li class="tocline1">7.2.6 <a href="#status.205">205 Reset Content</a></li><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.1 <a href="#st
atus.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><li class="tocline1">7.3.4 <a href="#status.303">303 See Other</a></li><li class="tocline1">7.3.5 <a href="#status.304">304 Not Modified</a></li><li class="tocline1">7.3.6 <a href="#status.305">305 Use Proxy</a></li><li class="tocline1">7.3.7 <a href="#status.306">306 (Unused)</a></li><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.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><li class="tocline1">7.4.4 <a href="#status.403">403 Forbidden</a></li><li class="tocline1">7.4.5 <a href="#status.404">404 Not Found</a></li><li class="tocline1">7.4.6 <a href="#status.405">405 Method Not Allowed</a></li><li class="tocline1">7.4.7 <a href="#status.406">406 Not Acceptable</a></li><li class="tocline1">7.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li><li class="tocline1">7.4.9 <a href="#status.408">408 Request Timeout</a></li><li class="tocline1">7.4.10 <a href="#status.409">409 Conflict</a></li><li class="tocline1">7.4.11 <a href="#status.410">410 Gone</a></li><li class="tocline1">7.4.12 <a href="#status.411">411 Length Required</a></li><li class="tocline1">7.4.13 <a href="#status.412">412 Preconditio
n Failed</a></li><li class="tocline1">7.4.14 <a href="#status.413">413 Request Entity Too Large</a></li><li class="tocline1">7.4.15 <a href="#status.414">414 Request-URI Too Long</a></li><li class="tocline1">7.4.16 <a href="#status.415">415 Unsupported Media Type</a></li><li class="tocline1">7.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li><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.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><li class="tocline1">7.5.4 <a href="#stat
us.503">503 Service Unavailable</a></li><li class="tocline1">7.5.5 <a href="#status.504">504 Gateway Timeout</a></li><li class="tocline1">7.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li></ul></li></ul></li><li class="tocline0">8. <a href="#rfc.section.8">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><li class="tocline1">8.4 <a href="#header.host">Host</a></li><li class="tocline1">8.5 <a href="#header.location">Location</a></li><li class="tocline1">8.6 <a href="#header.max-forwards">Max-Forwards</a></li><li class="tocline1">8.7 <a href="#header.referer">Referer</a></li><li class="tocline1">8.8 &n
bsp;<a href="#header.retry-after">Retry-After</a></li><li class="tocline1">8.9 <a href="#header.server">Server</a></li><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="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></ul></li><li class="tocline0">10. <a href="#rfc.section.10">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.&n
bsp; <a href="#rfc.section.A">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><li class="tocline0">B. <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><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><p id="rfc.section.1.p.2">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 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 [Part 3].</p><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1><p id="rfc.section.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white space. By convention, the products are listed in order of their significance for identifying the applicatio
n.</p><div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> product = token ["/" product-version]
+</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 Product Tokens" href="#rfc.section.2">
+ <link rel="Chapter" title="3 Request" href="#rfc.section.3">
+ <link rel="Chapter" title="4 Response" href="#rfc.section.4">
+ <link rel="Chapter" title="5 Entity" href="#rfc.section.5">
+ <link rel="Chapter" title="6 Method Definitions" href="#rfc.section.6">
+ <link rel="Chapter" title="7 Status Code Definitions" href="#rfc.section.7">
+ <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8">
+ <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9">
+ <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10">
+ <link rel="Chapter" href="#rfc.section.11" title="11 References">
+ <link rel="Appendix" title="A Changes from HTTP/1.0" href="#rfc.section.A">
+ <link rel="Appendix" title="B Changes from RFC 2068" href="#rfc.section.B">
+ <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.346, 2007/10/07 13:54:24, XSLT vendor: SAXON 8.9 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 name="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:id:draft-fielding-http-p2-semantics-00">
+ <meta name="DC.Date.Issued" scheme="ISO8601" content="2007-09">
+ <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068">
+ <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
+ <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2617">
+ <meta name="DC.Description.Abstract" content="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. This document is Part 2 of the eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC 2617. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
+ </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">Internet Draft</td>
+ <td class="header right">UC Irvine</td>
+ </tr>
+ <tr>
+ <td class="header left">
+ <draft-fielding-http-p2-semantics-00>
+
+ </td>
+ <td class="header right">J. Gettys</td>
+ </tr>
+ <tr>
+ <td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a>,
+ <a href="http://tools.ietf.org/html/rfc2616">2616</a>,
+ <a href="http://tools.ietf.org/html/rfc2617">2617</a> (if approved)
+ </td>
+ <td class="header right">Compaq/W3C</td>
+ </tr>
+ <tr>
+ <td class="header left">Intended status: Standards Track</td>
+ <td class="header right">J. Mogul</td>
+ </tr>
+ <tr>
+ <td class="header left">Expires: March 2008</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 class="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">September 2007</td>
+ </tr>
+ </table>
+ <p class="title">HTTP/1.1, part 2: Semantics<br><span class="filename">draft-fielding-http-p2-semantics-00</span></p>
+ <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
+ <p>This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft,
+ each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed,
+ and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
+ </p>
+ <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note
+ that other groups may also distribute working documents as Internet-Drafts.
+ </p>
+ <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as âwork
+ in progressâ.
+ </p>
+ <p>The list of current Internet-Drafts can be accessed at <<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>>.
+ </p>
+ <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>.
+ </p>
+ <p>This Internet-Draft will expire in March 2008.</p>
+ <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
+ <p>Copyright © The IETF Trust (2007). 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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the
+ eight-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, updates RFC 2616 and RFC
+ 2617. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status
+ codes, and response-header fields.
+ </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></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">
+ <li class="tocline1">3.1.1 <a href="#method">Method</a></li>
+ <li class="tocline1">3.1.2 <a href="#request-uri">Request-URI</a></li>
+ </ul>
+ </li>
+ <li class="tocline1">3.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
+ <li class="tocline1">3.3 <a href="#request.header.fields">Request Header Fields</a></li>
+ </ul>
+ </li>
+ <li class="tocline0">4. <a href="#response">Response</a><ul class="toc">
+ <li class="tocline1">4.1 <a href="#status-line">Status-Line</a><ul class="toc">
+ <li class="tocline1">4.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>
+ </ul>
+ </li>
+ <li class="tocline1">4.2 <a href="#response.header.fields">Response Header Fields</a></li>
+ </ul>
+ </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.1 <a href="#safe.methods">Safe Methods</a></li>
+ <li class="tocline1">6.1.2 <a href="#idempotent.methods">Idempotent Methods</a></li>
+ </ul>
+ </li>
+ <li class="tocline1">6.2 <a href="#OPTIONS">OPTIONS</a></li>
+ <li class="tocline1">6.3 <a href="#GET">GET</a></li>
+ <li class="tocline1">6.4 <a href="#HEAD">HEAD</a></li>
+ <li class="tocline1">6.5 <a href="#POST">POST</a></li>
+ <li class="tocline1">6.6 <a href="#PUT">PUT</a></li>
+ <li class="tocline1">6.7 <a href="#DELETE">DELETE</a></li>
+ <li class="tocline1">6.8 <a href="#TRACE">TRACE</a></li>
+ <li class="tocline1">6.9 <a href="#CONNECT">CONNECT</a></li>
+ </ul>
+ </li>
+ <li class="tocline0">7. <a href="#status.codes">Status Code Definitions</a><ul class="toc">
+ <li class="tocline1">7.1 <a href="#status.1xx">Informational 1xx</a><ul class="toc">
+ <li class="tocline1">7.1.1 <a href="#status.100">100 Continue</a></li>
+ <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.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>
+ <li class="tocline1">7.2.4 <a href="#status.203">203 Non-Authoritative Information</a></li>
+ <li class="tocline1">7.2.5 <a href="#status.204">204 No Content</a></li>
+ <li class="tocline1">7.2.6 <a href="#status.205">205 Reset Content</a></li>
+ <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.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>
+ <li class="tocline1">7.3.4 <a href="#status.303">303 See Other</a></li>
+ <li class="tocline1">7.3.5 <a href="#status.304">304 Not Modified</a></li>
+ <li class="tocline1">7.3.6 <a href="#status.305">305 Use Proxy</a></li>
+ <li class="tocline1">7.3.7 <a href="#status.306">306 (Unused)</a></li>
+ <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.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>
+ <li class="tocline1">7.4.4 <a href="#status.403">403 Forbidden</a></li>
+ <li class="tocline1">7.4.5 <a href="#status.404">404 Not Found</a></li>
+ <li class="tocline1">7.4.6 <a href="#status.405">405 Method Not Allowed</a></li>
+ <li class="tocline1">7.4.7 <a href="#status.406">406 Not Acceptable</a></li>
+ <li class="tocline1">7.4.8 <a href="#status.407">407 Proxy Authentication Required</a></li>
+ <li class="tocline1">7.4.9 <a href="#status.408">408 Request Timeout</a></li>
+ <li class="tocline1">7.4.10 <a href="#status.409">409 Conflict</a></li>
+ <li class="tocline1">7.4.11 <a href="#status.410">410 Gone</a></li>
+ <li class="tocline1">7.4.12 <a href="#status.411">411 Length Required</a></li>
+ <li class="tocline1">7.4.13 <a href="#status.412">412 Precondition Failed</a></li>
+ <li class="tocline1">7.4.14 <a href="#status.413">413 Request Entity Too Large</a></li>
+ <li class="tocline1">7.4.15 <a href="#status.414">414 Request-URI Too Long</a></li>
+ <li class="tocline1">7.4.16 <a href="#status.415">415 Unsupported Media Type</a></li>
+ <li class="tocline1">7.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li>
+ <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.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>
+ <li class="tocline1">7.5.4 <a href="#status.503">503 Service Unavailable</a></li>
+ <li class="tocline1">7.5.5 <a href="#status.504">504 Gateway Timeout</a></li>
+ <li class="tocline1">7.5.6 <a href="#status.505">505 HTTP Version Not Supported</a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li class="tocline0">8. <a href="#rfc.section.8">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>
+ <li class="tocline1">8.4 <a href="#header.host">Host</a></li>
+ <li class="tocline1">8.5 <a href="#header.location">Location</a></li>
+ <li class="tocline1">8.6 <a href="#header.max-forwards">Max-Forwards</a></li>
+ <li class="tocline1">8.7 <a href="#header.referer">Referer</a></li>
+ <li class="tocline1">8.8 <a href="#header.retry-after">Retry-After</a></li>
+ <li class="tocline1">8.9 <a href="#header.server">Server</a></li>
+ <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="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>
+ </ul>
+ </li>
+ <li class="tocline0">10. <a href="#rfc.section.10">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="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>
+ <li class="tocline0">B. <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>
+ <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>
+ <p id="rfc.section.1.p.2">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 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 [Part 3].
+ </p>
+ <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h1>
+ <p id="rfc.section.2.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields
+ using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white
+ space. By convention, the products are listed in order of their significance for identifying the application.
+ </p>
+ <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> product = token ["/" product-version]
product-version = token
-</pre><p id="rfc.section.2.p.3">Examples:</p><div id="rfc.figure.u.2"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+</pre><p id="rfc.section.2.p.3">Examples:</p>
+ <div id="rfc.figure.u.2"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
-</pre><p id="rfc.section.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).</p><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request" href="#request">Request</a></h1><p id="rfc.section.3.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.</p><div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span> Request = Request-Line ; <a href="#
request-line" title="Request-Line">Section 3.1</a>
+</pre><p id="rfc.section.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).
+ </p>
+ <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="request" href="#request">Request</a></h1>
+ <p id="rfc.section.3.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the
+ resource, the identifier of the resource, and the protocol version in use.
+ </p>
+ <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span> Request = Request-Line ; <a href="#request-line" title="Request-Line">Section 3.1</a>
*(( general-header ; [Part 1]
| request-header ; <a href="#request.header.fields" title="Request Header Fields">Section 3.3</a>
| entity-header ) CRLF) ; [Part 3]
CRLF
[ message-body ] ; [Part 1]
-</pre><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2><p id="rfc.section.3.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.</p><div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF
-</pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="method" href="#method">Method</a></h3><p id="rfc.section.3.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p><div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 6.2</a>
+</pre><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2>
+ <p id="rfc.section.3.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The
+ elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
+ </p>
+ <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span> Request-Line = Method SP Request-URI SP HTTP-Version CRLF
+</pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="method" href="#method">Method</a></h3>
+ <p id="rfc.section.3.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
+ <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 6.2</a>
| "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 6.3</a>
| "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 6.4</a>
| "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 6.5</a>
@@ -349,12 +635,75 @@
| "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 6.9</a>
| extension-method
extension-method = token
-</pre><p id="rfc.section.3.1.1.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 8.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title
="Method Definitions">Section 6</a>.</p><h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3><p id="rfc.section.3.1.2.p.1">The Request-URI is a Uniform Resource Identifier ([Part 1]) and identifies the resource upon which to apply the request.</p><div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span> Request-URI = "*" | absoluteURI | abs_path | authority
-</pre><p id="rfc.section.3.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be</p><div id="rfc.figure.u.7"></div><pre class="text"> OPTIONS * HTTP/1.1
-</pre><p id="rfc.section.3.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:</p><div id="rfc.figure.u.8"></div><pre class="text"> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
-</pre><p id="rfc.section.3.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.</p><p id="rfc.section.3.1.2.p.8">The authority form is only used by the CONNECT method (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 6.9</a>).</p><p id="rfc.section.3.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see [Part 1], abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www
.w3.org" and send the lines:</p><div id="rfc.figure.u.9"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1
+</pre><p id="rfc.section.3.1.1.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 8.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the
+ set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested
+ resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
+ and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section 6</a>.
+ </p>
+ <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3>
+ <p id="rfc.section.3.1.2.p.1">The Request-URI is a Uniform Resource Identifier ([Part 1]) and identifies the resource upon which to apply the request.</p>
+ <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span> Request-URI = "*" | absoluteURI | abs_path | authority
+</pre><p id="rfc.section.3.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
+ not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
+ apply to a resource. One example would be
+ </p>
+ <div id="rfc.figure.u.7"></div><pre class="text"> OPTIONS * HTTP/1.1
+</pre><p id="rfc.section.3.1.2.p.5">The absoluteURI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
+ and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request
+ loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
+ Request-Line would be:
+ </p>
+ <div id="rfc.figure.u.8"></div><pre class="text"> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+</pre><p id="rfc.section.3.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
+ </p>
+ <p id="rfc.section.3.1.2.p.8">The authority form is only used by the CONNECT method (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 6.9</a>).
+ </p>
+ <p id="rfc.section.3.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute
+ path of the URI <em class="bcp14">MUST</em> be transmitted (see [Part 1], abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
+ server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
+ </p>
+ <div id="rfc.figure.u.9"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
-</pre><p id="rfc.section.3.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).</p><p id="rfc.section.3.1.2.p.12">The Request-URI is transmitted in the format specified in [Part 1]. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[4]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.</p><p id="rfc.section.3.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".</p><p id
="rfc.section.3.1.2.p.14"> </p><dl class="empty"><dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.</dd></dl><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2><p id="rfc.section.3.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p><p id="rfc.section.3.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify
.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix A.1</a> for other requirements on Host support in HTTP/1.1.)</p><p id="rfc.section.3.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: </p><ol><li>If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.</li><li>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value.</li><li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.</li></ol><p id="r
fc.section.3.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.</p><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2><p id="rfc.section.3.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method invocation.</p><div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span> request-header = Accept ; [Part 3]
+</pre><p id="rfc.section.3.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
+ URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
+ </p>
+ <p id="rfc.section.3.1.2.p.12">The Request-URI is transmitted in the format specified in [Part 1]. If the Request-URI is encoded using the "% HEX HEX" encoding <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[4]</cite></a>, the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.
+ </p>
+ <p id="rfc.section.3.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above
+ to replace a null abs_path with "/".
+ </p>
+ <p id="rfc.section.3.1.2.p.14"> </p>
+ <dl class="empty">
+ <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
+ a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
+ known to rewrite the Request-URI.
+ </dd>
+ </dl>
+ <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
+ <p id="rfc.section.3.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p>
+ <p id="rfc.section.3.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix A.1</a> for other requirements on Host support in HTTP/1.1.)
+ </p>
+ <p id="rfc.section.3.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or
+ vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request:
+ </p>
+ <ol>
+ <li>If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.
+ </li>
+ <li>If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host
+ header field value.
+ </li>
+ <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message.
+ </li>
+ </ol>
+ <p id="rfc.section.3.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine
+ what exact resource is being requested.
+ </p>
+ <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2>
+ <p id="rfc.section.3.3.p.1">The request-header fields allow the client to pass additional information about the request, and about the client itself,
+ to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language
+ method invocation.
+ </p>
+ <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span> request-header = Accept ; [Part 3]
| Accept-Charset ; [Part 3]
| Accept-Encoding ; [Part 3]
| Accept-Language ; [Part 3]
@@ -373,14 +722,43 @@
| Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 8.7</a>
| TE ; [Part 1]
| User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 8.10</a>
-</pre><p id="rfc.section.3.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header fields.</p><h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="response" href="#response">Response</a></h1><p id="rfc.section.4.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p><div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 4.1</a>
+</pre><p id="rfc.section.3.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
+ or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
+ Unrecognized header fields are treated as entity-header fields.
+ </p>
+ <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="response" href="#response">Response</a></h1>
+ <p id="rfc.section.4.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
+ <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.9"></span> Response = Status-Line ; <a href="#status-line" title="Status-Line">Section 4.1</a>
*(( general-header ; [Part 1]
| response-header ; <a href="#response.header.fields" title="Response Header Fields">Section 4.2</a>
| entity-header ) CRLF) ; [Part 3]
CRLF
[ message-body ] ; [Part 1]
-</pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2><p id="rfc.section.4.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.</p><div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-</pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3><p id="rfc.section.4.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.</p><p id="rfc.section.4.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit: </p><ul><li>1xx: Informational - Request received, continuing process</li><li>2xx: Success - The
action was successfully received, understood, and accepted</li><li>3xx: Redirection - Further action must be taken in order to complete the request</li><li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li><li>5xx: Server Error - The server failed to fulfill an apparently valid request</li></ul><p id="rfc.section.4.1.1.p.3">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol.</p><div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> Status-Code =
+</pre><h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>
+ <p id="rfc.section.4.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code
+ and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final
+ CRLF sequence.
+ </p>
+ <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.10"></span> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+</pre><h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
+ <p id="rfc.section.4.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
+ are fully defined in <a href="#status.codes" title="Status Code Definitions">Section 7</a>. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use
+ by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
+ </p>
+ <p id="rfc.section.4.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
+ There are 5 values for the first digit:
+ </p>
+ <ul>
+ <li>1xx: Informational - Request received, continuing process</li>
+ <li>2xx: Success - The action was successfully received, understood, and accepted</li>
+ <li>3xx: Redirection - Further action must be taken in order to complete the request</li>
+ <li>4xx: Client Error - The request contains bad syntax or cannot be fulfilled</li>
+ <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
+ </ul>
+ <p id="rfc.section.4.1.1.p.3">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's,
+ are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol.
+ </p>
+ <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> Status-Code =
"100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 7.1.1</a>: Continue
| "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 7.1.2</a>: Switching Protocols
| "200" ; <a href="#status.200" id="rfc.xref.status.200.1" title="200 OK">Section 7.2.1</a>: OK
@@ -425,7 +803,18 @@
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
-</pre><p id="rfc.section.4.1.1.p.5">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the entity returned with the response, since that entity is likely to include human-readable information which will explain the unusual status.</p><h2 id="rfc.section.4.2"><a hre
f="#rfc.section.4.2">4.2</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2><p id="rfc.section.4.2.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.</p><div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.14"></span> response-header = Accept-Ranges ; [Part 3]
+</pre><p id="rfc.section.4.1.1.p.5">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes,
+ though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent
+ to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was
+ something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the entity returned with the response, since that entity is likely to include human-readable information
+ which will explain the unusual status.
+ </p>
+ <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
+ <p id="rfc.section.4.2.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
+ Status-Line. These header fields give information about the server and about further access to the resource identified by
+ the Request-URI.
+ </p>
+ <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.14"></span> response-header = Accept-Ranges ; [Part 3]
| Age ; [Part 6]
| ETag ; [Part 4]
| Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 8.5</a>
@@ -434,29 +823,1227 @@
| Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 8.9</a>
| Vary ; [Part 6]
| WWW-Authenticate ; [Part 7]
[... 1246 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org