HTTP
Click on the red underlined text to get to the source
...
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol with the lightness and speed necessary for distributed,
...
... application-level
protocol with the lightness and speed necessary for distributed,
collaborative, hypermedia information systems. HTTP has been in use
by the World-Wide Web global information initiative since 1990. This
specification reflects common usage of the protocol referred too as
...
... by the World-Wide Web global information initiative since 1990. This
specification reflects common usage of the protocol referred too as
"HTTP/1.0". This specification describes the features that seem to be
consistently implemented in most HTTP/1.0 clients and servers ...
... "HTTP/1.0". This specification describes the features that seem to be
consistently implemented in most HTTP/1.0 clients and servers. The
specification is split into two sections. Those features of HTTP ...
... HTTP/1.0 clients and servers. The
specification is split into two sections. Those features of HTTP for
which implementations are usually consistent are described in the
main body of this document. Those features which have few or
...
... This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
connection ...
... message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 and
transmitted via the connection ...
... request
An HTTP request message (as defined in Section 5).
response
...
... response
An HTTP response message (as defined in Section 6).
resource
...
... firewalls and as protocol translators for access to resources
stored on non-HTTP systems.
tunnel ...
... active, a tunnel is not
considered a party to the HTTP communication, though the tunnel
may have been initiated by an HTTP request ...
... HTTP communication, though the tunnel
may have been initiated by an HTTP request. The tunnel ceases to
exist when both ends of the relayed connections ...
... entity metainformation, and possible body content.
Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the
...
... travels the whole chain must pass through four separate connections.
This distinction is important because some HTTP communication options
may apply only to the connection with the nearest, non-tunnel ...
... requirements on cache behavior. Some
HTTP/1.0 applications use heuristics to describe what is or is not a
"cachable" response, but these rules are not standardized.
...
...
On the Internet, HTTP communication generally takes place over TCP/IP
connections. The default port is TCP ...
... 15], but other ports can be
used. This does not preclude HTTP from being implemented on top of
any other protocol on the Internet, or on other networks ...
... any other protocol on the Internet, or on other networks. HTTP only
presumes a reliable transport; any protocol that provides such
...
... presumes a reliable transport; any protocol that provides such
guarantees can be used, and the mapping of the HTTP/1.0 request and
response structures onto the transport data units ...
...
HTTP/1.0 uses many of the constructs defined for MIME, as defined in
RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) ...
... 5]. Appendix C describes the ways in which the context of
HTTP allows for different use of Internet Media Types than is
...
... token. However, applications should attempt to follow "common
form" when generating HTTP constructs, since there exist some
implementations that fail to accept anything beyond the common
forms.
...
... US-ASCII double-quote mark (34)>
HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker
...
... LF
HTTP/1.0 headers may be folded onto multiple lines if each
continuation line begins with a space or horizontal tab. All linear
...
... However, folding of header lines is not expected by some
applications, and should not be generated by HTTP/1.0 applications.
The TEXT rule is only used for descriptive field contents and values
...
... DIGIT
Many HTTP/1.0 header field values consist of words separated by LWS
or special characters. These special characters must be in a quoted
...
... SP | HT
Comments may be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
...
...
Single-character quoting using the backslash ("\") character is not
permitted in HTTP/1.0.
...
...
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
...
... the sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components which do not affect
...
...
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. If the protocol version ...
... The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. If the protocol version is not
...
... version is not
specified, the recipient must assume that the message is in the
simple HTTP/0.9 format.
HTTP-Version ...
... Note that the major and minor numbers should be treated as separate
integers and that each may be incremented higher than a single digit.
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
...
... Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros should be ignored by recipients
...
... version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros should be ignored by recipients
and never generated by senders.
...
...
This document defines both the 0.9 and 1.0 versions of the HTTP
protocol. Applications sending Full-Request or Full-Response
messages, as defined by this specification, must include an HTTP ...
... HTTP
protocol. Applications sending Full-Request or Full-Response
messages, as defined by this specification, must include an HTTP-
Version of "HTTP/1.0 ...
... HTTP/1.0 servers must:
o recognize the format of the Request-Line for HTTP/0.9 and
HTTP/1.0 requests;
...
... o recognize the format of the Request-Line for HTTP/0.9 and
HTTP/1.0 requests;
o understand any valid ...
... valid request in the format of HTTP/0.9 or
HTTP/1.0;
o respond appropriately with a message in the same protocol
...
... clients must:
o recognize the format of the Status-Line for HTTP/1.0 responses;
o understand any valid ...
... gateway applications must be careful in forwarding requests
that are received in a format different than that of the
application's native HTTP version. Since the protocol version
...
... URN)
[16]. As far as HTTP is concerned, Uniform Resource Identifiers are
simply formatted strings which identify--via name, location, or any
...
... valid URLs as specified by RFC 1738(-> 4266prop | 4248prop), since HTTP servers
are not restricted in the set of unreserved characters allowed to
...
... unreserved characters allowed to
represent the rel_path part of addresses, and HTTP proxies may
receive requests for URIs ...
...
The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs ...
... 5.1.2).
Note: Although the HTTP protocol is independent of the transport
layer protocol, the http URL only identifies resources by their
...
...
HTTP/1.0 applications have historically allowed three different
formats for the representation of date/time stamps:
...
... 850(-> 1036) [10] date format and lacks a four-digit year.
HTTP/1.0 clients and servers that parse the date value should accept
all three formats, though they must never generate the third
...
...
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been generated by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies ...
... NNTP.
All HTTP/1.0 date/time stamps must be represented in Universal Time
(UT), also known as Greenwich Mean Time ...
... when reading the asctime format.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP ...
... | "Sep" | "Oct" | "Nov" | "Dec"
Note: HTTP requirements for the date/time stamp format apply
...
... character set" is more commonly
referred to as a "character encoding." However, since HTTP and
MIME share the same registry ...
... character set, we define here the preferred
names for those character sets most likely to be used with HTTP
entities. These character sets include those registered by RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) ...
...
Note: For future compatibility, HTTP/1.0 applications should
consider "gzip" and "compress" to be equivalent to "x-gzip ...
...
All content-coding values are case-insensitive. HTTP/1.0 uses
content-coding values in the Content-Encoding (Section 10.3) header
field ...
... unrecognized parameter and its value were not present.
Some older HTTP applications do not recognize media type parameters.
HTTP/1.0 ...
... HTTP applications do not recognize media type parameters.
HTTP/1.0 applications should only use media type parameters when they
are necessary to define the content of a message.
...
... canonical form. In
general, an Entity-Body transferred via HTTP must be represented in
the appropriate canonical form prior to its transmission. If the body
...
... line break
when in canonical form. However, HTTP allows the transport of text
media with plain CR ...
... line break when used
consistently within the Entity-Body. HTTP applications must accept
CRLF, bare CR ...
... LF as being representative of a line break in
text media received via HTTP.
In addition, if the text media is represented in a character set ...
... LF respectively, as is the
case for some multi-byte character sets, HTTP allows the use of
whatever octet sequences are defined by that character set to
...
... LF should not be substituted for CRLF
within any of the HTTP control structures (such as header fields and
multipart boundaries).
...
... charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
...
... order to be consistently interpreted by the recipient.
Note: Many current HTTP servers provide data using charsets other
than "ISO ...
... interoperability and is not recommended. To compensate for this,
some HTTP user agents provide a configuration option to allow the
user to change the default interpretation of the media type ...
... IANA [15] do not have any special meaning for
HTTP/1.0, though user agents may need to understand each type in
order to correctly interpret the purpose of each body-part. An HTTP ...
... HTTP/1.0, though user agents may need to understand each type in
order to correctly interpret the purpose of each body-part. An HTTP
user agent should follow the same or similar behavior as a MIME ...
... user agent should follow the same or similar behavior as a MIME user
agent does upon receipt of a multipart type. HTTP servers should not
assume that all HTTP clients are prepared to handle multipart types.
...
... user
agent does upon receipt of a multipart type. HTTP servers should not
assume that all HTTP clients are prepared to handle multipart types.
All multipart types share a common syntax and must include a boundary
...
... protocol element and must therefore use only CRLF to represent line
breaks between body-parts. Multipart body-parts may contain HTTP
header fields which are significant to the meaning of that part.
...
... HTTP Message ...
...
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 ...
... Header fields.
Multiple HTTP-header fields with the same field-name may be present
in a message if and only if the entire field-value for that header
field ...
... version in use. For
backwards compatibility with the more limited HTTP/0.9 protocol,
there are two valid formats for an HTTP request ...
... HTTP/0.9 protocol,
there are two valid formats for an HTTP request:
Request = Simple-Request | Full-Request
...
... Entity-Body ] ; Section 7.2
If an HTTP/1.0 server receives a Simple-Request, it must respond with
an HTTP/0.9 Simple-Response. An HTTP/1.0 ...
... If an HTTP/1.0 server receives a Simple-Request, it must respond with
an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving ...
... HTTP/1.0 server receives a Simple-Request, it must respond with
an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving
...
...
Note that the difference between a Simple-Request and the Request-
Line of a Full-Request is the presence of the HTTP-Version field and
the availability of methods other than GET.
...
... Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
The most common form of Request-URI ...
... host "www.w3.org" and send the line:
GET /pub/WWW/TheProject.html HTTP/1.0
followed by the remainder of the Full-Request. Note that the absolute
...
... receiving and interpreting a request message, a server responds
in the form of an HTTP response message.
Response = Simple-Response | Full-Response
...
... Entity-Body ] ; Section 7.2
A Simple-Response should only be sent in response to an HTTP/0.9
Simple-Request or if the server only supports the more limited
HTTP ...
... HTTP/0.9
Simple-Request or if the server only supports the more limited
HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and
...
... HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and
receives a response that does not begin with a Status-Line, it should
assume that the response is a Simple-Response and parse it
...
... SP
(e.g., "HTTP/1.0 200 "), the presence of that expression is
sufficient to differentiate a Full-Response from a Simple-Response.
Although the Simple-Response format ...
... entity body, and thus cause a
misinterpretation of the message if it was given in response to a
Full-Request, most HTTP/0.9 servers are limited to responses of type
"text/html" and therefore would never generate such a response.
...
... The individual values of the numeric status codes defined for
HTTP/1.0, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
-- they may be replaced by local equivalents without affecting the
...
... LF>
HTTP status codes are extensible, but the above codes are the only
ones generally recognized in current practice. HTTP ...
... HTTP status codes are extensible, but the above codes are the only
ones generally recognized in current practice. HTTP applications are
not required to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
...
...
The entity body (if any) sent with an HTTP request or response is in
a format and encoding defined by the Entity ...
... in the request message headers. HTTP/1.0 requests containing an
entity body must include a valid ...
... connection cannot be used to indicate the end of a
request body, since it leaves no possibility for the server to send
back a response. Therefore, HTTP/1.0 requests containing an entity
body must include a valid ...
... data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving ...
...
The set of common methods for HTTP/1.0 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... return any Entity-Body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request should be identical
to the information sent in response to a GET request. This method ...
... A valid Content-Length is required on all HTTP/1.0 POST requests. An
HTTP/1.0 server should respond with a 400 (bad request) message if it
...
... Content-Length is required on all HTTP/1.0 POST requests. An
HTTP/1.0 server should respond with a 400 (bad request) message if it
cannot determine the length of the request message's content.
...
... consisting only of the Status-Line and optional headers, and is
terminated by an empty line. HTTP/1.0 does not define any 1xx status
codes and they are not a valid response to a HTTP/1.0 ...
... HTTP/1.0 does not define any 1xx status
codes and they are not a valid response to a HTTP/1.0 request.
However, they may be useful for experimental applications which are
...
...
This response code is not directly used by HTTP/1.0 applications,
but serves as the default for interpreting the 3xx class of
...
... client's unacknowledged
input buffers before they can be read and interpreted by the HTTP
application.
...
... since that entity may include relevant diagnostic information. HTTP
access authentication is explained in Section 11.
403 Forbidden
...
... This section defines the syntax and semantics of all commonly used
HTTP/1.0 header fields. For general and entity header fields ...
... credentials
HTTP access authentication is described in Section 11. If a request
is authenticated and a realm specified, the same credentials ...
... valid Content-Length field value is required on all
HTTP/1.0 request messages containing an entity body.
...
... message/external-body" content-type. In
HTTP, it should be used whenever the entity's length can be
determined prior to being transferred.
...
... semantics as orig-date in
RFC 822std11(-> 2822prop). The field value is an HTTP-date, as described in Section
3.3.
...
... 3.3.
Date = "Date" ":" HTTP-date
An example is
...
... should include an Expires header with that date. The format is an
absolute date and time as defined by HTTP-date in Section 3.3.
Expires = "Expires" ":" HTTP ...
... (0) or an invalid date format should be considered equivalent to
an "expires immediately." Although these values are not legitimate
for HTTP/1.0, a robust implementation is always desirable.
...
... Entity-Body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
An example of the field is:
...
... copy should be considered stale.
Last-Modified = "Last-Modified" ":" HTTP-date
An example of its use is
...
... WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in Section 11.
User agents must take special care in parsing the WWW-Authenticate ...
... request, it should return a 403 (forbidden) response.
The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication ...
... cache the response to a
request containing Authorization. HTTP/1.0 does not provide a means
for a client to be authenticated ...
... filtering
unauthorized access to resources on an HTTP server. It is based on
the assumption that the connection between the client ...
... This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.0 as
described by this document. The discussion does not include
...
... physical
network used as the carrier. HTTP/1.0 does not prevent additional
authentication schemes and encryption mechanisms ...
... interest. This information is clearly confidential in nature and its
handling may be constrained by law in certain countries. People using
the HTTP protocol to provide data are responsible for ensuring that
such material is not distributed without the permission of any
individuals that are identifiable by the published results.
...
...
Like any generic data transfer protocol, HTTP cannot regulate the
content of the data that is transferred, nor is there any a priori
method ...
...
Implementations of HTTP origin servers should be careful to restrict
the documents returned by HTTP requests to be only those that were
...
... Implementations of HTTP origin servers should be careful to restrict
the documents returned by HTTP requests to be only those that were
intended by the server administrators ...
... administrators. If an HTTP server translates
HTTP URIs directly into file system calls, the server must take
...
... file system calls, the server must take
special care not to serve files that were not intended to be
delivered to HTTP clients. For example, Unix, Microsoft Windows, and
other operating systems use ".." as a path component to indicate a
...
... other operating systems use ".." as a path component to indicate a
directory level above the current one. On such a system, an HTTP
server must disallow any such construct in the Request-URI if it
would otherwise allow access to a resource outside those intended to
...
... Request-URI if it
would otherwise allow access to a resource outside those intended to
be accessible via the HTTP server. Similarly, files intended for
reference only internally to the server (such as access control
...
... configuration files, and script code) must be protected from
inappropriate retrieval, since they might contain sensitive
information. Experience has shown that minor bugs in such HTTP server
implementations have turned into security risks.
...
... 5]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship
between HTTP/1.0 and Internet mail message formats.
...
... Internet mail message formats.
The HTTP protocol has evolved considerably over the past four years.
It has benefited from a large and active developer community--the
...
... mailing list--and
it is that community which has been most responsible for the success
of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip
M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou
...
...
This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already mentioned,
the following individuals have contributed to this specification:
...
...
These appendices are provided for informational reasons only -- they
do not form a part of the HTTP/1.0 specification.
...
...
In addition to defining the HTTP/1.0 protocol, this document serves
as the specification for the Internet media type ...
...
version: The HTTP-Version number of the enclosed message
(e.g., "1.0"). If not present, the version can be
...
... Although this document specifies the requirements for the generation
of HTTP/1.0 messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be
...
... single SP is required.
The line terminator for HTTP-header fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers ...
... representations and with extensible mechanisms. However, RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft)
discusses mail, and HTTP has a few features that are different than
those described in RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft). These differences were carefully chosen
...
... freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers
and clients.
...
... 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) will be
revised. The revisions may include some of the practices found in
HTTP/1.0 but not in RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft).
...
... 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft).
This appendix describes specific areas where HTTP differs from RFC
1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft). Proxies ...
... Proxies and gateways from MIME environments to HTTP
also need to be aware of the differences because some conversions may
be required.
...
... allowed for subtypes of the "text" media type when transmitted over
HTTP.
RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) ...
... indicate a line break within text content when a message is
transmitted over HTTP.
Where it is possible, a proxy ...
... Where it is possible, a proxy or gateway from HTTP to a strict RFC
1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) environment should translate all line breaks ...
... complicated by the presence of a Content-Encoding and by the fact
that HTTP allows the use of some character sets which do not use
octets 13 and 10 to represent CR ...
...
HTTP/1.0 uses a restricted set of date formats (Section 3.3) to
simplify the process of date comparison. Proxies ...
... other protocols should ensure that any Date header field present in a
message conforms to one of the HTTP/1.0 formats and rewrite the date
if necessary.
...
...
RFC 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) does not include any concept equivalent to HTTP/1.0's
Content-Encoding header field ...
... media type, proxies and gateways from HTTP to MIME-compliant
protocols must either change the value of ...
...
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft) ...
... Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format
...
... C.5 HTTP Header Fields in Multipart Body-Parts ...
... 1521(-> 2049draft | 2048(-> 4289 | 4288) | 2047draft | 2046draft | 2045draft), most header fields in multipart body-parts are generally
ignored unless the field name begins with "Content-". In HTTP/1.0,
multipart body-parts may contain any HTTP header fields which are
...
... ignored unless the field name begins with "Content-". In HTTP/1.0,
multipart body-parts may contain any HTTP header fields which are
significant to the meaning of that part.
...
...
This appendix documents protocol elements used by some existing HTTP
implementations, but not consistently and correctly across most
HTTP/1.0 ...
... HTTP
implementations, but not consistently and correctly across most
HTTP/1.0 applications. Implementors should be aware of these
features, but cannot rely upon their presence in, or interoperability ...
... features, but cannot rely upon their presence in, or interoperability
with, other HTTP/1.0 applications.
...
... 5], should indicate that the message is MIME-conformant.
Unfortunately, some older HTTP/1.0 servers send it indiscriminately,
and thus this field should be ignored.
...
... unavailable to the requesting client. The value of this field can
be either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response.
...