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/12 02:33:48 UTC
svn commit: r583996 [3/5] - in /labs/webarch/trunk/http/draft-fielding-http:
outline2616.html outlineALL.html p1-messaging.html p1-messaging.xml
p2-semantics.html p2-semantics.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=583996&r1=583995&r2=583996&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p1-messaging.xml Thu Oct 11 17:33:46 2007
@@ -13,6 +13,7 @@
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
<!ENTITY caching "[Part 6]">
<!ENTITY payload "[Part 3]">
+ <!ENTITY CONNECT "[Part 2]">
<!ENTITY content.negotiation "[Part 3]">
<!ENTITY diff2045entity "[Part 3]">
<!ENTITY entity "[Part 3]">
@@ -26,10 +27,7 @@
<!ENTITY request-header-fields "[Part 2]">
<!ENTITY response-header-fields "[Part 2]">
<!ENTITY method "[Part 2]">
- <!ENTITY status-code "[Part 2]">
- <!ENTITY request "[Part 2]">
- <!ENTITY request-uri "[Part 2]">
- <!ENTITY response "[Part 2]">
+ <!ENTITY status-codes "[Part 2]">
<!ENTITY status-100 "[Part 2]">
<!ENTITY status-1xx "[Part 2]">
<!ENTITY status-414 "[Part 2]">
@@ -265,7 +263,7 @@
<x:dfn>request</x:dfn>
<list>
<t>
- An HTTP request message, as defined in &request;.
+ An HTTP request message, as defined in <xref target="request"/>.
</t>
</list>
</t>
@@ -274,7 +272,7 @@
<x:dfn>response</x:dfn>
<list>
<t>
- An HTTP response message, as defined in &response;.
+ An HTTP response message, as defined in <xref target="response"/>.
</t>
</list>
</t>
@@ -991,10 +989,10 @@
If the port is empty or not given, port 80 is assumed. The semantics
are that the identified resource is located at the server listening
for TCP connections on that port of that host, and the Request-URI
- for the resource is abs_path (&request-uri;). The use of IP addresses
+ for the resource is abs_path (<xref target="request-uri"/>). The use of IP addresses
in URLs &SHOULD; be avoided whenever possible (see RFC 1900 <xref target="RFC1900"/>). If
the abs_path is not present in the URL, it &MUST; be given as "/" when
- used as a Request-URI for a resource (&request-uri;). If a proxy
+ used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
receives a host name which is not a fully qualified domain name, it
&MAY; add its domain to the host name it received. If a proxy receives
@@ -1262,7 +1260,7 @@
HTTP-message = Request | Response ; HTTP/1.1 messages
</artwork></figure>
<t>
- Request (&request;) and Response (&response;) messages use the generic
+ Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
message format of RFC 822 <xref target="RFC822"/> for transferring entities (the payload
of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
@@ -1379,7 +1377,7 @@
<t>
For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
- status code (&status-code;). All responses to the HEAD request method
+ status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method
&MUST-NOT; include a message-body, even though the presence of entity-header
fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
@@ -1499,6 +1497,235 @@
</section>
</section>
+<section title="Request" anchor="request">
+<t>
+ 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.
+</t>
+<!-- Host ; should be moved here eventually -->
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
+ Request = Request-Line ; <xref target="request-line"/>
+ *(( general-header ; <xref target="general.header.fields"/>
+ | request-header ; &request-header-fields;
+ | entity-header ) CRLF) ; &entity-header-fields;
+ CRLF
+ [ message-body ] ; <xref target="message.body"/>
+</artwork></figure>
+
+<section title="Request-Line" anchor="request-line">
+<t>
+ 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.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/>
+ Request-Line = Method SP Request-URI SP HTTP-Version CRLF
+</artwork></figure>
+
+<section title="Method" anchor="method">
+<t>
+ The Method token indicates the method to be performed on the
+ resource identified by the Request-URI. The method is case-sensitive.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
+ Method = token
+</artwork></figure>
+</section>
+
+<section title="Request-URI" anchor="request-uri">
+<t>
+ The Request-URI is a Uniform Resource Identifier (<xref target="uri"/>) and
+ identifies the resource upon which to apply the request.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/>
+ Request-URI = "*" | absoluteURI | abs_path | authority
+</artwork></figure>
+<t>
+ 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
+</t>
+<figure><artwork type="example">
+ OPTIONS * HTTP/1.1
+</artwork></figure>
+<t>
+ The absoluteURI form is &REQUIRED; 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 &MAY;
+ forward the request on to another proxy or directly to the server
+ specified by the absoluteURI. In order to avoid request loops, a
+ proxy &MUST; 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:
+</t>
+<figure><artwork type="example">
+ GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+</artwork></figure>
+<t>
+ To allow for transition to absoluteURIs in all requests in future
+ versions of HTTP, all HTTP/1.1 servers &MUST; accept the absoluteURI
+ form in requests, even though HTTP/1.1 clients will only generate
+ them in requests to proxies.
+</t>
+<t>
+ The authority form is only used by the CONNECT method (&CONNECT;).
+</t>
+<t>
+ 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 &MUST; be transmitted (see <xref target="general.syntax"/>, abs_path) as
+ the Request-URI, and the network location of the URI (authority) &MUST;
+ 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:
+</t>
+<figure><artwork type="example">
+ GET /pub/WWW/TheProject.html HTTP/1.1
+ Host: www.w3.org
+</artwork></figure>
+<t>
+ followed by the remainder of the Request. Note that the absolute path
+ cannot be empty; if none is present in the original URI, it &MUST; be
+ given as "/" (the server root).
+</t>
+<t>
+ The Request-URI is transmitted in the format specified in
+ <xref target="general.syntax"/>. If the Request-URI is encoded using the "% HEX HEX" encoding
+ <xref target="RFC2396"/>, the origin server &MUST; decode the Request-URI in order to
+ properly interpret the request. Servers &SHOULD; respond to invalid
+ Request-URIs with an appropriate status code.
+</t>
+<t>
+ A transparent proxy &MUST-NOT; 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 "/".
+</t>
+<t>
+ <list><t>
+ <x:h>Note:</x:h> 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.
+ </t></list>
+</t>
+</section>
+</section>
+
+<section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
+<t>
+ The exact resource identified by an Internet request is determined by
+ examining both the Request-URI and the Host header field.
+</t>
+<t>
+ An origin server that does not allow resources to differ by the
+ requested host &MAY; ignore the Host header field value when
+ determining the resource identified by an HTTP/1.1 request. (But see
+ <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
+ for other requirements on Host support in HTTP/1.1.)
+</t>
+<t>
+ An origin server that does differentiate resources based on the host
+ requested (sometimes referred to as virtual hosts or vanity host
+ names) &MUST; use the following rules for determining the requested
+ resource on an HTTP/1.1 request:
+ <list style="numbers">
+ <t>If Request-URI is an absoluteURI, the host is part of the
+ Request-URI. Any Host header field value in the request &MUST; be
+ ignored.</t>
+ <t>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.</t>
+ <t>If the host as determined by rule 1 or 2 is not a valid host on
+ the server, the response &MUST; be a 400 (Bad Request) error message.</t>
+ </list>
+</t>
+<t>
+ Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
+ 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.
+</t>
+</section>
+
+</section>
+
+
+<section title="Response" anchor="response">
+<t>
+ After receiving and interpreting a request message, a server responds
+ with an HTTP response message.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/>
+ Response = Status-Line ; <xref target="status-line"/>
+ *(( general-header ; <xref target="general.header.fields"/>
+ | response-header ; &response-header-fields;
+ | entity-header ) CRLF) ; &entity-header-fields;
+ CRLF
+ [ message-body ] ; <xref target="message.body"/>
+</artwork></figure>
+
+<section title="Status-Line" anchor="status-line">
+<t>
+ 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.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Line"/>
+ Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+</artwork></figure>
+
+<section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase">
+<t>
+ 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 &status-codes;. 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.
+</t>
+<t>
+ 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:
+ <list style="symbols">
+ <t>
+ 1xx: Informational - Request received, continuing process
+ </t>
+ <t>
+ 2xx: Success - The action was successfully received,
+ understood, and accepted
+ </t>
+ <t>
+ 3xx: Redirection - Further action must be taken in order to
+ complete the request
+ </t>
+ <t>
+ 4xx: Client Error - The request contains bad syntax or cannot
+ be fulfilled
+ </t>
+ <t>
+ 5xx: Server Error - The server failed to fulfill an apparently
+ valid request
+ </t>
+ </list>
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/>
+ Status-Code = 3DIGIT
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+</artwork></figure>
+</section>
+</section>
+
+</section>
+
+
<section title="Connections" anchor="connections">
<section title="Persistent Connections" anchor="persistent.connections">
@@ -2074,6 +2301,50 @@
</section>
</section>
+<section title="Host" anchor="header.host">
+ <iref primary="true" item="Host header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Host" x:for-anchor=""/>
+<t>
+ The Host request-header field specifies the Internet host and port
+ number of the resource being requested, as obtained from the original
+ URI given by the user or referring resource (generally an HTTP URL,
+ as described in <xref target="http.url"/>). The Host field value &MUST; represent
+ the naming authority of the origin server or gateway given by the
+ original URL. This allows the origin server or gateway to
+ differentiate between internally-ambiguous URLs, such as the root "/"
+ URL of a server for multiple host names on a single IP address.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
+ Host = "Host" ":" host [ ":" port ] ; <xref target="http.url"/>
+</artwork></figure>
+<t>
+ A "host" without any trailing port information implies the default
+ port for the service requested (e.g., "80" for an HTTP URL). For
+ example, a request on the origin server for
+ <http://www.w3.org/pub/WWW/> would properly include:
+</t>
+<figure><artwork type="example">
+ GET /pub/WWW/ HTTP/1.1
+ Host: www.w3.org
+</artwork></figure>
+<t>
+ A client &MUST; include a Host header field in all HTTP/1.1 request
+ messages . If the requested URI does not include an Internet host
+ name for the service being requested, then the Host header field &MUST;
+ be given with an empty value. An HTTP/1.1 proxy &MUST; ensure that any
+ request message it forwards does contain an appropriate Host header
+ field that identifies the service being requested by the proxy. All
+ Internet-based HTTP/1.1 servers &MUST; respond with a 400 (Bad Request)
+ status code to any HTTP/1.1 request message which lacks a Host header
+ field.
+</t>
+<t>
+ See sections <xref target="the.resource.identified.by.a.request" format="counter"/>
+ and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
+ for other requirements relating to Host.
+</t>
+</section>
+
<section title="TE" anchor="header.te">
<iref primary="true" item="TE header" x:for-anchor=""/>
<iref primary="true" item="Headers" subitem="TE" x:for-anchor=""/>
@@ -3691,6 +3962,50 @@
version of persistent connections described in <xref x:sec="19.7.1" x:fmt="sec" target="RFC2068"/> of RFC
2068 <xref target="RFC2068"/>.
</t>
+
+<section title="Changes from HTTP/1.0" anchor="changes.from.1.0">
+<t>
+ This section summarizes major differences between versions HTTP/1.0
+ and HTTP/1.1.
+</t>
+
+<section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
+<t>
+ The requirements that clients and servers support the Host request-header,
+ report an error if the Host request-header (<xref target="header.host"/>) is
+ missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-uri"/>)
+ are among the most important changes defined by this
+ specification.
+</t>
+<t>
+ Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+ addresses and servers; there was no other established mechanism for
+ distinguishing the intended server of a request than the IP address
+ to which that request was directed. The changes outlined above will
+ allow the Internet, once older HTTP clients are no longer common, to
+ support multiple Web sites from a single IP address, greatly
+ simplifying large operational Web servers, where allocation of many
+ IP addresses to a single host has created serious problems. The
+ Internet will also be able to recover the IP addresses that have been
+ allocated for the sole purpose of allowing special-purpose domain
+ names to be used in root-level HTTP URLs. Given the rate of growth of
+ the Web, and the number of servers already deployed, it is extremely
+ important that all implementations of HTTP (including updates to
+ existing HTTP/1.0 applications) correctly implement these
+ requirements:
+ <list style="symbols">
+ <t>Both clients and servers &MUST; support the Host request-header.</t>
+
+ <t>A client that sends an HTTP/1.1 request &MUST; send a Host header.</t>
+
+ <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
+ request does not include a Host request-header.</t>
+
+ <t>Servers &MUST; accept absolute URIs.</t>
+ </list>
+</t>
+</section>
+</section>
<section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections">
<t>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org