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 [5/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/p2-semantics.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml?rev=583996&r1=583995&r2=583996&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p2-semantics.xml Thu Oct 11 17:33:46 2007
@@ -24,8 +24,6 @@
<!ENTITY http-version "[Part 1]">
<!ENTITY use100 "[Part 1]">
<!ENTITY qvalue "[Part 3]">
- <!ENTITY entity-header-fields "[Part 3]">
- <!ENTITY general-header-fields "[Part 1]">
<!ENTITY header-accept "[Part 3]">
<!ENTITY header-accept-charset "[Part 3]">
<!ENTITY header-accept-encoding "[Part 3]">
@@ -38,6 +36,7 @@
<!ENTITY header-content-range "[Part 5]">
<!ENTITY header-etag "[Part 4]">
<!ENTITY header-expires "[Part 6]">
+ <!ENTITY header-host "[Part 1]">
<!ENTITY header-if-match "[Part 4]">
<!ENTITY header-if-modified-since "[Part 4]">
<!ENTITY header-if-none-match "[Part 4]">
@@ -235,32 +234,6 @@
</t>
</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>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/>
- Request = Request-Line ; <xref target="request-line"/>
- *(( general-header ; &general-header-fields;
- | request-header ; <xref target="request.header.fields"/>
- | entity-header ) CRLF) ; &entity-header-fields;
- CRLF
- [ message-body ] ; &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
@@ -294,125 +267,6 @@
</t>
</section>
-<section title="Request-URI" anchor="request-uri">
-<t>
- The Request-URI is a Uniform Resource Identifier (&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 (<xref target="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 &http-url;, 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
- &http-url;. 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 title="Request Header Fields" anchor="request.header.fields">
<t>
The request-header fields allow the client to pass additional
@@ -429,7 +283,7 @@
| Authorization ; &header-authorization;
| Expect ; <xref target="header.expect"/>
| From ; <xref target="header.from"/>
- | Host ; <xref target="header.host"/>
+ | Host ; &header-host;
| If-Match ; &header-if-match;
| If-Modified-Since ; &header-if-modified-since;
| If-None-Match ; &header-if-none-match;
@@ -451,33 +305,6 @@
entity-header fields.
</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 ; &general-header-fields;
- | response-header ; <xref target="response.header.fields"/>
- | entity-header ) CRLF) ; &entity-header-fields;
- CRLF
- [ message-body ] ; &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>
@@ -488,32 +315,6 @@
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>
<t>
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
@@ -584,7 +385,6 @@
information which will explain the unusual status.
</t>
</section>
-</section>
<section title="Response Header Fields" anchor="response.header.fields">
<t>
@@ -613,8 +413,6 @@
entity-header fields.
</t>
</section>
-</section>
-
<section title="Entity" anchor="entity">
<t>
@@ -639,7 +437,7 @@
this set can be expanded, additional methods cannot be assumed to
share the same semantics for separately extended clients and servers.
- The Host request-header field (<xref target="header.host"/>) &MUST; accompany all
+ The Host request-header field (&header-host;) &MUST; accompany all
HTTP/1.1 requests.
</t>
@@ -1971,50 +1769,6 @@
</t>
</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 &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 ] ; &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="Location" anchor="header.location">
<iref primary="true" item="Location header" x:for-anchor=""/>
<iref primary="true" item="Headers" subitem="Location" x:for-anchor=""/>
@@ -2409,48 +2163,6 @@
<seriesInfo name="RFC" value="2068"/>
</reference>
-<reference anchor="RFC2396">
-<front>
-<title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
-<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
-<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
-<address>
-<postal>
-<street>MIT Laboratory for Computer Science, NE43-356</street>
-<street>545 Technology Square</street>
-<city>Cambridge</city>
-<region>MA</region>
-<code>02139</code></postal>
-<facsimile>+1(617)258-8682</facsimile>
-<email>timbl@w3.org</email></address></author>
-<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
-<organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization>
-<address>
-<postal>
-<street>University of California, Irvine</street>
-<city>Irvine</city>
-<region>CA</region>
-<code>92697-3425</code></postal>
-<facsimile>+1(949)824-1715</facsimile>
-<email>fielding@ics.uci.edu</email></address></author>
-<author initials="L." surname="Masinter" fullname="Larry Masinter">
-<organization abbrev="Xerox Corporation">Xerox PARC</organization>
-<address>
-<postal>
-<street>3333 Coyote Hill Road</street>
-<city>Palo Alto</city>
-<region>CA</region>
-<code>94034</code></postal>
-<facsimile>+1(415)812-4333</facsimile>
-<email>masinter@parc.xerox.com</email></address></author>
-<date month="August" year="1998"/>
-<area>Applications</area>
-<keyword>uniform resource</keyword>
-<keyword>URI</keyword>
-</front>
-<seriesInfo name="RFC" value="2396"/>
-</reference>
-
<reference anchor="RFC2617">
<front>
<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
@@ -2542,50 +2254,6 @@
</reference>
</references>
-
-<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="Changes from RFC 2068" anchor="changes.from.rfc.2068">
<t>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org