HTTP/1.0
Click on the red underlined text to get to the source
... 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 ...
... 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.
...
... 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) ...
... 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
...
...
Single-character quoting using the backslash ("\") character is not
permitted in HTTP/1.0.
...
... 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 ...
...
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
...
... NNTP.
All HTTP/1.0 date/time stamps must be represented in Universal Time
(UT), also known as Greenwich Mean Time ...
...
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 ...
... 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.
...
... 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 ...
... 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 ...
... 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
...
... 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
...
... 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 ...
... 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
...
... 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 ...
...
The set of common methods for HTTP/1.0 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... 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
...
... This section defines the syntax and semantics of all commonly used
HTTP/1.0 header fields. For general and entity header fields ...
... valid Content-Length field value is required on all
HTTP/1.0 request messages containing an entity body.
...
... (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.
...
... cache the response to a
request containing Authorization. HTTP/1.0 does not provide a means
for a client to be authenticated ...
... 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 ...
... 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.
...
...
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 ...
... 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
...
... 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).
...
...
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 ...
... 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
...
... 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.
...