As per Relevance of the word resource, we have this rfc below:
Network Working Group T. Berners-
Request for Comments: 1945 MIT/
Category: Informational R.
UC
H.
MIT/
May 1996
Hypertext Transfer Protocol -- HTTP/1.0
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
IESG Note
The IESG has concerns about this protocol, and expects this
to be replaced relatively soon by a standards track document
The Hypertext Transfer Protocol (HTTP) is an application-
protocol with the lightness and speed necessary for distributed
collaborative, hypermedia information systems. It is a generic
stateless, object-oriented protocol which can be used for many tasks
such as name servers and distributed object management systems
through extension of its request methods (commands). A feature
HTTP is the typing of data representation, allowing systems to
built independently of the data being transferred
HTTP has been in use by the World-Wide Web global
initiative since 1990. This specification reflects common usage
the protocol referred to as "HTTP/1.0".
Table of
1. Introduction .............................................. 4
1.1 Purpose .............................................. 4
1.2 Terminology .......................................... 4
1.3 Overall Operation .................................... 6
1.4 HTTP and MIME ........................................ 8
2. Notational Conventions and Generic Grammar ................ 8
2.1 Augmented BNF ........................................ 8
2.2 Basic Rules .......................................... 10
3. Protocol Parameters ....................................... 12
Berners-Lee, et al Informational [Page 1]
RFC 1945 HTTP/1.0 May 1996
3.1 HTTP Version ......................................... 12
3.2 Uniform Resource Identifiers ......................... 14
3.2.1 General Syntax ................................ 14
3.2.2 http URL ...................................... 15
3.3 Date/Time Formats .................................... 15
3.4 Character Sets ....................................... 17
3.5 Content Codings ...................................... 18
3.6 Media Types .......................................... 19
3.6.1 Canonicalization and Text Defaults ............ 19
3.6.2 Multipart Types ............................... 20
3.7 Product Tokens ....................................... 20
4. HTTP Message .............................................. 21
4.1 Message Types ........................................ 21
4.2 Message Headers ...................................... 22
4.3 General Header Fields ................................ 23
5. Request ................................................... 23
5.1 Request-Line ......................................... 23
5.1.1 Method ........................................ 24
5.1.2 Request-URI ................................... 24
5.2 Request Header Fields ................................ 25
6. Response .................................................. 25
6.1 Status-Line .......................................... 26
6.1.1 Status Code and Reason Phrase ................. 26
6.2 Response Header Fields ............................... 28
7. Entity .................................................... 28
7.1 Entity Header Fields ................................. 29
7.2 Entity Body .......................................... 29
7.2.1 Type .......................................... 29
7.2.2 Length ........................................ 30
8. Method Definitions ........................................ 30
8.1 GET .................................................. 31
8.2 HEAD ................................................. 31
8.3 POST ................................................. 31
9. Status Code Definitions ................................... 32
9.1 Informational 1xx .................................... 32
9.2 Successful 2xx ....................................... 32
9.3 Redirection 3xx ...................................... 34
9.4 Client Error 4xx ..................................... 35
9.5 Server Error 5xx ..................................... 37
10. Header Field Definitions .................................. 37
10.1 Allow ............................................... 38
10.2 Authorization ....................................... 38
10.3 Content-Encoding .................................... 39
10.4 Content-Length ...................................... 39
10.5 Content-Type ........................................ 40
10.6 Date ................................................ 40
10.7 Expires ............................................. 41
10.8 From ................................................ 42
Berners-Lee, et al Informational [Page 2]
RFC 1945 HTTP/1.0 May 1996
10.9 If-Modified-Since ................................... 42
10.10 Last-Modified ....................................... 43
10.11 Location ............................................ 44
10.12 Pragma .............................................. 44
10.13 Referer ............................................. 44
10.14 Server .............................................. 45
10.15 User-Agent .......................................... 46
10.16 WWW-Authenticate .................................... 46
11. Access Authentication ..................................... 47
11.1 Basic Authentication Scheme ......................... 48
12. Security Considerations ................................... 49
12.1 Authentication of Clients ........................... 49
12.2 Safe Methods ........................................ 49
12.3 Abuse of Server Log Information ..................... 50
12.4 Transfer of Sensitive Information ................... 50
12.5 Attacks Based On File and Path Names ................ 51
13. Acknowledgments ........................................... 51
14. References ................................................ 52
15. Authors' Addresses ........................................ 54
Appendix A. Internet Media Type message/http ................ 55
Appendix B. Tolerant Applications ........................... 55
Appendix C. Relationship to MIME ............................ 56
C.1 Conversion to Canonical Form ......................... 56
C.2 Conversion of Date Formats ........................... 57
C.3 Introduction of Content-Encoding ..................... 57
C.4 No Content-Transfer-Encoding ......................... 57
C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
Appendix D. Additional Features ............................. 57
D.1 Additional Request Methods ........................... 58
D.1.1 PUT ........................................... 58
D.1.2 DELETE ........................................ 58
D.1.3 LINK .......................................... 58
D.1.4 UNLINK ........................................ 58
D.2 Additional Header Field Definitions .................. 58
D.2.1 Accept ........................................ 58
D.2.2 Accept-Charset ................................ 59
D.2.3 Accept-Encoding ............................... 59
D.2.4 Accept-Language ............................... 59
D.2.5 Content-Language .............................. 59
D.2.6 Link .......................................... 59
D.2.7 MIME-Version .................................. 59
D.2.8 Retry-After ................................... 60
D.2.9 Title ......................................... 60
D.2.10 URI ........................................... 60
Berners-Lee, et al Informational [Page 3]
RFC 1945 HTTP/1.0 May 1996
1.
1.1
The Hypertext Transfer Protocol (HTTP) is an application-
protocol with the lightness and speed necessary for distributed
collaborative, hypermedia information systems. HTTP has been in
by the World-Wide Web global information initiative since 1990.
specification reflects common usage of the protocol referred too
"HTTP/1.0". This specification describes the features that seem to
consistently implemented in most HTTP/1.0 clients and servers.
specification is split into two sections. Those features of HTTP
which implementations are usually consistent are described in
main body of this document. Those features which have few
inconsistent implementations are listed in Appendix D
Practical information systems require more functionality than
retrieval, including search, front-end update, and annotation.
allows an open-ended set of methods to be used to indicate
purpose of a request. It builds on the discipline of
provided by the Uniform Resource Identifier (URI) [2], as a
(URL) [4] or name (URN) [16], for indicating the resource on which
method is to be applied. Messages are passed in a format similar
that used by Internet Mail [7] and the Multipurpose Internet
Extensions (MIME) [5].
HTTP is also used as a generic protocol for communication
user agents and proxies/gateways to other Internet protocols, such
SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8],
basic hypermedia access to resources available from
applications and simplifying the implementation of user agents
1.2
This specification uses a number of terms to refer to the
played by participants in, and objects of, the HTTP communication
A transport layer virtual circuit established between
application programs for the purpose of communication
The basic unit of HTTP communication, consisting of a
sequence of octets matching the syntax defined in Section 4
transmitted via the connection
Berners-Lee, et al Informational [Page 4]
RFC 1945 HTTP/1.0 May 1996
An HTTP request message (as defined in Section 5).
An HTTP response message (as defined in Section 6).
A network data object or service which can be identified by
URI (Section 3.2).
A particular representation or rendition of a data resource,
reply from a service resource, that may be enclosed within
request or response message. An entity consists
metainformation in the form of entity headers and content in
form of an entity body
An application program that establishes connections for
purpose of sending requests
user
The client which initiates a request. These are often browsers
editors, spiders (web-traversing robots), or other end
tools
An application program that accepts connections in order
service requests by sending back responses
origin
The server on which a given resource resides or is to be created
An intermediary program which acts as both a server and a
for the purpose of making requests on behalf of other clients
Requests are serviced internally or by passing them,
possible translation, on to other servers. A proxy
interpret and, if necessary, rewrite a request message
Berners-Lee, et al Informational [Page 5]
RFC 1945 HTTP/1.0 May 1996
forwarding it. Proxies are often used as client-side
through network firewalls and as helper applications
handling requests via protocols not implemented by the
agent
A server which acts as an intermediary for some other server
Unlike a proxy, a gateway receives requests as if it were
origin server for the requested resource; the requesting
may not be aware that it is communicating with a gateway
Gateways are often used as server-side portals through
firewalls and as protocol translators for access to
stored on non-HTTP systems
A tunnel is an intermediary program which is acting as a
relay between two connections. Once active, a tunnel is
considered a party to the HTTP communication, though the
may have been initiated by an HTTP request. The tunnel ceases
exist when both ends of the relayed connections are closed
Tunnels are used when a portal is necessary and the
cannot, or should not, interpret the relayed communication
A program's local store of response messages and the
that controls its message storage, retrieval, and deletion.
cache stores cachable responses in order to reduce the
time and network bandwidth consumption on future,
requests. Any client or server may include a cache, though
cache cannot be used by a server while it is acting as a tunnel
Any given program may be capable of being both a client and a server
our use of these terms refers only to the role being performed by
program for a particular connection, rather than to the program'
capabilities in general. Likewise, any server may act as an
server, proxy, gateway, or tunnel, switching behavior based on
nature of each request
1.3 Overall
The HTTP protocol is based on a request/response paradigm. A
establishes a connection with a server and sends a request to
server in the form of a request method, URI, and protocol version
followed by a MIME-like message containing request modifiers,
information, and possible body content. The server responds with
Berners-Lee, et al Informational [Page 6]
RFC 1945 HTTP/1.0 May 1996
status line, including the message's protocol version and a
or error code, followed by a MIME-like message containing
information, entity metainformation, and possible body content
Most HTTP communication is initiated by a user agent and consists
a request to be applied to a resource on some origin server. In
simplest case, this may be accomplished via a single connection (v
between the user agent (UA) and the origin server (O).
request chain ------------------------>
UA -------------------v-------------------
<----------------------- response
A more complicated situation occurs when one or more
are present in the request/response chain. There are three
forms of intermediary: proxy, gateway, and tunnel. A proxy is
forwarding agent, receiving requests for a URI in its absolute form
rewriting all or parts of the message, and forwarding the
request toward the server identified by the URI. A gateway is
receiving agent, acting as a layer above some other server(s) and,
necessary, translating the requests to the underlying server'
protocol. A tunnel acts as a relay point between two
without changing the messages; tunnels are used when
communication needs to pass through an intermediary (such as
firewall) even when the intermediary cannot understand the
of the messages
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v-----
<------------------------------------- response
The figure above shows three intermediaries (A, B, and C) between
user agent and origin server. A request or response message
travels the whole chain must pass through four separate connections
This distinction is important because some HTTP communication
may apply only to the connection with the nearest, non-
neighbor, only to the end-points of the chain, or to all
along the chain. Although the diagram is linear, each participant
be engaged in multiple, simultaneous communications. For example,
may be receiving requests from many clients other than A, and/
forwarding requests to servers other than C, at the same time that
is handling A's request
Any party to the communication which is not acting as a tunnel
employ an internal cache for handling requests. The effect of a
is that the request/response chain is shortened if one of
participants along the chain has a cached response applicable to
request. The following illustrates the resulting chain if B has
Berners-Lee, et al Informational [Page 7]
RFC 1945 HTTP/1.0 May 1996
cached copy of an earlier response from O (via C) for a request
has not been cached by UA or A
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - -
<--------- response
Not all responses are cachable, and some requests may
modifiers which place special requirements on cache behavior.
HTTP/1.0 applications use heuristics to describe what is or is not
"cachable" response, but these rules are not standardized
On the Internet, HTTP communication generally takes place over TCP/
connections. The default port is TCP 80 [15], but other ports can
used. This does not preclude HTTP from being implemented on top
any other protocol on the Internet, or on other networks. HTTP
presumes a reliable transport; any protocol that provides
guarantees can be used, and the mapping of the HTTP/1.0 request
response structures onto the transport data units of the protocol
question is outside the scope of this specification
Except for experimental applications, current practice requires
the connection be established by the client prior to each request
closed by the server after sending the response. Both clients
servers should be aware that either party may close the
prematurely, due to user action, automated time-out, or
failure, and should handle such closing in a predictable fashion.
any case, the closing of the connection by either or both
always terminates the current request, regardless of its status
1.4 HTTP and
HTTP/1.0 uses many of the constructs defined for MIME, as defined
RFC 1521 [5]. Appendix C describes the ways in which the context
HTTP allows for different use of Internet Media Types than
typically found in Internet mail, and gives the rationale for
differences
2. Notational Conventions and Generic
2.1 Augmented
All of the mechanisms specified in this document are described
both prose and an augmented Backus-Naur Form (BNF) similar to
used by RFC 822 [7]. Implementors will need to be familiar with
notation in order to understand this specification. The augmented
includes the following constructs
Berners-Lee, et al Informational [Page 8]
RFC 1945 HTTP/1.0 May 1996
name =
The name of a rule is simply the name itself (without
enclosing "<" and ">") and is separated from its definition
the equal character "=". Whitespace is only significant in
indentation of continuation lines is used to indicate a
definition that spans more than one line. Certain basic
are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc
Angle brackets are used within definitions whenever
presence will facilitate discerning the use of rule names
"literal
Quotation marks surround literal text. Unless stated otherwise
the text is case-insensitive
rule1 | rule
Elements separated by a bar ("I") are alternatives
e.g., "yes | no" will accept yes or no
(rule1 rule2)
Elements enclosed in parentheses are treated as a
element. Thus, "(elem (foo | bar) elem)" allows the
sequences "elem foo elem" and "elem bar elem".
*
The character "*" preceding an element indicates repetition.
full form is "*element" indicating at least and
most occurrences of element. Default values are 0
infinity so that "*(element)" allows any number, including zero
"1*element" requires at least one; and "1*2element" allows
or two
[rule
Square brackets enclose optional elements; "[foo bar]"
equivalent to "*1(foo bar)".
N
Specific repetition: "(element)" is equivalent
"*(element)"; that is, exactly occurrences
(element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is
string of three alphabetic characters
Berners-Lee, et al Informational [Page 9]
RFC 1945 HTTP/1.0 May 1996
#
A construct "#" is defined, similar to "*", for defining
of elements. The full form is "#element" indicating
least and at most elements, each separated by one
more commas (",") and optional linear whitespace (LWS).
makes the usual form of lists very easy; a rule such
"( *LWS element *( *LWS "," *LWS element ))" can be shown
"1#element". Wherever this construct is used, null elements
allowed, but do not contribute to the count of elements present
That is, "(element), , (element)" is permitted, but counts
only two elements. Therefore, where at least one element
required, at least one non-null element must be present.
values are 0 and infinity so that "#(element)" allows
number, including zero; "1#element" requires at least one;
"1#2element" allows one or two
;
A semi-colon, set off some distance to the right of rule text
starts a comment that continues to the end of line. This is
simple way of including useful notes in parallel with
specifications
implied *
The grammar described by this specification is word-based
Except where noted otherwise, linear whitespace (LWS) can
included between any two adjacent words (token
quoted-string), and between adjacent tokens and
(tspecials), without changing the interpretation of a field.
least one delimiter (tspecials) must exist between any
tokens, since they would otherwise be interpreted as a
token. However, applications should attempt to follow "
form" when generating HTTP constructs, since there exist
implementations that fail to accept anything beyond the
forms
2.2 Basic
The following rules are used throughout this specification
describe basic parsing constructs. The US-ASCII coded character
is defined by [17].
OCTET = sequence of data
CHAR = character (octets 0 - 127)>
UPALPHA =
LOALPHA =
Berners-Lee, et al Informational [Page 10]
RFC 1945 HTTP/1.0 May 1996
ALPHA = UPALPHA |
DIGIT =
CTL =
(octets 0 - 31) and DEL (127)>
CR =
LF = linefeed (10)>
SP =
HT = horizontal-tab (9)>
<"> =
HTTP/1.0 defines the octet sequence CR LF as the end-of-line
for all protocol elements except the Entity-Body (see Appendix B
tolerant applications). The end-of-line marker within an Entity-
is defined by its associated media type, as described in Section 3.6.
CRLF = CR
HTTP/1.0 headers may be folded onto multiple lines if
continuation line begins with a space or horizontal tab. All
whitespace, including folding, has the same semantics as SP
LWS = [CRLF] 1*( SP | HT )
However, folding of header lines is not expected by
applications, and should not be generated by HTTP/1.0 applications
The TEXT rule is only used for descriptive field contents and
that are not intended to be interpreted by the message parser.
of *TEXT may contain octets from character sets other than US-ASCII
TEXT =
but including LWS
Recipients of header field TEXT containing octets outside the US
ASCII character set may assume that they represent ISO-8859-1
characters
Hexadecimal numeric characters are used in several protocol elements
HEX = "A" | "B" | "C" | "D" | "E" | "F
| "a" | "b" | "c" | "d" | "e" | "f" |
Many HTTP/1.0 header field values consist of words separated by
or special characters. These special characters must be in a
string to be used within a parameter value
word = token | quoted-
Berners-Lee, et al Informational [Page 11]
RFC 1945 HTTP/1.0 May 1996
token = 1*
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP |
Comments may be included in some HTTP header fields by
the comment text with parentheses. Comments are only allowed
fields containing "comment" as part of their field value definition
In all other fields, parentheses are considered part of the
value
comment = "(" *( ctext | comment ) ")"
ctext =
A string of text is parsed as a single word if it is quoted
double-quote marks
quoted-string = ( <"> *(qdtext) <"> )
qdtext = and CTLs
but including LWS
Single-character quoting using the backslash ("\") character is
permitted in HTTP/1.0.
3. Protocol
3.1 HTTP
HTTP uses a "." numbering scheme to indicate
of the protocol. The protocol versioning policy is intended to
the sender to indicate the format of a message and its capacity
understanding further HTTP communication, rather than the
obtained via that communication. No change is made to the
number for the addition of message components which do not
communication behavior or which only add to extensible field values
The number is incremented when the changes made to
protocol add features which do not change the general message
algorithm, but which may add to the message semantics and
additional capabilities of the sender. The number
incremented when the format of a message within the protocol
changed
The version of an HTTP message is indicated by an HTTP-Version
in the first line of the message. If the protocol version is
specified, the recipient must assume that the message is in
Berners-Lee, et al Informational [Page 12]
RFC 1945 HTTP/1.0 May 1996
simple HTTP/0.9 format
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*
Note that the major and minor numbers should be treated as
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
lower than HTTP/12.3. Leading zeros should be ignored by
and never generated by senders
This document defines both the 0.9 and 1.0 versions of the
protocol. Applications sending Full-Request or Full-
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
HTTP/1.0 requests
o understand any valid request in the format of HTTP/0.9
HTTP/1.0;
o respond appropriately with a message in the same
version used by the client
HTTP/1.0 clients must
o recognize the format of the Status-Line for HTTP/1.0 responses
o understand any valid response in the format of HTTP/0.9
HTTP/1.0.
Proxy and gateway applications must be careful in forwarding
that are received in a format different than that of
application's native HTTP version. Since the protocol
indicates the protocol capability of the sender, a proxy/gateway
never send a message with a version indicator which is greater
its native version; if a higher version request is received,
proxy/gateway must either downgrade the request version or
with an error. Requests with a version lower than that of
application's native format may be upgraded before being forwarded
the proxy/gateway's response to that request must follow the
requirements listed above
Berners-Lee, et al Informational [Page 13]
RFC 1945 HTTP/1.0 May 1996
3.2 Uniform Resource
URIs have been known by many names: WWW addresses, Universal
Identifiers, Universal Resource Identifiers [2], and finally
combination of Uniform Resource Locators (URL) [4] and Names (URN
[16]. As far as HTTP is concerned, Uniform Resource Identifiers
simply formatted strings which identify--via name, location, or
other characteristic--a network resource
3.2.1 General
URIs in HTTP can be represented in absolute form or relative to
known base URI [9], depending upon the context of their use. The
forms are differentiated by the fact that absolute URIs always
with a scheme name followed by a colon
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*
segment = *
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved |
unreserved = ALPHA | DIGIT | safe | extra |
escape = "%" HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national =
Berners-Lee, et al Informational [Page 14]
RFC 1945 HTTP/1.0 May 1996
reserved, extra, safe, and unsafe
For definitive information on URL syntax and semantics, see RFC 1738
[4] and RFC 1808 [9]. The BNF above includes national characters
allowed in valid URLs as specified by RFC 1738, since HTTP
are not restricted in the set of unreserved characters allowed
represent the rel_path part of addresses, and HTTP proxies
receive requests for URIs not defined by RFC 1738.
3.2.2 http
The "http" scheme is used to locate network resources via the
protocol. This section defines the scheme-specific syntax
semantics for http URLs
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = Internet host domain
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
port = *
If the port is empty or not given, port 80 is assumed. The
are that the identified resource is located at the server
for TCP connections on that port of that host, and the Request-
for the resource is abs_path. If the abs_path is not present in
URL, it must be given as "/" when used as a Request-URI (
5.1.2).
Note: Although the HTTP protocol is independent of the
layer protocol, the http URL only identifies resources by
TCP location, and thus non-TCP resources must be identified
some other URI scheme
The canonical form for "http" URLs is obtained by converting
UPALPHA characters in host to their LOALPHA equivalent (hostnames
case-insensitive), eliding the [ ":" port ] if the port is 80,
replacing an empty abs_path with "/".
3.3 Date/Time
HTTP/1.0 applications have historically allowed three
formats for the representation of date/time stamps
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime()
Berners-Lee, et al Informational [Page 15]
RFC 1945 HTTP/1.0 May 1996
The first format is preferred as an Internet standard and
a fixed-length subset of that defined by RFC 1123 [6] (an update
RFC 822 [7]). The second format is in common use, but is based on
obsolete RFC 850 [10] date format and lacks a four-digit year
HTTP/1.0 clients and servers that parse the date value should
all three formats, though they must never generate the
(asctime) format
Note: Recipients of date values are encouraged to be robust
accepting date values that may have been generated by non-
applications, as is sometimes the case when retrieving or
messages via proxies/gateways to SMTP or NNTP
All HTTP/1.0 date/time stamps must be represented in Universal
(UT), also known as Greenwich Mean Time (GMT), without exception
This is indicated in the first two formats by the inclusion of "GMT
as the three-letter abbreviation for time zone, and should be
when reading the asctime format
HTTP-date = rfc1123-date | rfc850-date | asctime-
rfc1123-date = wkday "," SP date1 SP time SP "GMT
rfc850-date = weekday "," SP date2 SP time SP "GMT
asctime-date = wkday SP date3 SP time SP 4
date1 = 2DIGIT SP month SP 4
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed
| "Thu" | "Fri" | "Sat" | "Sun
weekday = "Monday" | "Tuesday" | "Wednesday
| "Thursday" | "Friday" | "Saturday" | "Sunday
month = "Jan" | "Feb" | "Mar" | "Apr
| "May" | "Jun" | "Jul" | "Aug
| "Sep" | "Oct" | "Nov" | "Dec
Note: HTTP requirements for the date/time stamp format
only to their usage within the protocol stream. Clients
servers are not required to use these formats for
Berners-Lee, et al Informational [Page 16]
RFC 1945 HTTP/1.0 May 1996
presentation, request logging, etc
3.4 Character
HTTP uses the same definition of the term "character set" as
described for MIME
The term "character set" is used in this document to refer to
method used with one or more tables to convert a sequence
octets into a sequence of characters. Note that
conversion in the other direction is not required, in that not
characters may be available in a given character set and
character set may provide more than one sequence of octets
represent a particular character. This definition is intended
allow various kinds of character encodings, from simple single
table mappings such as US-ASCII to complex table switching
such as those that use ISO 2022's techniques. However,
definition associated with a MIME character set name must
specify the mapping to be performed from octets to characters.
particular, use of external profiling information to determine
exact mapping is not permitted
Note: This use of the term "character set" is more
referred to as a "character encoding." However, since HTTP
MIME share the same registry, it is important that the
also be shared
HTTP character sets are identified by case-insensitive tokens.
complete set of tokens are defined by the IANA Character Set
[15]. However, because that registry does not define a single
consistent token for each character set, we define here the
names for those character sets most likely to be used with
entities. These character sets include those registered by RFC 1521
[5] -- the US-ASCII [17] and ISO-8859 [18] character sets --
other names specifically recommended for use within MIME
parameters
charset = "US-ASCII
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
|
Although HTTP allows an arbitrary token to be used as a
value, any token that has a predefined value within the
Character Set registry [15] must represent the character set
Berners-Lee, et al Informational [Page 17]
RFC 1945 HTTP/1.0 May 1996
by that registry. Applications should limit their use of
sets to those defined by the IANA registry
The character set of an entity body should be labelled as the
common denominator of the character codes used within that body,
the exception that no label is preferred over the labels US-ASCII
ISO-8859-1.
3.5 Content
Content coding values are used to indicate an encoding
that has been applied to a resource. Content codings are
used to allow a document to be compressed or encrypted without
the identity of its underlying media type. Typically, the resource
stored in this encoding and only decoded before rendering
analogous usage
content-coding = "x-gzip" | "x-compress" |
Note: For future compatibility, HTTP/1.0 applications
consider "gzip" and "compress" to be equivalent to "x-gzip
and "x-compress", respectively
All content-coding values are case-insensitive. HTTP/1.0
content-coding values in the Content-Encoding (Section 10.3)
field. Although the value describes the content-coding, what is
important is that it indicates what decoding mechanism will
required to remove the encoding. Note that a single program may
capable of decoding multiple content-coding formats. Two values
defined by this specification
x-
An encoding format produced by the file compression
"gzip" (GNU zip) developed by Jean-loup Gailly. This format
typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC
x-
The encoding format produced by the file compression
"compress". This format is an adaptive Lempel-Ziv-Welch
(LZW).
Note: Use of program names for the identification
encoding formats is not desirable and should be
for future encodings. Their use here is representative
historical practice, not good design
Berners-Lee, et al Informational [Page 18]
RFC 1945 HTTP/1.0 May 1996
3.6 Media
HTTP uses Internet Media Types [13] in the Content-Type header
(Section 10.5) in order to provide open and extensible data typing
media-type = type "/" subtype *( ";" parameter )
type =
subtype =
Parameters may follow the type/subtype in the form of attribute/
pairs
parameter = attribute "="
attribute =
value = token | quoted-
The type, subtype, and parameter attribute names are case
insensitive. Parameter values may or may not be case-sensitive
depending on the semantics of the parameter name. LWS must not
generated between the type and subtype, nor between an attribute
its value. Upon receipt of a media type with an
parameter, a user agent should treat the media type as if
unrecognized parameter and its value were not present
Some older HTTP applications do not recognize media type parameters
HTTP/1.0 applications should only use media type parameters when
are necessary to define the content of a message
Media-type values are registered with the Internet Assigned
Authority (IANA [15]). The media type registration process
outlined in RFC 1590 [13]. Use of non-registered media types
discouraged
3.6.1 Canonicalization and Text
Internet media types are registered with a canonical form.
general, an Entity-Body transferred via HTTP must be represented
the appropriate canonical form prior to its transmission. If the
has been encoded with a Content-Encoding, the underlying data
be in canonical form prior to being encoded
Media subtypes of the "text" type use CRLF as the text line
when in canonical form. However, HTTP allows the transport of
media with plain CR or LF alone representing a line break when
consistently within the Entity-Body. HTTP applications must
CRLF, bare CR, and bare LF as being representative of a line break
text media received via HTTP
Berners-Lee, et al Informational [Page 19]
RFC 1945 HTTP/1.0 May 1996
In addition, if the text media is represented in a character set
does not use octets 13 and 10 for CR and LF respectively, as is
case for some multi-byte character sets, HTTP allows the use
whatever octet sequences are defined by that character set
represent the equivalent of CR and LF for line breaks.
flexibility regarding line breaks applies only to text media in
Entity-Body; a bare CR or LF should not be substituted for
within any of the HTTP control structures (such as header fields
multipart boundaries).
The "charset" parameter is used with some media types to define
character set (Section 3.4) of the data. When no explicit
parameter is provided by the sender, media subtypes of the "text
type are defined to have a default charset value of "ISO-8859-1"
received via HTTP. Data in character sets other than "ISO-8859-1"
its subsets must be labelled with an appropriate charset value
order to be consistently interpreted by the recipient
Note: Many current HTTP servers provide data using charsets
than "ISO-8859-1" without proper labelling. This situation
interoperability and is not recommended. To compensate for this
some HTTP user agents provide a configuration option to allow
user to change the default interpretation of the media
character set when no charset parameter is given
3.6.2 Multipart
MIME provides for a number of "multipart" types -- encapsulations
several entities within a single message's Entity-Body. The
types registered by IANA [15] do not have any special meaning
HTTP/1.0, though user agents may need to understand each type
order to correctly interpret the purpose of each body-part. An
user agent should follow the same or similar behavior as a MIME
agent does upon receipt of a multipart type. HTTP servers should
assume that all HTTP clients are prepared to handle multipart types
All multipart types share a common syntax and must include a
parameter as part of the media type value. The message body is
a protocol element and must therefore use only CRLF to represent
breaks between body-parts. Multipart body-parts may contain
header fields which are significant to the meaning of that part
3.7 Product
Product tokens are used to allow communicating applications
identify themselves via a simple product token, with an
slash and version designator. Most fields using product tokens
allow subproducts which form a significant part of the application
Berners-Lee, et al Informational [Page 20]
RFC 1945 HTTP/1.0 May 1996
be listed, separated by whitespace. By convention, the products
listed in order of their significance for identifying
application
product = token ["/" product-version
product-version =
Examples
User-Agent: CERN-LineMode/2.15 libwww/2.17b
Server: Apache/0.8.4
Product tokens should be short and to the point -- use of them
advertizing or other non-essential information is
forbidden. Although any token character may appear in a product
version, this token should only be used for a version
(i.e., successive versions of the same product should only differ
the product-version portion of the product value).
4. HTTP
4.1 Message
HTTP messages consist of requests from client to server and
from server to client
HTTP-message = Simple-Request ; HTTP/0.9
| Simple-
| Full-Request ; HTTP/1.0
| Full-
Full-Request and Full-Response use the generic message format of
822 [7] for transferring entities. Both messages may include
header fields (also known as "headers") and an entity body.
entity body is separated from the headers by a null line (i.e.,
line with nothing preceding the CRLF).
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
[ Entity-Body ] ; Section 7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
Berners-Lee, et al Informational [Page 21]
RFC 1945 HTTP/1.0 May 1996
| Entity-Header ) ; Section 7.1
[ Entity-Body ] ; Section 7.2
Simple-Request and Simple-Response do not allow the use of any
information and are limited to a single request method (GET).
Simple-Request = "GET" SP Request-URI
Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it
the server from identifying the media type of the returned entity
4.2 Message
HTTP header fields, which include General-Header (Section 4.3),
Request-Header (Section 5.2), Response-Header (Section 6.2),
Entity-Header (Section 7.1) fields, follow the same generic format
that given in Section 3.1 of RFC 822 [7]. Each header field
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
extra line with at least one SP or HT, though this is
recommended
HTTP-header = field-name ":" [ field-value ]
field-name =
field-value = *( field-content | LWS )
field-content =
and consisting of either *TEXT or
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
Entity-Header fields
Multiple HTTP-header fields with the same field-name may be
in a message if and only if the entire field-value for that
field is defined as a comma-separated list [i.e., #(values)]. It
be possible to combine the multiple header fields into one "field
name: field-value" pair, without changing the semantics of
message, by appending each subsequent field-value to the first,
separated by a comma
Berners-Lee, et al Informational [Page 22]
RFC 1945 HTTP/1.0 May 1996
4.3 General Header
There are a few header fields which have general applicability
both request and response messages, but which do not apply to
entity being transferred. These headers apply only to the
being transmitted
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
General header field names can be extended reliably only
combination with a change in the protocol version. However, new
experimental header fields may be given the semantics of
header fields if all parties in the communication recognize them
be general header fields. Unrecognized header fields are treated
Entity-Header fields
5.
A request message from a client to a server includes, within
first line of that message, the method to be applied to the resource
the identifier of the resource, and the protocol version in use.
backwards compatibility with the more limited HTTP/0.9 protocol
there are two valid formats for an HTTP request
Request = Simple-Request | Full-
Simple-Request = "GET" SP Request-URI
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
[ Entity-Body ] ; Section 7.2
If an HTTP/1.0 server receives a Simple-Request, it must respond
an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of
a Full-Response should never generate a Simple-Request
5.1 Request-
The Request-Line begins with a method token, followed by
Request-URI and the protocol version, and ending with CRLF.
elements are separated by SP characters. No CR or LF are
except in the final CRLF sequence
Request-Line = Method SP Request-URI SP HTTP-Version
Berners-Lee, et al Informational [Page 23]
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
the availability of methods other than GET
5.1.1
The Method token indicates the method to be performed on the
identified by the Request-URI. The method is case-sensitive
Method = "GET" ; Section 8.1
| "HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-
extension-method =
The list of methods acceptable by a specific resource can
dynamically; the client is notified through the return code of
response if a method is not allowed on a resource. Servers
return the status code 501 (not implemented) if the method
unrecognized or not implemented
The methods commonly used by HTTP/1.0 applications are fully
in Section 8.
5.1.2 Request-
The Request-URI is a Uniform Resource Identifier (Section 3.2)
identifies the resource upon which to apply the request
Request-URI = absoluteURI | abs_
The two options for Request-URI are dependent on the nature of
request
The absoluteURI form is only allowed when the request is being
to a proxy. The proxy is requested to forward the request and
the response. If the request is GET or HEAD and a prior response
cached, the proxy may use the cached message if it passes
restrictions in the Expires header field. Note that the proxy
forward the request on to another proxy or directly to the
specified by the absoluteURI. In order to avoid request loops,
proxy must be able to recognize all of its server names,
any aliases, local variations, and the numeric IP address. An
Request-Line would be
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
Berners-Lee, et al Informational [Page 24]
RFC 1945 HTTP/1.0 May 1996
The most common form of Request-URI is that used to identify
resource on an origin server or gateway. In this case, only
absolute path of the URI is transmitted (see Section 3.2.1,
abs_path). For example, a client wishing to retrieve the
above directly from the origin server would create a TCP
to port 80 of the 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
path cannot be empty; if none is present in the original URI, it
be given as "/" (the server root).
The Request-URI is transmitted as an encoded string, where
characters may be escaped using the "% HEX HEX" encoding defined
RFC 1738 [4]. The origin server must decode the Request-URI in
to properly interpret the request
5.2 Request Header
The request header fields allow the client to pass
information about the request, and about the client itself, to
server. These fields act as request modifiers, with
equivalent to the parameters on a programming language
(procedure) invocation
Request-Header = Authorization ; Section 10.2
| From ; Section 10.8
| If-Modified-Since ; Section 10.9
| Referer ; Section 10.13
| User-Agent ; Section 10.15
Request-Header field names can be extended reliably only
combination with a change in the protocol version. However, new
experimental header fields may be given the semantics of
header fields if all parties in the communication recognize them
be request header fields. Unrecognized header fields are treated
Entity-Header fields
6.
After receiving and interpreting a request message, a server
in the form of an HTTP response message
Response = Simple-Response | Full-
Simple-Response = [ Entity-Body ]
Berners-Lee, et al Informational [Page 25]
RFC 1945 HTTP/1.0 May 1996
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
[ 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
HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request
receives a response that does not begin with a Status-Line, it
assume that the response is a Simple-Response and parse
accordingly. Note that the Simple-Response consists only of
entity body and is terminated by the server closing the connection
6.1 Status-
The first line of a Full-Response message is the Status-Line
consisting of the protocol version followed by a numeric status
and its associated textual phrase, with each element separated by
characters. No CR or LF is allowed except in the final CRLF sequence
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase
Since a status line always begins with the protocol version
status
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT
(e.g., "HTTP/1.0 200 "), the presence of that expression
sufficient to differentiate a Full-Response from a Simple-Response
Although the Simple-Response format may allow such an expression
occur at the beginning of an entity body, and thus cause
misinterpretation of the message if it was given in response to
Full-Request, most HTTP/0.9 servers are limited to responses of
"text/html" and therefore would never generate such a response
6.1.1 Status Code and Reason
The Status-Code element is a 3-digit integer result code of
attempt to understand and satisfy the request. The Reason-Phrase
intended to give a short textual description of the Status-Code.
Status-Code is intended for use by automata and the Reason-Phrase
intended for the human user. The client is not required to examine
display the Reason-Phrase
Berners-Lee, et al Informational [Page 26]
RFC 1945 HTTP/1.0 May 1996
The first digit of the Status-Code defines the class of response.
last two digits do not have any categorization role. There are 5
values for the first digit
o 1xx: Informational - Not used, but reserved for future
o 2xx: Success - The action was successfully received
understood, and accepted
o 3xx: Redirection - Further action must be taken in order
complete the
o 4xx: Client Error - The request contains bad syntax or
be
o 5xx: Server Error - The server failed to fulfill an
valid
The individual values of the numeric status codes defined
HTTP/1.0, and an example set of corresponding Reason-Phrase's,
presented below. The reason phrases listed here are only
-- they may be replaced by local equivalents without affecting
protocol. These codes are fully defined in Section 9.
Status-Code = "200" ;
| "201" ;
| "202" ;
| "204" ; No
| "301" ; Moved
| "302" ; Moved
| "304" ; Not
| "400" ; Bad
| "401" ;
| "403" ;
| "404" ; Not
| "500" ; Internal Server
| "501" ; Not
| "502" ; Bad
| "503" ; Service
| extension-
extension-code = 3
Reason-Phrase = *
HTTP status codes are extensible, but the above codes are the
ones generally recognized in current practice. HTTP applications
not required to understand the meaning of all registered
Berners-Lee, et al Informational [Page 27]
RFC 1945 HTTP/1.0 May 1996
codes, though such understanding is obviously desirable. However
applications must understand the class of any status code,
indicated by the first digit, and treat any unrecognized response
being equivalent to the x00 status code of that class, with
exception that an unrecognized response must not be cached.
example, if an unrecognized status code of 431 is received by
client, it can safely assume that there was something wrong with
request and treat the response as if it had received a 400
code. In such cases, user agents should present to the user
entity returned with the response, since that entity is likely
include human-readable information which will explain the
status
6.2 Response Header
The response header fields allow the server to pass
information about the response which cannot be placed in the Status
Line. These header fields give information about the server and
further access to the resource identified by the Request-URI
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
Response-Header field names can be extended reliably only
combination with a change in the protocol version. However, new
experimental header fields may be given the semantics of
header fields if all parties in the communication recognize them
be response header fields. Unrecognized header fields are treated
Entity-Header fields
7.
Full-Request and Full-Response messages may transfer an entity
some requests and responses. An entity consists of Entity-
fields and (usually) an Entity-Body. In this section, both sender
recipient refer to either the client or the server, depending on
sends and who receives the entity
Berners-Lee, et al Informational [Page 28]
RFC 1945 HTTP/1.0 May 1996
7.1 Entity Header
Entity-Header fields define optional metainformation about
Entity-Body or, if no body is present, about the resource
by the request
Entity-Header = Allow ; Section 10.1
| Content-Encoding ; Section 10.3
| Content-Length ; Section 10.4
| Content-Type ; Section 10.5
| Expires ; Section 10.7
| Last-Modified ; Section 10.10
| extension-
extension-header = HTTP-
The extension-header mechanism allows additional Entity-Header
to be defined without changing the protocol, but these fields
be assumed to be recognizable by the recipient. Unrecognized
fields should be ignored by the recipient and forwarded by proxies
7.2 Entity
The entity body (if any) sent with an HTTP request or response is
a format and encoding defined by the Entity-Header fields
Entity-Body = *
An entity body is included with a request message only when
request method calls for one. The presence of an entity body in
request is signaled by the inclusion of a Content-Length header
in the request message headers. HTTP/1.0 requests containing
entity body must include a valid Content-Length header field
For response messages, whether or not an entity body is included
a message is dependent on both the request method and the
code. All responses to the HEAD request method must not include
body, even though the presence of entity header fields may lead
to believe they do. All 1xx (informational), 204 (no content),
304 (not modified) responses must not include a body. All
responses must include an entity body or a Content-Length
field defined with a value of zero (0).
7.2.1
When an Entity-Body is included with a message, the data type of
body is determined via the header fields Content-Type and Content
Encoding. These define a two-layer, ordered encoding model
Berners-Lee, et al Informational [Page 29]
RFC 1945 HTTP/1.0 May 1996
entity-body := Content-Encoding( Content-Type( data ) )
A Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional
coding applied to the type, usually for the purpose of
compression, that is a property of the resource requested.
default for the content encoding is none (i.e., the
function).
Any HTTP/1.0 message containing an entity body should include
Content-Type header field defining the media type of that body.
and only if the media type is not given by a Content-Type header,
is the case for Simple-Response messages, the recipient may
to guess the media type via inspection of its content and/or the
extension(s) of the URL used to identify the resource. If the
type remains unknown, the recipient should treat it as
"application/octet-stream".
7.2.2
When an Entity-Body is included with a message, the length of
body may be determined in one of two ways. If a Content-Length
field is present, its value in bytes represents the length of
Entity-Body. Otherwise, the body length is determined by the
of the connection by the server
Closing the connection cannot be used to indicate the end of
request body, since it leaves no possibility for the server to
back a response. Therefore, HTTP/1.0 requests containing an
body must include a valid Content-Length header field. If a
contains an entity body and Content-Length is not specified, and
server does not recognize or cannot calculate the length from
fields, then the server should send a 400 (bad request) response
Note: Some older servers supply an invalid Content-Length
sending a document that contains server-side includes
inserted into the data stream. It must be emphasized that
will not be tolerated by future versions of HTTP. Unless
client knows that it is receiving a response from a
server, it should not depend on the Content-Length value
correct
8. Method
The set of common methods for HTTP/1.0 is defined below.
this set can be expanded, additional methods cannot be assumed
share the same semantics for separately extended clients and servers
Berners-Lee, et al Informational [Page 30]
RFC 1945 HTTP/1.0 May 1996
8.1
The GET method means retrieve whatever information (in the form of
entity) is identified by the Request-URI. If the Request-URI
to a data-producing process, it is the produced data which shall
returned as the entity in the response and not the source text of
process, unless that text happens to be the output of the process
The semantics of the GET method changes to a "conditional GET" if
request message includes an If-Modified-Since header field.
conditional GET method requests that the identified resource
transferred only if it has been modified since the date given by
If-Modified-Since header, as described in Section 10.9.
conditional GET method is intended to reduce network usage
allowing cached entities to be refreshed without requiring
requests or transferring unnecessary data
8.2
The HEAD method is identical to GET except that the server must
return any Entity-Body in the response. The metainformation
in the HTTP headers in response to a HEAD request should be
to the information sent in response to a GET request. This method
be used for obtaining metainformation about the resource
by the Request-URI without transferring the Entity-Body itself.
method is often used for testing hypertext links for validity
accessibility, and recent modification
There is no "conditional HEAD" request analogous to the
GET. If an If-Modified-Since header field is included with a
request, it should be ignored
8.3
The POST method is used to request that the destination server
the entity enclosed in the request as a new subordinate of
resource identified by the Request-URI in the Request-Line. POST
designed to allow a uniform method to cover the following functions
o Annotation of existing resources
o Posting a message to a bulletin board, newsgroup, mailing list
or similar group of articles
o Providing a block of data, such as the result of submitting
form [3], to a