Entity-Header (Section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [7]. Each header field consists
of a name followed immediately by a colon (":"), a single space (SP)
character, and the field value. Field names are case-insensitive.
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or HT, though this is not
recommended.
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
The order in which header fields are received is not significant.
However, it is "good practice" to send General-Header fields first,
followed by Request-Header or Response-Header fields prior to the
Entity-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 is defined as a comma-separated list [i.e., #(values)]. It must
be possible to combine the multiple header fields into one "field-
name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma.
RFC 1945 HTTP/1.0 May 1996
4.3 General Header Fields
There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the
entity being transferred. These headers apply only to the message
being transmitted.
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
General header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to
be general header fields. Unrecognized header fields are treated as
Entity-Header fields.
5. Request
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. For
backwards compatibility with the more limited HTTP/0.9 protocol,
there are two valid formats for an HTTP request:
Request = Simple-Request | Full-Request
Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ 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 client capable of receiving
a Full-Response should never generate a Simple-Request.
5.1 Request-Line
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 are allowed
except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
RFC 1945 HTTP/1.0 May 1996
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.
5.1.1 Method
=13= |