7 Network Working Group T. Berners-Lee
8 Request for Comments: 1945 MIT/LCS
9 Category: Informational R. Fielding
16 Hypertext Transfer Protocol -- HTTP/1.0
20 This memo provides information for the Internet community. This memo
21 does not specify an Internet standard of any kind. Distribution of
22 this memo is unlimited.
26 The IESG has concerns about this protocol, and expects this document
27 to be replaced relatively soon by a standards track document.
31 The Hypertext Transfer Protocol (HTTP) is an application-level
32 protocol with the lightness and speed necessary for distributed,
33 collaborative, hypermedia information systems. It is a generic,
34 stateless, object-oriented protocol which can be used for many tasks,
35 such as name servers and distributed object management systems,
36 through extension of its request methods (commands). A feature of
37 HTTP is the typing of data representation, allowing systems to be
38 built independently of the data being transferred.
40 HTTP has been in use by the World-Wide Web global information
41 initiative since 1990. This specification reflects common usage of
42 the protocol referred to as "HTTP/1.0".
46 1. Introduction .............................................. 4
47 1.1 Purpose .............................................. 4
48 1.2 Terminology .......................................... 4
49 1.3 Overall Operation .................................... 6
50 1.4 HTTP and MIME ........................................ 8
51 2. Notational Conventions and Generic Grammar ................ 8
52 2.1 Augmented BNF ........................................ 8
53 2.2 Basic Rules .......................................... 10
54 3. Protocol Parameters ....................................... 12
58 Berners-Lee, et al Informational [Page 1]
60 RFC 1945 HTTP/1.0 May 1996
63 3.1 HTTP Version ......................................... 12
64 3.2 Uniform Resource Identifiers ......................... 14
65 3.2.1 General Syntax ................................ 14
66 3.2.2 http URL ...................................... 15
67 3.3 Date/Time Formats .................................... 15
68 3.4 Character Sets ....................................... 17
69 3.5 Content Codings ...................................... 18
70 3.6 Media Types .......................................... 19
71 3.6.1 Canonicalization and Text Defaults ............ 19
72 3.6.2 Multipart Types ............................... 20
73 3.7 Product Tokens ....................................... 20
74 4. HTTP Message .............................................. 21
75 4.1 Message Types ........................................ 21
76 4.2 Message Headers ...................................... 22
77 4.3 General Header Fields ................................ 23
78 5. Request ................................................... 23
79 5.1 Request-Line ......................................... 23
80 5.1.1 Method ........................................ 24
81 5.1.2 Request-URI ................................... 24
82 5.2 Request Header Fields ................................ 25
83 6. Response .................................................. 25
84 6.1 Status-Line .......................................... 26
85 6.1.1 Status Code and Reason Phrase ................. 26
86 6.2 Response Header Fields ............................... 28
87 7. Entity .................................................... 28
88 7.1 Entity Header Fields ................................. 29
89 7.2 Entity Body .......................................... 29
90 7.2.1 Type .......................................... 29
91 7.2.2 Length ........................................ 30
92 8. Method Definitions ........................................ 30
93 8.1 GET .................................................. 31
94 8.2 HEAD ................................................. 31
95 8.3 POST ................................................. 31
96 9. Status Code Definitions ................................... 32
97 9.1 Informational 1xx .................................... 32
98 9.2 Successful 2xx ....................................... 32
99 9.3 Redirection 3xx ...................................... 34
100 9.4 Client Error 4xx ..................................... 35
101 9.5 Server Error 5xx ..................................... 37
102 10. Header Field Definitions .................................. 37
103 10.1 Allow ............................................... 38
104 10.2 Authorization ....................................... 38
105 10.3 Content-Encoding .................................... 39
106 10.4 Content-Length ...................................... 39
107 10.5 Content-Type ........................................ 40
108 10.6 Date ................................................ 40
109 10.7 Expires ............................................. 41
110 10.8 From ................................................ 42
114 Berners-Lee, et al Informational [Page 2]
116 RFC 1945 HTTP/1.0 May 1996
119 10.9 If-Modified-Since ................................... 42
120 10.10 Last-Modified ....................................... 43
121 10.11 Location ............................................ 44
122 10.12 Pragma .............................................. 44
123 10.13 Referer ............................................. 44
124 10.14 Server .............................................. 45
125 10.15 User-Agent .......................................... 46
126 10.16 WWW-Authenticate .................................... 46
127 11. Access Authentication ..................................... 47
128 11.1 Basic Authentication Scheme ......................... 48
129 12. Security Considerations ................................... 49
130 12.1 Authentication of Clients ........................... 49
131 12.2 Safe Methods ........................................ 49
132 12.3 Abuse of Server Log Information ..................... 50
133 12.4 Transfer of Sensitive Information ................... 50
134 12.5 Attacks Based On File and Path Names ................ 51
135 13. Acknowledgments ........................................... 51
136 14. References ................................................ 52
137 15. Authors' Addresses ........................................ 54
138 Appendix A. Internet Media Type message/http ................ 55
139 Appendix B. Tolerant Applications ........................... 55
140 Appendix C. Relationship to MIME ............................ 56
141 C.1 Conversion to Canonical Form ......................... 56
142 C.2 Conversion of Date Formats ........................... 57
143 C.3 Introduction of Content-Encoding ..................... 57
144 C.4 No Content-Transfer-Encoding ......................... 57
145 C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
146 Appendix D. Additional Features ............................. 57
147 D.1 Additional Request Methods ........................... 58
148 D.1.1 PUT ........................................... 58
149 D.1.2 DELETE ........................................ 58
150 D.1.3 LINK .......................................... 58
151 D.1.4 UNLINK ........................................ 58
152 D.2 Additional Header Field Definitions .................. 58
153 D.2.1 Accept ........................................ 58
154 D.2.2 Accept-Charset ................................ 59
155 D.2.3 Accept-Encoding ............................... 59
156 D.2.4 Accept-Language ............................... 59
157 D.2.5 Content-Language .............................. 59
158 D.2.6 Link .......................................... 59
159 D.2.7 MIME-Version .................................. 59
160 D.2.8 Retry-After ................................... 60
161 D.2.9 Title ......................................... 60
162 D.2.10 URI ........................................... 60
170 Berners-Lee, et al Informational [Page 3]
172 RFC 1945 HTTP/1.0 May 1996
179 The Hypertext Transfer Protocol (HTTP) is an application-level
180 protocol with the lightness and speed necessary for distributed,
181 collaborative, hypermedia information systems. HTTP has been in use
182 by the World-Wide Web global information initiative since 1990. This
183 specification reflects common usage of the protocol referred too as
184 "HTTP/1.0". This specification describes the features that seem to be
185 consistently implemented in most HTTP/1.0 clients and servers. The
186 specification is split into two sections. Those features of HTTP for
187 which implementations are usually consistent are described in the
188 main body of this document. Those features which have few or
189 inconsistent implementations are listed in Appendix D.
191 Practical information systems require more functionality than simple
192 retrieval, including search, front-end update, and annotation. HTTP
193 allows an open-ended set of methods to be used to indicate the
194 purpose of a request. It builds on the discipline of reference
195 provided by the Uniform Resource Identifier (URI) [2], as a location
196 (URL) [4] or name (URN) [16], for indicating the resource on which a
197 method is to be applied. Messages are passed in a format similar to
198 that used by Internet Mail [7] and the Multipurpose Internet Mail
199 Extensions (MIME) [5].
201 HTTP is also used as a generic protocol for communication between
202 user agents and proxies/gateways to other Internet protocols, such as
203 SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing
204 basic hypermedia access to resources available from diverse
205 applications and simplifying the implementation of user agents.
209 This specification uses a number of terms to refer to the roles
210 played by participants in, and objects of, the HTTP communication.
214 A transport layer virtual circuit established between two
215 application programs for the purpose of communication.
219 The basic unit of HTTP communication, consisting of a structured
220 sequence of octets matching the syntax defined in Section 4 and
221 transmitted via the connection.
226 Berners-Lee, et al Informational [Page 4]
228 RFC 1945 HTTP/1.0 May 1996
233 An HTTP request message (as defined in Section 5).
237 An HTTP response message (as defined in Section 6).
241 A network data object or service which can be identified by a
246 A particular representation or rendition of a data resource, or
247 reply from a service resource, that may be enclosed within a
248 request or response message. An entity consists of
249 metainformation in the form of entity headers and content in the
250 form of an entity body.
254 An application program that establishes connections for the
255 purpose of sending requests.
259 The client which initiates a request. These are often browsers,
260 editors, spiders (web-traversing robots), or other end user
265 An application program that accepts connections in order to
266 service requests by sending back responses.
270 The server on which a given resource resides or is to be created.
274 An intermediary program which acts as both a server and a client
275 for the purpose of making requests on behalf of other clients.
276 Requests are serviced internally or by passing them, with
277 possible translation, on to other servers. A proxy must
278 interpret and, if necessary, rewrite a request message before
282 Berners-Lee, et al Informational [Page 5]
284 RFC 1945 HTTP/1.0 May 1996
287 forwarding it. Proxies are often used as client-side portals
288 through network firewalls and as helper applications for
289 handling requests via protocols not implemented by the user
294 A server which acts as an intermediary for some other server.
295 Unlike a proxy, a gateway receives requests as if it were the
296 origin server for the requested resource; the requesting client
297 may not be aware that it is communicating with a gateway.
298 Gateways are often used as server-side portals through network
299 firewalls and as protocol translators for access to resources
300 stored on non-HTTP systems.
304 A tunnel is an intermediary program which is acting as a blind
305 relay between two connections. Once active, a tunnel is not
306 considered a party to the HTTP communication, though the tunnel
307 may have been initiated by an HTTP request. The tunnel ceases to
308 exist when both ends of the relayed connections are closed.
309 Tunnels are used when a portal is necessary and the intermediary
310 cannot, or should not, interpret the relayed communication.
314 A program's local store of response messages and the subsystem
315 that controls its message storage, retrieval, and deletion. A
316 cache stores cachable responses in order to reduce the response
317 time and network bandwidth consumption on future, equivalent
318 requests. Any client or server may include a cache, though a
319 cache cannot be used by a server while it is acting as a tunnel.
321 Any given program may be capable of being both a client and a server;
322 our use of these terms refers only to the role being performed by the
323 program for a particular connection, rather than to the program's
324 capabilities in general. Likewise, any server may act as an origin
325 server, proxy, gateway, or tunnel, switching behavior based on the
326 nature of each request.
328 1.3 Overall Operation
330 The HTTP protocol is based on a request/response paradigm. A client
331 establishes a connection with a server and sends a request to the
332 server in the form of a request method, URI, and protocol version,
333 followed by a MIME-like message containing request modifiers, client
334 information, and possible body content. The server responds with a
338 Berners-Lee, et al Informational [Page 6]
340 RFC 1945 HTTP/1.0 May 1996
343 status line, including the message's protocol version and a success
344 or error code, followed by a MIME-like message containing server
345 information, entity metainformation, and possible body content.
347 Most HTTP communication is initiated by a user agent and consists of
348 a request to be applied to a resource on some origin server. In the
349 simplest case, this may be accomplished via a single connection (v)
350 between the user agent (UA) and the origin server (O).
352 request chain ------------------------>
353 UA -------------------v------------------- O
354 <----------------------- response chain
356 A more complicated situation occurs when one or more intermediaries
357 are present in the request/response chain. There are three common
358 forms of intermediary: proxy, gateway, and tunnel. A proxy is a
359 forwarding agent, receiving requests for a URI in its absolute form,
360 rewriting all or parts of the message, and forwarding the reformatted
361 request toward the server identified by the URI. A gateway is a
362 receiving agent, acting as a layer above some other server(s) and, if
363 necessary, translating the requests to the underlying server's
364 protocol. A tunnel acts as a relay point between two connections
365 without changing the messages; tunnels are used when the
366 communication needs to pass through an intermediary (such as a
367 firewall) even when the intermediary cannot understand the contents
370 request chain -------------------------------------->
371 UA -----v----- A -----v----- B -----v----- C -----v----- O
372 <------------------------------------- response chain
374 The figure above shows three intermediaries (A, B, and C) between the
375 user agent and origin server. A request or response message that
376 travels the whole chain must pass through four separate connections.
377 This distinction is important because some HTTP communication options
378 may apply only to the connection with the nearest, non-tunnel
379 neighbor, only to the end-points of the chain, or to all connections
380 along the chain. Although the diagram is linear, each participant may
381 be engaged in multiple, simultaneous communications. For example, B
382 may be receiving requests from many clients other than A, and/or
383 forwarding requests to servers other than C, at the same time that it
384 is handling A's request.
386 Any party to the communication which is not acting as a tunnel may
387 employ an internal cache for handling requests. The effect of a cache
388 is that the request/response chain is shortened if one of the
389 participants along the chain has a cached response applicable to that
390 request. The following illustrates the resulting chain if B has a
394 Berners-Lee, et al Informational [Page 7]
396 RFC 1945 HTTP/1.0 May 1996
399 cached copy of an earlier response from O (via C) for a request which
400 has not been cached by UA or A.
402 request chain ---------->
403 UA -----v----- A -----v----- B - - - - - - C - - - - - - O
404 <--------- response chain
406 Not all responses are cachable, and some requests may contain
407 modifiers which place special requirements on cache behavior. Some
408 HTTP/1.0 applications use heuristics to describe what is or is not a
409 "cachable" response, but these rules are not standardized.
411 On the Internet, HTTP communication generally takes place over TCP/IP
412 connections. The default port is TCP 80 [15], but other ports can be
413 used. This does not preclude HTTP from being implemented on top of
414 any other protocol on the Internet, or on other networks. HTTP only
415 presumes a reliable transport; any protocol that provides such
416 guarantees can be used, and the mapping of the HTTP/1.0 request and
417 response structures onto the transport data units of the protocol in
418 question is outside the scope of this specification.
420 Except for experimental applications, current practice requires that
421 the connection be established by the client prior to each request and
422 closed by the server after sending the response. Both clients and
423 servers should be aware that either party may close the connection
424 prematurely, due to user action, automated time-out, or program
425 failure, and should handle such closing in a predictable fashion. In
426 any case, the closing of the connection by either or both parties
427 always terminates the current request, regardless of its status.
431 HTTP/1.0 uses many of the constructs defined for MIME, as defined in
432 RFC 1521 [5]. Appendix C describes the ways in which the context of
433 HTTP allows for different use of Internet Media Types than is
434 typically found in Internet mail, and gives the rationale for those
437 2. Notational Conventions and Generic Grammar
441 All of the mechanisms specified in this document are described in
442 both prose and an augmented Backus-Naur Form (BNF) similar to that
443 used by RFC 822 [7]. Implementors will need to be familiar with the
444 notation in order to understand this specification. The augmented BNF
445 includes the following constructs:
450 Berners-Lee, et al Informational [Page 8]
452 RFC 1945 HTTP/1.0 May 1996
457 The name of a rule is simply the name itself (without any
458 enclosing "<" and ">") and is separated from its definition by
459 the equal character "=". Whitespace is only significant in that
460 indentation of continuation lines is used to indicate a rule
461 definition that spans more than one line. Certain basic rules
462 are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
463 Angle brackets are used within definitions whenever their
464 presence will facilitate discerning the use of rule names.
468 Quotation marks surround literal text. Unless stated otherwise,
469 the text is case-insensitive.
473 Elements separated by a bar ("I") are alternatives,
474 e.g., "yes | no" will accept yes or no.
478 Elements enclosed in parentheses are treated as a single
479 element. Thus, "(elem (foo | bar) elem)" allows the token
480 sequences "elem foo elem" and "elem bar elem".
484 The character "*" preceding an element indicates repetition. The
485 full form is "<n>*<m>element" indicating at least <n> and at
486 most <m> occurrences of element. Default values are 0 and
487 infinity so that "*(element)" allows any number, including zero;
488 "1*element" requires at least one; and "1*2element" allows one
493 Square brackets enclose optional elements; "[foo bar]" is
494 equivalent to "*1(foo bar)".
498 Specific repetition: "<n>(element)" is equivalent to
499 "<n>*<n>(element)"; that is, exactly <n> occurrences of
500 (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a
501 string of three alphabetic characters.
506 Berners-Lee, et al Informational [Page 9]
508 RFC 1945 HTTP/1.0 May 1996
513 A construct "#" is defined, similar to "*", for defining lists
514 of elements. The full form is "<n>#<m>element" indicating at
515 least <n> and at most <m> elements, each separated by one or
516 more commas (",") and optional linear whitespace (LWS). This
517 makes the usual form of lists very easy; a rule such as
518 "( *LWS element *( *LWS "," *LWS element ))" can be shown as
519 "1#element". Wherever this construct is used, null elements are
520 allowed, but do not contribute to the count of elements present.
521 That is, "(element), , (element)" is permitted, but counts as
522 only two elements. Therefore, where at least one element is
523 required, at least one non-null element must be present. Default
524 values are 0 and infinity so that "#(element)" allows any
525 number, including zero; "1#element" requires at least one; and
526 "1#2element" allows one or two.
530 A semi-colon, set off some distance to the right of rule text,
531 starts a comment that continues to the end of line. This is a
532 simple way of including useful notes in parallel with the
537 The grammar described by this specification is word-based.
538 Except where noted otherwise, linear whitespace (LWS) can be
539 included between any two adjacent words (token or
540 quoted-string), and between adjacent tokens and delimiters
541 (tspecials), without changing the interpretation of a field. At
542 least one delimiter (tspecials) must exist between any two
543 tokens, since they would otherwise be interpreted as a single
544 token. However, applications should attempt to follow "common
545 form" when generating HTTP constructs, since there exist some
546 implementations that fail to accept anything beyond the common
551 The following rules are used throughout this specification to
552 describe basic parsing constructs. The US-ASCII coded character set
555 OCTET = <any 8-bit sequence of data>
556 CHAR = <any US-ASCII character (octets 0 - 127)>
557 UPALPHA = <any US-ASCII uppercase letter "A".."Z">
558 LOALPHA = <any US-ASCII lowercase letter "a".."z">
562 Berners-Lee, et al Informational [Page 10]
564 RFC 1945 HTTP/1.0 May 1996
567 ALPHA = UPALPHA | LOALPHA
568 DIGIT = <any US-ASCII digit "0".."9">
569 CTL = <any US-ASCII control character
570 (octets 0 - 31) and DEL (127)>
571 CR = <US-ASCII CR, carriage return (13)>
572 LF = <US-ASCII LF, linefeed (10)>
573 SP = <US-ASCII SP, space (32)>
574 HT = <US-ASCII HT, horizontal-tab (9)>
575 <"> = <US-ASCII double-quote mark (34)>
577 HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker
578 for all protocol elements except the Entity-Body (see Appendix B for
579 tolerant applications). The end-of-line marker within an Entity-Body
580 is defined by its associated media type, as described in Section 3.6.
584 HTTP/1.0 headers may be folded onto multiple lines if each
585 continuation line begins with a space or horizontal tab. All linear
586 whitespace, including folding, has the same semantics as SP.
588 LWS = [CRLF] 1*( SP | HT )
590 However, folding of header lines is not expected by some
591 applications, and should not be generated by HTTP/1.0 applications.
593 The TEXT rule is only used for descriptive field contents and values
594 that are not intended to be interpreted by the message parser. Words
595 of *TEXT may contain octets from character sets other than US-ASCII.
597 TEXT = <any OCTET except CTLs,
600 Recipients of header field TEXT containing octets outside the US-
601 ASCII character set may assume that they represent ISO-8859-1
604 Hexadecimal numeric characters are used in several protocol elements.
606 HEX = "A" | "B" | "C" | "D" | "E" | "F"
607 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
609 Many HTTP/1.0 header field values consist of words separated by LWS
610 or special characters. These special characters must be in a quoted
611 string to be used within a parameter value.
613 word = token | quoted-string
618 Berners-Lee, et al Informational [Page 11]
620 RFC 1945 HTTP/1.0 May 1996
623 token = 1*<any CHAR except CTLs or tspecials>
625 tspecials = "(" | ")" | "<" | ">" | "@"
626 | "," | ";" | ":" | "\" | <">
627 | "/" | "[" | "]" | "?" | "="
628 | "{" | "}" | SP | HT
630 Comments may be included in some HTTP header fields by surrounding
631 the comment text with parentheses. Comments are only allowed in
632 fields containing "comment" as part of their field value definition.
633 In all other fields, parentheses are considered part of the field
636 comment = "(" *( ctext | comment ) ")"
637 ctext = <any TEXT excluding "(" and ")">
639 A string of text is parsed as a single word if it is quoted using
642 quoted-string = ( <"> *(qdtext) <"> )
644 qdtext = <any CHAR except <"> and CTLs,
647 Single-character quoting using the backslash ("\") character is not
648 permitted in HTTP/1.0.
650 3. Protocol Parameters
654 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
655 of the protocol. The protocol versioning policy is intended to allow
656 the sender to indicate the format of a message and its capacity for
657 understanding further HTTP communication, rather than the features
658 obtained via that communication. No change is made to the version
659 number for the addition of message components which do not affect
660 communication behavior or which only add to extensible field values.
661 The <minor> number is incremented when the changes made to the
662 protocol add features which do not change the general message parsing
663 algorithm, but which may add to the message semantics and imply
664 additional capabilities of the sender. The <major> number is
665 incremented when the format of a message within the protocol is
668 The version of an HTTP message is indicated by an HTTP-Version field
669 in the first line of the message. If the protocol version is not
670 specified, the recipient must assume that the message is in the
674 Berners-Lee, et al Informational [Page 12]
676 RFC 1945 HTTP/1.0 May 1996
679 simple HTTP/0.9 format.
681 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
683 Note that the major and minor numbers should be treated as separate
684 integers and that each may be incremented higher than a single digit.
685 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
686 lower than HTTP/12.3. Leading zeros should be ignored by recipients
687 and never generated by senders.
689 This document defines both the 0.9 and 1.0 versions of the HTTP
690 protocol. Applications sending Full-Request or Full-Response
691 messages, as defined by this specification, must include an HTTP-
692 Version of "HTTP/1.0".
694 HTTP/1.0 servers must:
696 o recognize the format of the Request-Line for HTTP/0.9 and
699 o understand any valid request in the format of HTTP/0.9 or
702 o respond appropriately with a message in the same protocol
703 version used by the client.
705 HTTP/1.0 clients must:
707 o recognize the format of the Status-Line for HTTP/1.0 responses;
709 o understand any valid response in the format of HTTP/0.9 or
712 Proxy and gateway applications must be careful in forwarding requests
713 that are received in a format different than that of the
714 application's native HTTP version. Since the protocol version
715 indicates the protocol capability of the sender, a proxy/gateway must
716 never send a message with a version indicator which is greater than
717 its native version; if a higher version request is received, the
718 proxy/gateway must either downgrade the request version or respond
719 with an error. Requests with a version lower than that of the
720 application's native format may be upgraded before being forwarded;
721 the proxy/gateway's response to that request must follow the server
722 requirements listed above.
730 Berners-Lee, et al Informational [Page 13]
732 RFC 1945 HTTP/1.0 May 1996
735 3.2 Uniform Resource Identifiers
737 URIs have been known by many names: WWW addresses, Universal Document
738 Identifiers, Universal Resource Identifiers [2], and finally the
739 combination of Uniform Resource Locators (URL) [4] and Names (URN)
740 [16]. As far as HTTP is concerned, Uniform Resource Identifiers are
741 simply formatted strings which identify--via name, location, or any
742 other characteristic--a network resource.
746 URIs in HTTP can be represented in absolute form or relative to some
747 known base URI [9], depending upon the context of their use. The two
748 forms are differentiated by the fact that absolute URIs always begin
749 with a scheme name followed by a colon.
751 URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
753 absoluteURI = scheme ":" *( uchar | reserved )
755 relativeURI = net_path | abs_path | rel_path
757 net_path = "//" net_loc [ abs_path ]
758 abs_path = "/" rel_path
759 rel_path = [ path ] [ ";" params ] [ "?" query ]
761 path = fsegment *( "/" segment )
765 params = param *( ";" param )
766 param = *( pchar | "/" )
768 scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
769 net_loc = *( pchar | ";" | "?" )
770 query = *( uchar | reserved )
771 fragment = *( uchar | reserved )
773 pchar = uchar | ":" | "@" | "&" | "=" | "+"
774 uchar = unreserved | escape
775 unreserved = ALPHA | DIGIT | safe | extra | national
778 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
779 extra = "!" | "*" | "'" | "(" | ")" | ","
780 safe = "$" | "-" | "_" | "."
781 unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
782 national = <any OCTET excluding ALPHA, DIGIT,
786 Berners-Lee, et al Informational [Page 14]
788 RFC 1945 HTTP/1.0 May 1996
791 reserved, extra, safe, and unsafe>
793 For definitive information on URL syntax and semantics, see RFC 1738
794 [4] and RFC 1808 [9]. The BNF above includes national characters not
795 allowed in valid URLs as specified by RFC 1738, since HTTP servers
796 are not restricted in the set of unreserved characters allowed to
797 represent the rel_path part of addresses, and HTTP proxies may
798 receive requests for URIs not defined by RFC 1738.
802 The "http" scheme is used to locate network resources via the HTTP
803 protocol. This section defines the scheme-specific syntax and
804 semantics for http URLs.
806 http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
808 host = <A legal Internet host domain name
809 or IP address (in dotted-decimal form),
810 as defined by Section 2.1 of RFC 1123>
814 If the port is empty or not given, port 80 is assumed. The semantics
815 are that the identified resource is located at the server listening
816 for TCP connections on that port of that host, and the Request-URI
817 for the resource is abs_path. If the abs_path is not present in the
818 URL, it must be given as "/" when used as a Request-URI (Section
821 Note: Although the HTTP protocol is independent of the transport
822 layer protocol, the http URL only identifies resources by their
823 TCP location, and thus non-TCP resources must be identified by
824 some other URI scheme.
826 The canonical form for "http" URLs is obtained by converting any
827 UPALPHA characters in host to their LOALPHA equivalent (hostnames are
828 case-insensitive), eliding the [ ":" port ] if the port is 80, and
829 replacing an empty abs_path with "/".
831 3.3 Date/Time Formats
833 HTTP/1.0 applications have historically allowed three different
834 formats for the representation of date/time stamps:
836 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
837 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
838 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
842 Berners-Lee, et al Informational [Page 15]
844 RFC 1945 HTTP/1.0 May 1996
847 The first format is preferred as an Internet standard and represents
848 a fixed-length subset of that defined by RFC 1123 [6] (an update to
849 RFC 822 [7]). The second format is in common use, but is based on the
850 obsolete RFC 850 [10] date format and lacks a four-digit year.
851 HTTP/1.0 clients and servers that parse the date value should accept
852 all three formats, though they must never generate the third
855 Note: Recipients of date values are encouraged to be robust in
856 accepting date values that may have been generated by non-HTTP
857 applications, as is sometimes the case when retrieving or posting
858 messages via proxies/gateways to SMTP or NNTP.
860 All HTTP/1.0 date/time stamps must be represented in Universal Time
861 (UT), also known as Greenwich Mean Time (GMT), without exception.
862 This is indicated in the first two formats by the inclusion of "GMT"
863 as the three-letter abbreviation for time zone, and should be assumed
864 when reading the asctime format.
866 HTTP-date = rfc1123-date | rfc850-date | asctime-date
868 rfc1123-date = wkday "," SP date1 SP time SP "GMT"
869 rfc850-date = weekday "," SP date2 SP time SP "GMT"
870 asctime-date = wkday SP date3 SP time SP 4DIGIT
872 date1 = 2DIGIT SP month SP 4DIGIT
873 ; day month year (e.g., 02 Jun 1982)
874 date2 = 2DIGIT "-" month "-" 2DIGIT
875 ; day-month-year (e.g., 02-Jun-82)
876 date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
877 ; month day (e.g., Jun 2)
879 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
880 ; 00:00:00 - 23:59:59
882 wkday = "Mon" | "Tue" | "Wed"
883 | "Thu" | "Fri" | "Sat" | "Sun"
885 weekday = "Monday" | "Tuesday" | "Wednesday"
886 | "Thursday" | "Friday" | "Saturday" | "Sunday"
888 month = "Jan" | "Feb" | "Mar" | "Apr"
889 | "May" | "Jun" | "Jul" | "Aug"
890 | "Sep" | "Oct" | "Nov" | "Dec"
892 Note: HTTP requirements for the date/time stamp format apply
893 only to their usage within the protocol stream. Clients and
894 servers are not required to use these formats for user
898 Berners-Lee, et al Informational [Page 16]
900 RFC 1945 HTTP/1.0 May 1996
903 presentation, request logging, etc.
907 HTTP uses the same definition of the term "character set" as that
910 The term "character set" is used in this document to refer to a
911 method used with one or more tables to convert a sequence of
912 octets into a sequence of characters. Note that unconditional
913 conversion in the other direction is not required, in that not all
914 characters may be available in a given character set and a
915 character set may provide more than one sequence of octets to
916 represent a particular character. This definition is intended to
917 allow various kinds of character encodings, from simple single-
918 table mappings such as US-ASCII to complex table switching methods
919 such as those that use ISO 2022's techniques. However, the
920 definition associated with a MIME character set name must fully
921 specify the mapping to be performed from octets to characters. In
922 particular, use of external profiling information to determine the
923 exact mapping is not permitted.
925 Note: This use of the term "character set" is more commonly
926 referred to as a "character encoding." However, since HTTP and
927 MIME share the same registry, it is important that the terminology
930 HTTP character sets are identified by case-insensitive tokens. The
931 complete set of tokens are defined by the IANA Character Set registry
932 [15]. However, because that registry does not define a single,
933 consistent token for each character set, we define here the preferred
934 names for those character sets most likely to be used with HTTP
935 entities. These character sets include those registered by RFC 1521
936 [5] -- the US-ASCII [17] and ISO-8859 [18] character sets -- and
937 other names specifically recommended for use within MIME charset
941 | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
942 | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
943 | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
944 | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
945 | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
948 Although HTTP allows an arbitrary token to be used as a charset
949 value, any token that has a predefined value within the IANA
950 Character Set registry [15] must represent the character set defined
954 Berners-Lee, et al Informational [Page 17]
956 RFC 1945 HTTP/1.0 May 1996
959 by that registry. Applications should limit their use of character
960 sets to those defined by the IANA registry.
962 The character set of an entity body should be labelled as the lowest
963 common denominator of the character codes used within that body, with
964 the exception that no label is preferred over the labels US-ASCII or
969 Content coding values are used to indicate an encoding transformation
970 that has been applied to a resource. Content codings are primarily
971 used to allow a document to be compressed or encrypted without losing
972 the identity of its underlying media type. Typically, the resource is
973 stored in this encoding and only decoded before rendering or
976 content-coding = "x-gzip" | "x-compress" | token
978 Note: For future compatibility, HTTP/1.0 applications should
979 consider "gzip" and "compress" to be equivalent to "x-gzip"
980 and "x-compress", respectively.
982 All content-coding values are case-insensitive. HTTP/1.0 uses
983 content-coding values in the Content-Encoding (Section 10.3) header
984 field. Although the value describes the content-coding, what is more
985 important is that it indicates what decoding mechanism will be
986 required to remove the encoding. Note that a single program may be
987 capable of decoding multiple content-coding formats. Two values are
988 defined by this specification:
991 An encoding format produced by the file compression program
992 "gzip" (GNU zip) developed by Jean-loup Gailly. This format is
993 typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
996 The encoding format produced by the file compression program
997 "compress". This format is an adaptive Lempel-Ziv-Welch coding
1000 Note: Use of program names for the identification of
1001 encoding formats is not desirable and should be discouraged
1002 for future encodings. Their use here is representative of
1003 historical practice, not good design.
1010 Berners-Lee, et al Informational [Page 18]
1012 RFC 1945 HTTP/1.0 May 1996
1017 HTTP uses Internet Media Types [13] in the Content-Type header field
1018 (Section 10.5) in order to provide open and extensible data typing.
1020 media-type = type "/" subtype *( ";" parameter )
1024 Parameters may follow the type/subtype in the form of attribute/value
1027 parameter = attribute "=" value
1029 value = token | quoted-string
1031 The type, subtype, and parameter attribute names are case-
1032 insensitive. Parameter values may or may not be case-sensitive,
1033 depending on the semantics of the parameter name. LWS must not be
1034 generated between the type and subtype, nor between an attribute and
1035 its value. Upon receipt of a media type with an unrecognized
1036 parameter, a user agent should treat the media type as if the
1037 unrecognized parameter and its value were not present.
1039 Some older HTTP applications do not recognize media type parameters.
1040 HTTP/1.0 applications should only use media type parameters when they
1041 are necessary to define the content of a message.
1043 Media-type values are registered with the Internet Assigned Number
1044 Authority (IANA [15]). The media type registration process is
1045 outlined in RFC 1590 [13]. Use of non-registered media types is
1048 3.6.1 Canonicalization and Text Defaults
1050 Internet media types are registered with a canonical form. In
1051 general, an Entity-Body transferred via HTTP must be represented in
1052 the appropriate canonical form prior to its transmission. If the body
1053 has been encoded with a Content-Encoding, the underlying data should
1054 be in canonical form prior to being encoded.
1056 Media subtypes of the "text" type use CRLF as the text line break
1057 when in canonical form. However, HTTP allows the transport of text
1058 media with plain CR or LF alone representing a line break when used
1059 consistently within the Entity-Body. HTTP applications must accept
1060 CRLF, bare CR, and bare LF as being representative of a line break in
1061 text media received via HTTP.
1066 Berners-Lee, et al Informational [Page 19]
1068 RFC 1945 HTTP/1.0 May 1996
1071 In addition, if the text media is represented in a character set that
1072 does not use octets 13 and 10 for CR and LF respectively, as is the
1073 case for some multi-byte character sets, HTTP allows the use of
1074 whatever octet sequences are defined by that character set to
1075 represent the equivalent of CR and LF for line breaks. This
1076 flexibility regarding line breaks applies only to text media in the
1077 Entity-Body; a bare CR or LF should not be substituted for CRLF
1078 within any of the HTTP control structures (such as header fields and
1079 multipart boundaries).
1081 The "charset" parameter is used with some media types to define the
1082 character set (Section 3.4) of the data. When no explicit charset
1083 parameter is provided by the sender, media subtypes of the "text"
1084 type are defined to have a default charset value of "ISO-8859-1" when
1085 received via HTTP. Data in character sets other than "ISO-8859-1" or
1086 its subsets must be labelled with an appropriate charset value in
1087 order to be consistently interpreted by the recipient.
1089 Note: Many current HTTP servers provide data using charsets other
1090 than "ISO-8859-1" without proper labelling. This situation reduces
1091 interoperability and is not recommended. To compensate for this,
1092 some HTTP user agents provide a configuration option to allow the
1093 user to change the default interpretation of the media type
1094 character set when no charset parameter is given.
1096 3.6.2 Multipart Types
1098 MIME provides for a number of "multipart" types -- encapsulations of
1099 several entities within a single message's Entity-Body. The multipart
1100 types registered by IANA [15] do not have any special meaning for
1101 HTTP/1.0, though user agents may need to understand each type in
1102 order to correctly interpret the purpose of each body-part. An HTTP
1103 user agent should follow the same or similar behavior as a MIME user
1104 agent does upon receipt of a multipart type. HTTP servers should not
1105 assume that all HTTP clients are prepared to handle multipart types.
1107 All multipart types share a common syntax and must include a boundary
1108 parameter as part of the media type value. The message body is itself
1109 a protocol element and must therefore use only CRLF to represent line
1110 breaks between body-parts. Multipart body-parts may contain HTTP
1111 header fields which are significant to the meaning of that part.
1115 Product tokens are used to allow communicating applications to
1116 identify themselves via a simple product token, with an optional
1117 slash and version designator. Most fields using product tokens also
1118 allow subproducts which form a significant part of the application to
1122 Berners-Lee, et al Informational [Page 20]
1124 RFC 1945 HTTP/1.0 May 1996
1127 be listed, separated by whitespace. By convention, the products are
1128 listed in order of their significance for identifying the
1131 product = token ["/" product-version]
1132 product-version = token
1136 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1138 Server: Apache/0.8.4
1140 Product tokens should be short and to the point -- use of them for
1141 advertizing or other non-essential information is explicitly
1142 forbidden. Although any token character may appear in a product-
1143 version, this token should only be used for a version identifier
1144 (i.e., successive versions of the same product should only differ in
1145 the product-version portion of the product value).
1151 HTTP messages consist of requests from client to server and responses
1152 from server to client.
1154 HTTP-message = Simple-Request ; HTTP/0.9 messages
1156 | Full-Request ; HTTP/1.0 messages
1159 Full-Request and Full-Response use the generic message format of RFC
1160 822 [7] for transferring entities. Both messages may include optional
1161 header fields (also known as "headers") and an entity body. The
1162 entity body is separated from the headers by a null line (i.e., a
1163 line with nothing preceding the CRLF).
1165 Full-Request = Request-Line ; Section 5.1
1166 *( General-Header ; Section 4.3
1167 | Request-Header ; Section 5.2
1168 | Entity-Header ) ; Section 7.1
1170 [ Entity-Body ] ; Section 7.2
1172 Full-Response = Status-Line ; Section 6.1
1173 *( General-Header ; Section 4.3
1174 | Response-Header ; Section 6.2
1178 Berners-Lee, et al Informational [Page 21]
1180 RFC 1945 HTTP/1.0 May 1996
1183 | Entity-Header ) ; Section 7.1
1185 [ Entity-Body ] ; Section 7.2
1187 Simple-Request and Simple-Response do not allow the use of any header
1188 information and are limited to a single request method (GET).
1190 Simple-Request = "GET" SP Request-URI CRLF
1192 Simple-Response = [ Entity-Body ]
1194 Use of the Simple-Request format is discouraged because it prevents
1195 the server from identifying the media type of the returned entity.
1199 HTTP header fields, which include General-Header (Section 4.3),
1200 Request-Header (Section 5.2), Response-Header (Section 6.2), and
1201 Entity-Header (Section 7.1) fields, follow the same generic format as
1202 that given in Section 3.1 of RFC 822 [7]. Each header field consists
1203 of a name followed immediately by a colon (":"), a single space (SP)
1204 character, and the field value. Field names are case-insensitive.
1205 Header fields can be extended over multiple lines by preceding each
1206 extra line with at least one SP or HT, though this is not
1209 HTTP-header = field-name ":" [ field-value ] CRLF
1212 field-value = *( field-content | LWS )
1214 field-content = <the OCTETs making up the field-value
1215 and consisting of either *TEXT or combinations
1216 of token, tspecials, and quoted-string>
1218 The order in which header fields are received is not significant.
1219 However, it is "good practice" to send General-Header fields first,
1220 followed by Request-Header or Response-Header fields prior to the
1221 Entity-Header fields.
1223 Multiple HTTP-header fields with the same field-name may be present
1224 in a message if and only if the entire field-value for that header
1225 field is defined as a comma-separated list [i.e., #(values)]. It must
1226 be possible to combine the multiple header fields into one "field-
1227 name: field-value" pair, without changing the semantics of the
1228 message, by appending each subsequent field-value to the first, each
1229 separated by a comma.
1234 Berners-Lee, et al Informational [Page 22]
1236 RFC 1945 HTTP/1.0 May 1996
1239 4.3 General Header Fields
1241 There are a few header fields which have general applicability for
1242 both request and response messages, but which do not apply to the
1243 entity being transferred. These headers apply only to the message
1246 General-Header = Date ; Section 10.6
1247 | Pragma ; Section 10.12
1249 General header field names can be extended reliably only in
1250 combination with a change in the protocol version. However, new or
1251 experimental header fields may be given the semantics of general
1252 header fields if all parties in the communication recognize them to
1253 be general header fields. Unrecognized header fields are treated as
1254 Entity-Header fields.
1258 A request message from a client to a server includes, within the
1259 first line of that message, the method to be applied to the resource,
1260 the identifier of the resource, and the protocol version in use. For
1261 backwards compatibility with the more limited HTTP/0.9 protocol,
1262 there are two valid formats for an HTTP request:
1264 Request = Simple-Request | Full-Request
1266 Simple-Request = "GET" SP Request-URI CRLF
1268 Full-Request = Request-Line ; Section 5.1
1269 *( General-Header ; Section 4.3
1270 | Request-Header ; Section 5.2
1271 | Entity-Header ) ; Section 7.1
1273 [ Entity-Body ] ; Section 7.2
1275 If an HTTP/1.0 server receives a Simple-Request, it must respond with
1276 an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving
1277 a Full-Response should never generate a Simple-Request.
1281 The Request-Line begins with a method token, followed by the
1282 Request-URI and the protocol version, and ending with CRLF. The
1283 elements are separated by SP characters. No CR or LF are allowed
1284 except in the final CRLF sequence.
1286 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
1290 Berners-Lee, et al Informational [Page 23]
1292 RFC 1945 HTTP/1.0 May 1996
1295 Note that the difference between a Simple-Request and the Request-
1296 Line of a Full-Request is the presence of the HTTP-Version field and
1297 the availability of methods other than GET.
1301 The Method token indicates the method to be performed on the resource
1302 identified by the Request-URI. The method is case-sensitive.
1304 Method = "GET" ; Section 8.1
1305 | "HEAD" ; Section 8.2
1306 | "POST" ; Section 8.3
1309 extension-method = token
1311 The list of methods acceptable by a specific resource can change
1312 dynamically; the client is notified through the return code of the
1313 response if a method is not allowed on a resource. Servers should
1314 return the status code 501 (not implemented) if the method is
1315 unrecognized or not implemented.
1317 The methods commonly used by HTTP/1.0 applications are fully defined
1322 The Request-URI is a Uniform Resource Identifier (Section 3.2) and
1323 identifies the resource upon which to apply the request.
1325 Request-URI = absoluteURI | abs_path
1327 The two options for Request-URI are dependent on the nature of the
1330 The absoluteURI form is only allowed when the request is being made
1331 to a proxy. The proxy is requested to forward the request and return
1332 the response. If the request is GET or HEAD and a prior response is
1333 cached, the proxy may use the cached message if it passes any
1334 restrictions in the Expires header field. Note that the proxy may
1335 forward the request on to another proxy or directly to the server
1336 specified by the absoluteURI. In order to avoid request loops, a
1337 proxy must be able to recognize all of its server names, including
1338 any aliases, local variations, and the numeric IP address. An example
1339 Request-Line would be:
1341 GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
1346 Berners-Lee, et al Informational [Page 24]
1348 RFC 1945 HTTP/1.0 May 1996
1351 The most common form of Request-URI is that used to identify a
1352 resource on an origin server or gateway. In this case, only the
1353 absolute path of the URI is transmitted (see Section 3.2.1,
1354 abs_path). For example, a client wishing to retrieve the resource
1355 above directly from the origin server would create a TCP connection
1356 to port 80 of the host "www.w3.org" and send the line:
1358 GET /pub/WWW/TheProject.html HTTP/1.0
1360 followed by the remainder of the Full-Request. Note that the absolute
1361 path cannot be empty; if none is present in the original URI, it must
1362 be given as "/" (the server root).
1364 The Request-URI is transmitted as an encoded string, where some
1365 characters may be escaped using the "% HEX HEX" encoding defined by
1366 RFC 1738 [4]. The origin server must decode the Request-URI in order
1367 to properly interpret the request.
1369 5.2 Request Header Fields
1371 The request header fields allow the client to pass additional
1372 information about the request, and about the client itself, to the
1373 server. These fields act as request modifiers, with semantics
1374 equivalent to the parameters on a programming language method
1375 (procedure) invocation.
1377 Request-Header = Authorization ; Section 10.2
1378 | From ; Section 10.8
1379 | If-Modified-Since ; Section 10.9
1380 | Referer ; Section 10.13
1381 | User-Agent ; Section 10.15
1383 Request-Header field names can be extended reliably only in
1384 combination with a change in the protocol version. However, new or
1385 experimental header fields may be given the semantics of request
1386 header fields if all parties in the communication recognize them to
1387 be request header fields. Unrecognized header fields are treated as
1388 Entity-Header fields.
1392 After receiving and interpreting a request message, a server responds
1393 in the form of an HTTP response message.
1395 Response = Simple-Response | Full-Response
1397 Simple-Response = [ Entity-Body ]
1402 Berners-Lee, et al Informational [Page 25]
1404 RFC 1945 HTTP/1.0 May 1996
1407 Full-Response = Status-Line ; Section 6.1
1408 *( General-Header ; Section 4.3
1409 | Response-Header ; Section 6.2
1410 | Entity-Header ) ; Section 7.1
1412 [ Entity-Body ] ; Section 7.2
1414 A Simple-Response should only be sent in response to an HTTP/0.9
1415 Simple-Request or if the server only supports the more limited
1416 HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and
1417 receives a response that does not begin with a Status-Line, it should
1418 assume that the response is a Simple-Response and parse it
1419 accordingly. Note that the Simple-Response consists only of the
1420 entity body and is terminated by the server closing the connection.
1424 The first line of a Full-Response message is the Status-Line,
1425 consisting of the protocol version followed by a numeric status code
1426 and its associated textual phrase, with each element separated by SP
1427 characters. No CR or LF is allowed except in the final CRLF sequence.
1429 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
1431 Since a status line always begins with the protocol version and
1434 "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
1436 (e.g., "HTTP/1.0 200 "), the presence of that expression is
1437 sufficient to differentiate a Full-Response from a Simple-Response.
1438 Although the Simple-Response format may allow such an expression to
1439 occur at the beginning of an entity body, and thus cause a
1440 misinterpretation of the message if it was given in response to a
1441 Full-Request, most HTTP/0.9 servers are limited to responses of type
1442 "text/html" and therefore would never generate such a response.
1444 6.1.1 Status Code and Reason Phrase
1446 The Status-Code element is a 3-digit integer result code of the
1447 attempt to understand and satisfy the request. The Reason-Phrase is
1448 intended to give a short textual description of the Status-Code. The
1449 Status-Code is intended for use by automata and the Reason-Phrase is
1450 intended for the human user. The client is not required to examine or
1451 display the Reason-Phrase.
1458 Berners-Lee, et al Informational [Page 26]
1460 RFC 1945 HTTP/1.0 May 1996
1463 The first digit of the Status-Code defines the class of response. The
1464 last two digits do not have any categorization role. There are 5
1465 values for the first digit:
1467 o 1xx: Informational - Not used, but reserved for future use
1469 o 2xx: Success - The action was successfully received,
1470 understood, and accepted.
1472 o 3xx: Redirection - Further action must be taken in order to
1473 complete the request
1475 o 4xx: Client Error - The request contains bad syntax or cannot
1478 o 5xx: Server Error - The server failed to fulfill an apparently
1481 The individual values of the numeric status codes defined for
1482 HTTP/1.0, and an example set of corresponding Reason-Phrase's, are
1483 presented below. The reason phrases listed here are only recommended
1484 -- they may be replaced by local equivalents without affecting the
1485 protocol. These codes are fully defined in Section 9.
1487 Status-Code = "200" ; OK
1490 | "204" ; No Content
1491 | "301" ; Moved Permanently
1492 | "302" ; Moved Temporarily
1493 | "304" ; Not Modified
1494 | "400" ; Bad Request
1495 | "401" ; Unauthorized
1498 | "500" ; Internal Server Error
1499 | "501" ; Not Implemented
1500 | "502" ; Bad Gateway
1501 | "503" ; Service Unavailable
1504 extension-code = 3DIGIT
1506 Reason-Phrase = *<TEXT, excluding CR, LF>
1508 HTTP status codes are extensible, but the above codes are the only
1509 ones generally recognized in current practice. HTTP applications are
1510 not required to understand the meaning of all registered status
1514 Berners-Lee, et al Informational [Page 27]
1516 RFC 1945 HTTP/1.0 May 1996
1519 codes, though such understanding is obviously desirable. However,
1520 applications must understand the class of any status code, as
1521 indicated by the first digit, and treat any unrecognized response as
1522 being equivalent to the x00 status code of that class, with the
1523 exception that an unrecognized response must not be cached. For
1524 example, if an unrecognized status code of 431 is received by the
1525 client, it can safely assume that there was something wrong with its
1526 request and treat the response as if it had received a 400 status
1527 code. In such cases, user agents should present to the user the
1528 entity returned with the response, since that entity is likely to
1529 include human-readable information which will explain the unusual
1532 6.2 Response Header Fields
1534 The response header fields allow the server to pass additional
1535 information about the response which cannot be placed in the Status-
1536 Line. These header fields give information about the server and about
1537 further access to the resource identified by the Request-URI.
1539 Response-Header = Location ; Section 10.11
1540 | Server ; Section 10.14
1541 | WWW-Authenticate ; Section 10.16
1543 Response-Header field names can be extended reliably only in
1544 combination with a change in the protocol version. However, new or
1545 experimental header fields may be given the semantics of response
1546 header fields if all parties in the communication recognize them to
1547 be response header fields. Unrecognized header fields are treated as
1548 Entity-Header fields.
1552 Full-Request and Full-Response messages may transfer an entity within
1553 some requests and responses. An entity consists of Entity-Header
1554 fields and (usually) an Entity-Body. In this section, both sender and
1555 recipient refer to either the client or the server, depending on who
1556 sends and who receives the entity.
1570 Berners-Lee, et al Informational [Page 28]
1572 RFC 1945 HTTP/1.0 May 1996
1575 7.1 Entity Header Fields
1577 Entity-Header fields define optional metainformation about the
1578 Entity-Body or, if no body is present, about the resource identified
1581 Entity-Header = Allow ; Section 10.1
1582 | Content-Encoding ; Section 10.3
1583 | Content-Length ; Section 10.4
1584 | Content-Type ; Section 10.5
1585 | Expires ; Section 10.7
1586 | Last-Modified ; Section 10.10
1589 extension-header = HTTP-header
1591 The extension-header mechanism allows additional Entity-Header fields
1592 to be defined without changing the protocol, but these fields cannot
1593 be assumed to be recognizable by the recipient. Unrecognized header
1594 fields should be ignored by the recipient and forwarded by proxies.
1598 The entity body (if any) sent with an HTTP request or response is in
1599 a format and encoding defined by the Entity-Header fields.
1601 Entity-Body = *OCTET
1603 An entity body is included with a request message only when the
1604 request method calls for one. The presence of an entity body in a
1605 request is signaled by the inclusion of a Content-Length header field
1606 in the request message headers. HTTP/1.0 requests containing an
1607 entity body must include a valid Content-Length header field.
1609 For response messages, whether or not an entity body is included with
1610 a message is dependent on both the request method and the response
1611 code. All responses to the HEAD request method must not include a
1612 body, even though the presence of entity header fields may lead one
1613 to believe they do. All 1xx (informational), 204 (no content), and
1614 304 (not modified) responses must not include a body. All other
1615 responses must include an entity body or a Content-Length header
1616 field defined with a value of zero (0).
1620 When an Entity-Body is included with a message, the data type of that
1621 body is determined via the header fields Content-Type and Content-
1622 Encoding. These define a two-layer, ordered encoding model:
1626 Berners-Lee, et al Informational [Page 29]
1628 RFC 1945 HTTP/1.0 May 1996
1631 entity-body := Content-Encoding( Content-Type( data ) )
1633 A Content-Type specifies the media type of the underlying data. A
1634 Content-Encoding may be used to indicate any additional content
1635 coding applied to the type, usually for the purpose of data
1636 compression, that is a property of the resource requested. The
1637 default for the content encoding is none (i.e., the identity
1640 Any HTTP/1.0 message containing an entity body should include a
1641 Content-Type header field defining the media type of that body. If
1642 and only if the media type is not given by a Content-Type header, as
1643 is the case for Simple-Response messages, the recipient may attempt
1644 to guess the media type via inspection of its content and/or the name
1645 extension(s) of the URL used to identify the resource. If the media
1646 type remains unknown, the recipient should treat it as type
1647 "application/octet-stream".
1651 When an Entity-Body is included with a message, the length of that
1652 body may be determined in one of two ways. If a Content-Length header
1653 field is present, its value in bytes represents the length of the
1654 Entity-Body. Otherwise, the body length is determined by the closing
1655 of the connection by the server.
1657 Closing the connection cannot be used to indicate the end of a
1658 request body, since it leaves no possibility for the server to send
1659 back a response. Therefore, HTTP/1.0 requests containing an entity
1660 body must include a valid Content-Length header field. If a request
1661 contains an entity body and Content-Length is not specified, and the
1662 server does not recognize or cannot calculate the length from other
1663 fields, then the server should send a 400 (bad request) response.
1665 Note: Some older servers supply an invalid Content-Length when
1666 sending a document that contains server-side includes dynamically
1667 inserted into the data stream. It must be emphasized that this
1668 will not be tolerated by future versions of HTTP. Unless the
1669 client knows that it is receiving a response from a compliant
1670 server, it should not depend on the Content-Length value being
1673 8. Method Definitions
1675 The set of common methods for HTTP/1.0 is defined below. Although
1676 this set can be expanded, additional methods cannot be assumed to
1677 share the same semantics for separately extended clients and servers.
1682 Berners-Lee, et al Informational [Page 30]
1684 RFC 1945 HTTP/1.0 May 1996
1689 The GET method means retrieve whatever information (in the form of an
1690 entity) is identified by the Request-URI. If the Request-URI refers
1691 to a data-producing process, it is the produced data which shall be
1692 returned as the entity in the response and not the source text of the
1693 process, unless that text happens to be the output of the process.
1695 The semantics of the GET method changes to a "conditional GET" if the
1696 request message includes an If-Modified-Since header field. A
1697 conditional GET method requests that the identified resource be
1698 transferred only if it has been modified since the date given by the
1699 If-Modified-Since header, as described in Section 10.9. The
1700 conditional GET method is intended to reduce network usage by
1701 allowing cached entities to be refreshed without requiring multiple
1702 requests or transferring unnecessary data.
1706 The HEAD method is identical to GET except that the server must not
1707 return any Entity-Body in the response. The metainformation contained
1708 in the HTTP headers in response to a HEAD request should be identical
1709 to the information sent in response to a GET request. This method can
1710 be used for obtaining metainformation about the resource identified
1711 by the Request-URI without transferring the Entity-Body itself. This
1712 method is often used for testing hypertext links for validity,
1713 accessibility, and recent modification.
1715 There is no "conditional HEAD" request analogous to the conditional
1716 GET. If an If-Modified-Since header field is included with a HEAD
1717 request, it should be ignored.
1721 The POST method is used to request that the destination server accept
1722 the entity enclosed in the request as a new subordinate of the
1723 resource identified by the Request-URI in the Request-Line. POST is
1724 designed to allow a uniform method to cover the following functions:
1726 o Annotation of existing resources;
1728 o Posting a message to a bulletin board, newsgroup, mailing list,
1729 or similar group of articles;
1731 o Providing a block of data, such as the result of submitting a
1732 form [3], to a data-handling process;
1734 o Extending a database through an append operation.
1738 Berners-Lee, et al Informational [Page 31]
1740 RFC 1945 HTTP/1.0 May 1996
1743 The actual function performed by the POST method is determined by the
1744 server and is usually dependent on the Request-URI. The posted entity
1745 is subordinate to that URI in the same way that a file is subordinate
1746 to a directory containing it, a news article is subordinate to a
1747 newsgroup to which it is posted, or a record is subordinate to a
1750 A successful POST does not require that the entity be created as a
1751 resource on the origin server or made accessible for future
1752 reference. That is, the action performed by the POST method might not
1753 result in a resource that can be identified by a URI. In this case,
1754 either 200 (ok) or 204 (no content) is the appropriate response
1755 status, depending on whether or not the response includes an entity
1756 that describes the result.
1758 If a resource has been created on the origin server, the response
1759 should be 201 (created) and contain an entity (preferably of type
1760 "text/html") which describes the status of the request and refers to
1763 A valid Content-Length is required on all HTTP/1.0 POST requests. An
1764 HTTP/1.0 server should respond with a 400 (bad request) message if it
1765 cannot determine the length of the request message's content.
1767 Applications must not cache responses to a POST request because the
1768 application has no way of knowing that the server would return an
1769 equivalent response on some future request.
1771 9. Status Code Definitions
1773 Each Status-Code is described below, including a description of which
1774 method(s) it can follow and any metainformation required in the
1777 9.1 Informational 1xx
1779 This class of status code indicates a provisional response,
1780 consisting only of the Status-Line and optional headers, and is
1781 terminated by an empty line. HTTP/1.0 does not define any 1xx status
1782 codes and they are not a valid response to a HTTP/1.0 request.
1783 However, they may be useful for experimental applications which are
1784 outside the scope of this specification.
1788 This class of status code indicates that the client's request was
1789 successfully received, understood, and accepted.
1794 Berners-Lee, et al Informational [Page 32]
1796 RFC 1945 HTTP/1.0 May 1996
1801 The request has succeeded. The information returned with the
1802 response is dependent on the method used in the request, as follows:
1804 GET an entity corresponding to the requested resource is sent
1807 HEAD the response must only contain the header information and
1810 POST an entity describing or containing the result of the action.
1814 The request has been fulfilled and resulted in a new resource being
1815 created. The newly created resource can be referenced by the URI(s)
1816 returned in the entity of the response. The origin server should
1817 create the resource before using this Status-Code. If the action
1818 cannot be carried out immediately, the server must include in the
1819 response body a description of when the resource will be available;
1820 otherwise, the server should respond with 202 (accepted).
1822 Of the methods defined by this specification, only POST can create a
1827 The request has been accepted for processing, but the processing
1828 has not been completed. The request may or may not eventually be
1829 acted upon, as it may be disallowed when processing actually takes
1830 place. There is no facility for re-sending a status code from an
1831 asynchronous operation such as this.
1833 The 202 response is intentionally non-committal. Its purpose is to
1834 allow a server to accept a request for some other process (perhaps
1835 a batch-oriented process that is only run once per day) without
1836 requiring that the user agent's connection to the server persist
1837 until the process is completed. The entity returned with this
1838 response should include an indication of the request's current
1839 status and either a pointer to a status monitor or some estimate of
1840 when the user can expect the request to be fulfilled.
1844 The server has fulfilled the request but there is no new
1845 information to send back. If the client is a user agent, it should
1846 not change its document view from that which caused the request to
1850 Berners-Lee, et al Informational [Page 33]
1852 RFC 1945 HTTP/1.0 May 1996
1855 be generated. This response is primarily intended to allow input
1856 for scripts or other actions to take place without causing a change
1857 to the user agent's active document view. The response may include
1858 new metainformation in the form of entity headers, which should
1859 apply to the document currently in the user agent's active view.
1863 This class of status code indicates that further action needs to be
1864 taken by the user agent in order to fulfill the request. The action
1865 required may be carried out by the user agent without interaction
1866 with the user if and only if the method used in the subsequent
1867 request is GET or HEAD. A user agent should never automatically
1868 redirect a request more than 5 times, since such redirections usually
1869 indicate an infinite loop.
1871 300 Multiple Choices
1873 This response code is not directly used by HTTP/1.0 applications,
1874 but serves as the default for interpreting the 3xx class of
1877 The requested resource is available at one or more locations.
1878 Unless it was a HEAD request, the response should include an entity
1879 containing a list of resource characteristics and locations from
1880 which the user or user agent can choose the one most appropriate.
1881 If the server has a preferred choice, it should include the URL in
1882 a Location field; user agents may use this field value for
1883 automatic redirection.
1885 301 Moved Permanently
1887 The requested resource has been assigned a new permanent URL and
1888 any future references to this resource should be done using that
1889 URL. Clients with link editing capabilities should automatically
1890 relink references to the Request-URI to the new reference returned
1891 by the server, where possible.
1893 The new URL must be given by the Location field in the response.
1894 Unless it was a HEAD request, the Entity-Body of the response
1895 should contain a short note with a hyperlink to the new URL.
1897 If the 301 status code is received in response to a request using
1898 the POST method, the user agent must not automatically redirect the
1899 request unless it can be confirmed by the user, since this might
1900 change the conditions under which the request was issued.
1906 Berners-Lee, et al Informational [Page 34]
1908 RFC 1945 HTTP/1.0 May 1996
1911 Note: When automatically redirecting a POST request after
1912 receiving a 301 status code, some existing user agents will
1913 erroneously change it into a GET request.
1915 302 Moved Temporarily
1917 The requested resource resides temporarily under a different URL.
1918 Since the redirection may be altered on occasion, the client should
1919 continue to use the Request-URI for future requests.
1921 The URL must be given by the Location field in the response. Unless
1922 it was a HEAD request, the Entity-Body of the response should
1923 contain a short note with a hyperlink to the new URI(s).
1925 If the 302 status code is received in response to a request using
1926 the POST method, the user agent must not automatically redirect the
1927 request unless it can be confirmed by the user, since this might
1928 change the conditions under which the request was issued.
1930 Note: When automatically redirecting a POST request after
1931 receiving a 302 status code, some existing user agents will
1932 erroneously change it into a GET request.
1936 If the client has performed a conditional GET request and access is
1937 allowed, but the document has not been modified since the date and
1938 time specified in the If-Modified-Since field, the server must
1939 respond with this status code and not send an Entity-Body to the
1940 client. Header fields contained in the response should only include
1941 information which is relevant to cache managers or which may have
1942 changed independently of the entity's Last-Modified date. Examples
1943 of relevant header fields include: Date, Server, and Expires. A
1944 cache should update its cached entity to reflect any new field
1945 values given in the 304 response.
1947 9.4 Client Error 4xx
1949 The 4xx class of status code is intended for cases in which the
1950 client seems to have erred. If the client has not completed the
1951 request when a 4xx code is received, it should immediately cease
1952 sending data to the server. Except when responding to a HEAD request,
1953 the server should include an entity containing an explanation of the
1954 error situation, and whether it is a temporary or permanent
1955 condition. These status codes are applicable to any request method.
1962 Berners-Lee, et al Informational [Page 35]
1964 RFC 1945 HTTP/1.0 May 1996
1967 Note: If the client is sending data, server implementations on TCP
1968 should be careful to ensure that the client acknowledges receipt
1969 of the packet(s) containing the response prior to closing the
1970 input connection. If the client continues sending data to the
1971 server after the close, the server's controller will send a reset
1972 packet to the client, which may erase the client's unacknowledged
1973 input buffers before they can be read and interpreted by the HTTP
1978 The request could not be understood by the server due to malformed
1979 syntax. The client should not repeat the request without
1984 The request requires user authentication. The response must include
1985 a WWW-Authenticate header field (Section 10.16) containing a
1986 challenge applicable to the requested resource. The client may
1987 repeat the request with a suitable Authorization header field
1988 (Section 10.2). If the request already included Authorization
1989 credentials, then the 401 response indicates that authorization has
1990 been refused for those credentials. If the 401 response contains
1991 the same challenge as the prior response, and the user agent has
1992 already attempted authentication at least once, then the user
1993 should be presented the entity that was given in the response,
1994 since that entity may include relevant diagnostic information. HTTP
1995 access authentication is explained in Section 11.
1999 The server understood the request, but is refusing to fulfill it.
2000 Authorization will not help and the request should not be repeated.
2001 If the request method was not HEAD and the server wishes to make
2002 public why the request has not been fulfilled, it should describe
2003 the reason for the refusal in the entity body. This status code is
2004 commonly used when the server does not wish to reveal exactly why
2005 the request has been refused, or when no other response is
2010 The server has not found anything matching the Request-URI. No
2011 indication is given of whether the condition is temporary or
2012 permanent. If the server does not wish to make this information
2013 available to the client, the status code 403 (forbidden) can be
2018 Berners-Lee, et al Informational [Page 36]
2020 RFC 1945 HTTP/1.0 May 1996
2023 9.5 Server Error 5xx
2025 Response status codes beginning with the digit "5" indicate cases in
2026 which the server is aware that it has erred or is incapable of
2027 performing the request. If the client has not completed the request
2028 when a 5xx code is received, it should immediately cease sending data
2029 to the server. Except when responding to a HEAD request, the server
2030 should include an entity containing an explanation of the error
2031 situation, and whether it is a temporary or permanent condition.
2032 These response codes are applicable to any request method and there
2033 are no required header fields.
2035 500 Internal Server Error
2037 The server encountered an unexpected condition which prevented it
2038 from fulfilling the request.
2042 The server does not support the functionality required to fulfill
2043 the request. This is the appropriate response when the server does
2044 not recognize the request method and is not capable of supporting
2045 it for any resource.
2049 The server, while acting as a gateway or proxy, received an invalid
2050 response from the upstream server it accessed in attempting to
2051 fulfill the request.
2053 503 Service Unavailable
2055 The server is currently unable to handle the request due to a
2056 temporary overloading or maintenance of the server. The implication
2057 is that this is a temporary condition which will be alleviated
2060 Note: The existence of the 503 status code does not imply
2061 that a server must use it when becoming overloaded. Some
2062 servers may wish to simply refuse the connection.
2064 10. Header Field Definitions
2066 This section defines the syntax and semantics of all commonly used
2067 HTTP/1.0 header fields. For general and entity header fields, both
2068 sender and recipient refer to either the client or the server,
2069 depending on who sends and who receives the message.
2074 Berners-Lee, et al Informational [Page 37]
2076 RFC 1945 HTTP/1.0 May 1996
2081 The Allow entity-header field lists the set of methods supported by
2082 the resource identified by the Request-URI. The purpose of this field
2083 is strictly to inform the recipient of valid methods associated with
2084 the resource. The Allow header field is not permitted in a request
2085 using the POST method, and thus should be ignored if it is received
2086 as part of a POST entity.
2088 Allow = "Allow" ":" 1#method
2094 This field cannot prevent a client from trying other methods.
2095 However, the indications given by the Allow header field value should
2096 be followed. The actual set of allowed methods is defined by the
2097 origin server at the time of each request.
2099 A proxy must not modify the Allow header field even if it does not
2100 understand all the methods specified, since the user agent may have
2101 other means of communicating with the origin server.
2103 The Allow header field does not indicate what methods are implemented
2108 A user agent that wishes to authenticate itself with a server--
2109 usually, but not necessarily, after receiving a 401 response--may do
2110 so by including an Authorization request-header field with the
2111 request. The Authorization field value consists of credentials
2112 containing the authentication information of the user agent for the
2113 realm of the resource being requested.
2115 Authorization = "Authorization" ":" credentials
2117 HTTP access authentication is described in Section 11. If a request
2118 is authenticated and a realm specified, the same credentials should
2119 be valid for all other requests within this realm.
2121 Responses to requests containing an Authorization field are not
2130 Berners-Lee, et al Informational [Page 38]
2132 RFC 1945 HTTP/1.0 May 1996
2135 10.3 Content-Encoding
2137 The Content-Encoding entity-header field is used as a modifier to the
2138 media-type. When present, its value indicates what additional content
2139 coding has been applied to the resource, and thus what decoding
2140 mechanism must be applied in order to obtain the media-type
2141 referenced by the Content-Type header field. The Content-Encoding is
2142 primarily used to allow a document to be compressed without losing
2143 the identity of its underlying media type.
2145 Content-Encoding = "Content-Encoding" ":" content-coding
2147 Content codings are defined in Section 3.5. An example of its use is
2149 Content-Encoding: x-gzip
2151 The Content-Encoding is a characteristic of the resource identified
2152 by the Request-URI. Typically, the resource is stored with this
2153 encoding and is only decoded before rendering or analogous usage.
2157 The Content-Length entity-header field indicates the size of the
2158 Entity-Body, in decimal number of octets, sent to the recipient or,
2159 in the case of the HEAD method, the size of the Entity-Body that
2160 would have been sent had the request been a GET.
2162 Content-Length = "Content-Length" ":" 1*DIGIT
2166 Content-Length: 3495
2168 Applications should use this field to indicate the size of the
2169 Entity-Body to be transferred, regardless of the media type of the
2170 entity. A valid Content-Length field value is required on all
2171 HTTP/1.0 request messages containing an entity body.
2173 Any Content-Length greater than or equal to zero is a valid value.
2174 Section 7.2.2 describes how to determine the length of a response
2175 entity body if a Content-Length is not given.
2177 Note: The meaning of this field is significantly different from
2178 the corresponding definition in MIME, where it is an optional
2179 field used within the "message/external-body" content-type. In
2180 HTTP, it should be used whenever the entity's length can be
2181 determined prior to being transferred.
2186 Berners-Lee, et al Informational [Page 39]
2188 RFC 1945 HTTP/1.0 May 1996
2193 The Content-Type entity-header field indicates the media type of the
2194 Entity-Body sent to the recipient or, in the case of the HEAD method,
2195 the media type that would have been sent had the request been a GET.
2197 Content-Type = "Content-Type" ":" media-type
2199 Media types are defined in Section 3.6. An example of the field is
2201 Content-Type: text/html
2203 Further discussion of methods for identifying the media type of an
2204 entity is provided in Section 7.2.1.
2208 The Date general-header field represents the date and time at which
2209 the message was originated, having the same semantics as orig-date in
2210 RFC 822. The field value is an HTTP-date, as described in Section
2213 Date = "Date" ":" HTTP-date
2217 Date: Tue, 15 Nov 1994 08:12:31 GMT
2219 If a message is received via direct connection with the user agent
2220 (in the case of requests) or the origin server (in the case of
2221 responses), then the date can be assumed to be the current date at
2222 the receiving end. However, since the date--as it is believed by the
2223 origin--is important for evaluating cached responses, origin servers
2224 should always include a Date header. Clients should only send a Date
2225 header field in messages that include an entity body, as in the case
2226 of the POST request, and even then it is optional. A received message
2227 which does not have a Date header field should be assigned one by the
2228 recipient if the message will be cached by that recipient or
2229 gatewayed via a protocol which requires a Date.
2231 In theory, the date should represent the moment just before the
2232 entity is generated. In practice, the date can be generated at any
2233 time during the message origination without affecting its semantic
2236 Note: An earlier version of this document incorrectly specified
2237 that this field should contain the creation date of the enclosed
2238 Entity-Body. This has been changed to reflect actual (and proper)
2242 Berners-Lee, et al Informational [Page 40]
2244 RFC 1945 HTTP/1.0 May 1996
2251 The Expires entity-header field gives the date/time after which the
2252 entity should be considered stale. This allows information providers
2253 to suggest the volatility of the resource, or a date after which the
2254 information may no longer be valid. Applications must not cache this
2255 entity beyond the date given. The presence of an Expires field does
2256 not imply that the original resource will change or cease to exist
2257 at, before, or after that time. However, information providers that
2258 know or even suspect that a resource will change by a certain date
2259 should include an Expires header with that date. The format is an
2260 absolute date and time as defined by HTTP-date in Section 3.3.
2262 Expires = "Expires" ":" HTTP-date
2264 An example of its use is
2266 Expires: Thu, 01 Dec 1994 16:00:00 GMT
2268 If the date given is equal to or earlier than the value of the Date
2269 header, the recipient must not cache the enclosed entity. If a
2270 resource is dynamic by nature, as is the case with many data-
2271 producing processes, entities from that resource should be given an
2272 appropriate Expires value which reflects that dynamism.
2274 The Expires field cannot be used to force a user agent to refresh its
2275 display or reload a resource; its semantics apply only to caching
2276 mechanisms, and such mechanisms need only check a resource's
2277 expiration status when a new request for that resource is initiated.
2279 User agents often have history mechanisms, such as "Back" buttons and
2280 history lists, which can be used to redisplay an entity retrieved
2281 earlier in a session. By default, the Expires field does not apply to
2282 history mechanisms. If the entity is still in storage, a history
2283 mechanism should display it even if the entity has expired, unless
2284 the user has specifically configured the agent to refresh expired
2287 Note: Applications are encouraged to be tolerant of bad or
2288 misinformed implementations of the Expires header. A value of zero
2289 (0) or an invalid date format should be considered equivalent to
2290 an "expires immediately." Although these values are not legitimate
2291 for HTTP/1.0, a robust implementation is always desirable.
2298 Berners-Lee, et al Informational [Page 41]
2300 RFC 1945 HTTP/1.0 May 1996
2305 The From request-header field, if given, should contain an Internet
2306 e-mail address for the human user who controls the requesting user
2307 agent. The address should be machine-usable, as defined by mailbox in
2308 RFC 822 [7] (as updated by RFC 1123 [6]):
2310 From = "From" ":" mailbox
2314 From: webmaster@w3.org
2316 This header field may be used for logging purposes and as a means for
2317 identifying the source of invalid or unwanted requests. It should not
2318 be used as an insecure form of access protection. The interpretation
2319 of this field is that the request is being performed on behalf of the
2320 person given, who accepts responsibility for the method performed. In
2321 particular, robot agents should include this header so that the
2322 person responsible for running the robot can be contacted if problems
2323 occur on the receiving end.
2325 The Internet e-mail address in this field may be separate from the
2326 Internet host which issued the request. For example, when a request
2327 is passed through a proxy, the original issuer's address should be
2330 Note: The client should not send the From header field without the
2331 user's approval, as it may conflict with the user's privacy
2332 interests or their site's security policy. It is strongly
2333 recommended that the user be able to disable, enable, and modify
2334 the value of this field at any time prior to a request.
2336 10.9 If-Modified-Since
2338 The If-Modified-Since request-header field is used with the GET
2339 method to make it conditional: if the requested resource has not been
2340 modified since the time specified in this field, a copy of the
2341 resource will not be returned from the server; instead, a 304 (not
2342 modified) response will be returned without any Entity-Body.
2344 If-Modified-Since = "If-Modified-Since" ":" HTTP-date
2346 An example of the field is:
2348 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
2354 Berners-Lee, et al Informational [Page 42]
2356 RFC 1945 HTTP/1.0 May 1996
2359 A conditional GET method requests that the identified resource be
2360 transferred only if it has been modified since the date given by the
2361 If-Modified-Since header. The algorithm for determining this includes
2362 the following cases:
2364 a) If the request would normally result in anything other than
2365 a 200 (ok) status, or if the passed If-Modified-Since date
2366 is invalid, the response is exactly the same as for a
2367 normal GET. A date which is later than the server's current
2370 b) If the resource has been modified since the
2371 If-Modified-Since date, the response is exactly the same as
2374 c) If the resource has not been modified since a valid
2375 If-Modified-Since date, the server shall return a 304 (not
2378 The purpose of this feature is to allow efficient updates of cached
2379 information with a minimum amount of transaction overhead.
2383 The Last-Modified entity-header field indicates the date and time at
2384 which the sender believes the resource was last modified. The exact
2385 semantics of this field are defined in terms of how the recipient
2386 should interpret it: if the recipient has a copy of this resource
2387 which is older than the date given by the Last-Modified field, that
2388 copy should be considered stale.
2390 Last-Modified = "Last-Modified" ":" HTTP-date
2392 An example of its use is
2394 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
2396 The exact meaning of this header field depends on the implementation
2397 of the sender and the nature of the original resource. For files, it
2398 may be just the file system last-modified time. For entities with
2399 dynamically included parts, it may be the most recent of the set of
2400 last-modify times for its component parts. For database gateways, it
2401 may be the last-update timestamp of the record. For virtual objects,
2402 it may be the last time the internal state changed.
2404 An origin server must not send a Last-Modified date which is later
2405 than the server's time of message origination. In such cases, where
2406 the resource's last modification would indicate some time in the
2410 Berners-Lee, et al Informational [Page 43]
2412 RFC 1945 HTTP/1.0 May 1996
2415 future, the server must replace that date with the message
2420 The Location response-header field defines the exact location of the
2421 resource that was identified by the Request-URI. For 3xx responses,
2422 the location must indicate the server's preferred URL for automatic
2423 redirection to the resource. Only one absolute URL is allowed.
2425 Location = "Location" ":" absoluteURI
2429 Location: http://www.w3.org/hypertext/WWW/NewLocation.html
2433 The Pragma general-header field is used to include implementation-
2434 specific directives that may apply to any recipient along the
2435 request/response chain. All pragma directives specify optional
2436 behavior from the viewpoint of the protocol; however, some systems
2437 may require that behavior be consistent with the directives.
2439 Pragma = "Pragma" ":" 1#pragma-directive
2441 pragma-directive = "no-cache" | extension-pragma
2442 extension-pragma = token [ "=" word ]
2444 When the "no-cache" directive is present in a request message, an
2445 application should forward the request toward the origin server even
2446 if it has a cached copy of what is being requested. This allows a
2447 client to insist upon receiving an authoritative response to its
2448 request. It also allows a client to refresh a cached copy which is
2449 known to be corrupted or stale.
2451 Pragma directives must be passed through by a proxy or gateway
2452 application, regardless of their significance to that application,
2453 since the directives may be applicable to all recipients along the
2454 request/response chain. It is not possible to specify a pragma for a
2455 specific recipient; however, any pragma directive not relevant to a
2456 recipient should be ignored by that recipient.
2460 The Referer request-header field allows the client to specify, for
2461 the server's benefit, the address (URI) of the resource from which
2462 the Request-URI was obtained. This allows a server to generate lists
2466 Berners-Lee, et al Informational [Page 44]
2468 RFC 1945 HTTP/1.0 May 1996
2471 of back-links to resources for interest, logging, optimized caching,
2472 etc. It also allows obsolete or mistyped links to be traced for
2473 maintenance. The Referer field must not be sent if the Request-URI
2474 was obtained from a source that does not have its own URI, such as
2475 input from the user keyboard.
2477 Referer = "Referer" ":" ( absoluteURI | relativeURI )
2481 Referer: http://www.w3.org/hypertext/DataSources/Overview.html
2483 If a partial URI is given, it should be interpreted relative to the
2484 Request-URI. The URI must not include a fragment.
2486 Note: Because the source of a link may be private information or
2487 may reveal an otherwise private information source, it is strongly
2488 recommended that the user be able to select whether or not the
2489 Referer field is sent. For example, a browser client could have a
2490 toggle switch for browsing openly/anonymously, which would
2491 respectively enable/disable the sending of Referer and From
2496 The Server response-header field contains information about the
2497 software used by the origin server to handle the request. The field
2498 can contain multiple product tokens (Section 3.7) and comments
2499 identifying the server and any significant subproducts. By
2500 convention, the product tokens are listed in order of their
2501 significance for identifying the application.
2503 Server = "Server" ":" 1*( product | comment )
2507 Server: CERN/3.0 libwww/2.17
2509 If the response is being forwarded through a proxy, the proxy
2510 application must not add its data to the product list.
2512 Note: Revealing the specific software version of the server may
2513 allow the server machine to become more vulnerable to attacks
2514 against software that is known to contain security holes. Server
2515 implementors are encouraged to make this field a configurable
2522 Berners-Lee, et al Informational [Page 45]
2524 RFC 1945 HTTP/1.0 May 1996
2527 Note: Some existing servers fail to restrict themselves to the
2528 product token syntax within the Server field.
2532 The User-Agent request-header field contains information about the
2533 user agent originating the request. This is for statistical purposes,
2534 the tracing of protocol violations, and automated recognition of user
2535 agents for the sake of tailoring responses to avoid particular user
2536 agent limitations. Although it is not required, user agents should
2537 include this field with requests. The field can contain multiple
2538 product tokens (Section 3.7) and comments identifying the agent and
2539 any subproducts which form a significant part of the user agent. By
2540 convention, the product tokens are listed in order of their
2541 significance for identifying the application.
2543 User-Agent = "User-Agent" ":" 1*( product | comment )
2547 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2549 Note: Some current proxy applications append their product
2550 information to the list in the User-Agent field. This is not
2551 recommended, since it makes machine interpretation of these
2554 Note: Some existing clients fail to restrict themselves to
2555 the product token syntax within the User-Agent field.
2557 10.16 WWW-Authenticate
2559 The WWW-Authenticate response-header field must be included in 401
2560 (unauthorized) response messages. The field value consists of at
2561 least one challenge that indicates the authentication scheme(s) and
2562 parameters applicable to the Request-URI.
2564 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
2566 The HTTP access authentication process is described in Section 11.
2567 User agents must take special care in parsing the WWW-Authenticate
2568 field value if it contains more than one challenge, or if more than
2569 one WWW-Authenticate header field is provided, since the contents of
2570 a challenge may itself contain a comma-separated list of
2571 authentication parameters.
2578 Berners-Lee, et al Informational [Page 46]
2580 RFC 1945 HTTP/1.0 May 1996
2583 11. Access Authentication
2585 HTTP provides a simple challenge-response authentication mechanism
2586 which may be used by a server to challenge a client request and by a
2587 client to provide authentication information. It uses an extensible,
2588 case-insensitive token to identify the authentication scheme,
2589 followed by a comma-separated list of attribute-value pairs which
2590 carry the parameters necessary for achieving authentication via that
2595 auth-param = token "=" quoted-string
2597 The 401 (unauthorized) response message is used by an origin server
2598 to challenge the authorization of a user agent. This response must
2599 include a WWW-Authenticate header field containing at least one
2600 challenge applicable to the requested resource.
2602 challenge = auth-scheme 1*SP realm *( "," auth-param )
2604 realm = "realm" "=" realm-value
2605 realm-value = quoted-string
2607 The realm attribute (case-insensitive) is required for all
2608 authentication schemes which issue a challenge. The realm value
2609 (case-sensitive), in combination with the canonical root URL of the
2610 server being accessed, defines the protection space. These realms
2611 allow the protected resources on a server to be partitioned into a
2612 set of protection spaces, each with its own authentication scheme
2613 and/or authorization database. The realm value is a string, generally
2614 assigned by the origin server, which may have additional semantics
2615 specific to the authentication scheme.
2617 A user agent that wishes to authenticate itself with a server--
2618 usually, but not necessarily, after receiving a 401 response--may do
2619 so by including an Authorization header field with the request. The
2620 Authorization field value consists of credentials containing the
2621 authentication information of the user agent for the realm of the
2622 resource being requested.
2624 credentials = basic-credentials
2625 | ( auth-scheme #auth-param )
2627 The domain over which credentials can be automatically applied by a
2628 user agent is determined by the protection space. If a prior request
2629 has been authorized, the same credentials may be reused for all other
2630 requests within that protection space for a period of time determined
2634 Berners-Lee, et al Informational [Page 47]
2636 RFC 1945 HTTP/1.0 May 1996
2639 by the authentication scheme, parameters, and/or user preference.
2640 Unless otherwise defined by the authentication scheme, a single
2641 protection space cannot extend outside the scope of its server.
2643 If the server does not wish to accept the credentials sent with a
2644 request, it should return a 403 (forbidden) response.
2646 The HTTP protocol does not restrict applications to this simple
2647 challenge-response mechanism for access authentication. Additional
2648 mechanisms may be used, such as encryption at the transport level or
2649 via message encapsulation, and with additional header fields
2650 specifying authentication information. However, these additional
2651 mechanisms are not defined by this specification.
2653 Proxies must be completely transparent regarding user agent
2654 authentication. That is, they must forward the WWW-Authenticate and
2655 Authorization headers untouched, and must not cache the response to a
2656 request containing Authorization. HTTP/1.0 does not provide a means
2657 for a client to be authenticated with a proxy.
2659 11.1 Basic Authentication Scheme
2661 The "basic" authentication scheme is based on the model that the user
2662 agent must authenticate itself with a user-ID and a password for each
2663 realm. The realm value should be considered an opaque string which
2664 can only be compared for equality with other realms on that server.
2665 The server will authorize the request only if it can validate the
2666 user-ID and password for the protection space of the Request-URI.
2667 There are no optional authentication parameters.
2669 Upon receipt of an unauthorized request for a URI within the
2670 protection space, the server should respond with a challenge like the
2673 WWW-Authenticate: Basic realm="WallyWorld"
2675 where "WallyWorld" is the string assigned by the server to identify
2676 the protection space of the Request-URI.
2678 To receive authorization, the client sends the user-ID and password,
2679 separated by a single colon (":") character, within a base64 [5]
2680 encoded string in the credentials.
2682 basic-credentials = "Basic" SP basic-cookie
2684 basic-cookie = <base64 [5] encoding of userid-password,
2685 except not limited to 76 char/line>
2690 Berners-Lee, et al Informational [Page 48]
2692 RFC 1945 HTTP/1.0 May 1996
2695 userid-password = [ token ] ":" *TEXT
2697 If the user agent wishes to send the user-ID "Aladdin" and password
2698 "open sesame", it would use the following header field:
2700 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
2702 The basic authentication scheme is a non-secure method of filtering
2703 unauthorized access to resources on an HTTP server. It is based on
2704 the assumption that the connection between the client and the server
2705 can be regarded as a trusted carrier. As this is not generally true
2706 on an open network, the basic authentication scheme should be used
2707 accordingly. In spite of this, clients should implement the scheme in
2708 order to communicate with servers that use it.
2710 12. Security Considerations
2712 This section is meant to inform application developers, information
2713 providers, and users of the security limitations in HTTP/1.0 as
2714 described by this document. The discussion does not include
2715 definitive solutions to the problems revealed, though it does make
2716 some suggestions for reducing security risks.
2718 12.1 Authentication of Clients
2720 As mentioned in Section 11.1, the Basic authentication scheme is not
2721 a secure method of user authentication, nor does it prevent the
2722 Entity-Body from being transmitted in clear text across the physical
2723 network used as the carrier. HTTP/1.0 does not prevent additional
2724 authentication schemes and encryption mechanisms from being employed
2725 to increase security.
2729 The writers of client software should be aware that the software
2730 represents the user in their interactions over the Internet, and
2731 should be careful to allow the user to be aware of any actions they
2732 may take which may have an unexpected significance to themselves or
2735 In particular, the convention has been established that the GET and
2736 HEAD methods should never have the significance of taking an action
2737 other than retrieval. These methods should be considered "safe." This
2738 allows user agents to represent other methods, such as POST, in a
2739 special way, so that the user is made aware of the fact that a
2740 possibly unsafe action is being requested.
2746 Berners-Lee, et al Informational [Page 49]
2748 RFC 1945 HTTP/1.0 May 1996
2751 Naturally, it is not possible to ensure that the server does not
2752 generate side-effects as a result of performing a GET request; in
2753 fact, some dynamic resources consider that a feature. The important
2754 distinction here is that the user did not request the side-effects,
2755 so therefore cannot be held accountable for them.
2757 12.3 Abuse of Server Log Information
2759 A server is in the position to save personal data about a user's
2760 requests which may identify their reading patterns or subjects of
2761 interest. This information is clearly confidential in nature and its
2762 handling may be constrained by law in certain countries. People using
2763 the HTTP protocol to provide data are responsible for ensuring that
2764 such material is not distributed without the permission of any
2765 individuals that are identifiable by the published results.
2767 12.4 Transfer of Sensitive Information
2769 Like any generic data transfer protocol, HTTP cannot regulate the
2770 content of the data that is transferred, nor is there any a priori
2771 method of determining the sensitivity of any particular piece of
2772 information within the context of any given request. Therefore,
2773 applications should supply as much control over this information as
2774 possible to the provider of that information. Three header fields are
2775 worth special mention in this context: Server, Referer and From.
2777 Revealing the specific software version of the server may allow the
2778 server machine to become more vulnerable to attacks against software
2779 that is known to contain security holes. Implementors should make the
2780 Server header field a configurable option.
2782 The Referer field allows reading patterns to be studied and reverse
2783 links drawn. Although it can be very useful, its power can be abused
2784 if user details are not separated from the information contained in
2785 the Referer. Even when the personal information has been removed, the
2786 Referer field may indicate a private document's URI whose publication
2787 would be inappropriate.
2789 The information sent in the From field might conflict with the user's
2790 privacy interests or their site's security policy, and hence it
2791 should not be transmitted without the user being able to disable,
2792 enable, and modify the contents of the field. The user must be able
2793 to set the contents of this field within a user preference or
2794 application defaults configuration.
2796 We suggest, though do not require, that a convenient toggle interface
2797 be provided for the user to enable or disable the sending of From and
2798 Referer information.
2802 Berners-Lee, et al Informational [Page 50]
2804 RFC 1945 HTTP/1.0 May 1996
2807 12.5 Attacks Based On File and Path Names
2809 Implementations of HTTP origin servers should be careful to restrict
2810 the documents returned by HTTP requests to be only those that were
2811 intended by the server administrators. If an HTTP server translates
2812 HTTP URIs directly into file system calls, the server must take
2813 special care not to serve files that were not intended to be
2814 delivered to HTTP clients. For example, Unix, Microsoft Windows, and
2815 other operating systems use ".." as a path component to indicate a
2816 directory level above the current one. On such a system, an HTTP
2817 server must disallow any such construct in the Request-URI if it
2818 would otherwise allow access to a resource outside those intended to
2819 be accessible via the HTTP server. Similarly, files intended for
2820 reference only internally to the server (such as access control
2821 files, configuration files, and script code) must be protected from
2822 inappropriate retrieval, since they might contain sensitive
2823 information. Experience has shown that minor bugs in such HTTP server
2824 implementations have turned into security risks.
2828 This specification makes heavy use of the augmented BNF and generic
2829 constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it
2830 reuses many of the definitions provided by Nathaniel Borenstein and
2831 Ned Freed for MIME [5]. We hope that their inclusion in this
2832 specification will help reduce past confusion over the relationship
2833 between HTTP/1.0 and Internet mail message formats.
2835 The HTTP protocol has evolved considerably over the past four years.
2836 It has benefited from a large and active developer community--the
2837 many people who have participated on the www-talk mailing list--and
2838 it is that community which has been most responsible for the success
2839 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
2840 Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip
2841 M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou
2842 Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve
2843 special recognition for their efforts in defining aspects of the
2844 protocol for early versions of this specification.
2846 Paul Hoffman contributed sections regarding the informational status
2847 of this document and Appendices C and D.
2858 Berners-Lee, et al Informational [Page 51]
2860 RFC 1945 HTTP/1.0 May 1996
2863 This document has benefited greatly from the comments of all those
2864 participating in the HTTP-WG. In addition to those already mentioned,
2865 the following individuals have contributed to this specification:
2867 Gary Adams Harald Tveit Alvestrand
2868 Keith Ball Brian Behlendorf
2869 Paul Burchard Maurizio Codogno
2870 Mike Cowlishaw Roman Czyborra
2871 Michael A. Dolan John Franks
2872 Jim Gettys Marc Hedlund
2873 Koen Holtman Alex Hopmann
2874 Bob Jernigan Shel Kaphan
2875 Martijn Koster Dave Kristol
2876 Daniel LaLiberte Paul Leach
2877 Albert Lunde John C. Mallery
2878 Larry Masinter Mitra
2879 Jeffrey Mogul Gavin Nicol
2880 Bill Perry Jeffrey Perry
2881 Owen Rees Luigi Rizzo
2882 David Robinson Marc Salomon
2883 Rich Salz Jim Seidman
2884 Chuck Shotton Eric W. Sink
2885 Simon E. Spero Robert S. Thau
2886 Francois Yergeau Mary Ellen Zurko
2887 Jean-Philippe Martin-Flatin
2891 [1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
2892 Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
2893 Distributed Document Search and Retrieval Protocol", RFC 1436,
2894 University of Minnesota, March 1993.
2896 [2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
2897 Unifying Syntax for the Expression of Names and Addresses of
2898 Objects on the Network as used in the World-Wide Web",
2899 RFC 1630, CERN, June 1994.
2901 [3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2902 2.0", RFC 1866, MIT/W3C, November 1995.
2904 [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
2905 Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
2906 University of Minnesota, December 1994.
2914 Berners-Lee, et al Informational [Page 52]
2916 RFC 1945 HTTP/1.0 May 1996
2919 [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
2920 Extensions) Part One: Mechanisms for Specifying and Describing
2921 the Format of Internet Message Bodies", RFC 1521, Bellcore,
2922 Innosoft, September 1993.
2924 [6] Braden, R., "Requirements for Internet hosts - Application and
2925 Support", STD 3, RFC 1123, IETF, October 1989.
2927 [7] Crocker, D., "Standard for the Format of ARPA Internet Text
2928 Messages", STD 11, RFC 822, UDEL, August 1982.
2930 [8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
2931 J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
2932 Functional Specification." (v1.5), Thinking Machines
2933 Corporation, April 1990.
2935 [9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
2936 UC Irvine, June 1995.
2938 [10] Horton, M., and R. Adams, "Standard for interchange of USENET
2939 Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
2940 Laboratories, Center for Seismic Studies, December 1987.
2942 [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
2943 A Proposed Standard for the Stream-Based Transmission of News",
2944 RFC 977, UC San Diego, UC Berkeley, February 1986.
2946 [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
2947 USC/ISI, August 1982.
2949 [13] Postel, J., "Media Type Registration Procedure." RFC 1590,
2950 USC/ISI, March 1994.
2952 [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
2953 STD 9, RFC 959, USC/ISI, October 1985.
2955 [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
2956 1700, USC/ISI, October 1994.
2958 [16] Sollins, K., and L. Masinter, "Functional Requirements for
2959 Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
2962 [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
2963 for Information Interchange. Standard ANSI X3.4-1986, ANSI,
2970 Berners-Lee, et al Informational [Page 53]
2972 RFC 1945 HTTP/1.0 May 1996
2975 [18] ISO-8859. International Standard -- Information Processing --
2976 8-bit Single-Byte Coded Graphic Character Sets --
2977 Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
2978 Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
2979 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
2980 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
2981 Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
2982 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
2983 Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
2984 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
2985 Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
2987 15. Authors' Addresses
2990 Director, W3 Consortium
2991 MIT Laboratory for Computer Science
2992 545 Technology Square
2993 Cambridge, MA 02139, U.S.A.
2995 Fax: +1 (617) 258 8682
3000 Department of Information and Computer Science
3001 University of California
3002 Irvine, CA 92717-3425, U.S.A.
3004 Fax: +1 (714) 824-4056
3005 EMail: fielding@ics.uci.edu
3008 Henrik Frystyk Nielsen
3010 MIT Laboratory for Computer Science
3011 545 Technology Square
3012 Cambridge, MA 02139, U.S.A.
3014 Fax: +1 (617) 258 8682
3015 EMail: frystyk@w3.org
3026 Berners-Lee, et al Informational [Page 54]
3028 RFC 1945 HTTP/1.0 May 1996
3033 These appendices are provided for informational reasons only -- they
3034 do not form a part of the HTTP/1.0 specification.
3036 A. Internet Media Type message/http
3038 In addition to defining the HTTP/1.0 protocol, this document serves
3039 as the specification for the Internet media type "message/http". The
3040 following is to be registered with IANA [13].
3042 Media Type name: message
3044 Media subtype name: http
3046 Required parameters: none
3048 Optional parameters: version, msgtype
3050 version: The HTTP-Version number of the enclosed message
3051 (e.g., "1.0"). If not present, the version can be
3052 determined from the first line of the body.
3054 msgtype: The message type -- "request" or "response". If
3055 not present, the type can be determined from the
3056 first line of the body.
3058 Encoding considerations: only "7bit", "8bit", or "binary" are
3061 Security considerations: none
3063 B. Tolerant Applications
3065 Although this document specifies the requirements for the generation
3066 of HTTP/1.0 messages, not all applications will be correct in their
3067 implementation. We therefore recommend that operational applications
3068 be tolerant of deviations whenever those deviations can be
3069 interpreted unambiguously.
3071 Clients should be tolerant in parsing the Status-Line and servers
3072 tolerant when parsing the Request-Line. In particular, they should
3073 accept any amount of SP or HT characters between fields, even though
3074 only a single SP is required.
3076 The line terminator for HTTP-header fields is the sequence CRLF.
3077 However, we recommend that applications, when parsing such headers,
3078 recognize a single LF as a line terminator and ignore the leading CR.
3082 Berners-Lee, et al Informational [Page 55]
3084 RFC 1945 HTTP/1.0 May 1996
3087 C. Relationship to MIME
3089 HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC
3090 822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to
3091 allow entities to be transmitted in an open variety of
3092 representations and with extensible mechanisms. However, RFC 1521
3093 discusses mail, and HTTP has a few features that are different than
3094 those described in RFC 1521. These differences were carefully chosen
3095 to optimize performance over binary connections, to allow greater
3096 freedom in the use of new media types, to make date comparisons
3097 easier, and to acknowledge the practice of some early HTTP servers
3100 At the time of this writing, it is expected that RFC 1521 will be
3101 revised. The revisions may include some of the practices found in
3102 HTTP/1.0 but not in RFC 1521.
3104 This appendix describes specific areas where HTTP differs from RFC
3105 1521. Proxies and gateways to strict MIME environments should be
3106 aware of these differences and provide the appropriate conversions
3107 where necessary. Proxies and gateways from MIME environments to HTTP
3108 also need to be aware of the differences because some conversions may
3111 C.1 Conversion to Canonical Form
3113 RFC 1521 requires that an Internet mail entity be converted to
3114 canonical form prior to being transferred, as described in Appendix G
3115 of RFC 1521 [5]. Section 3.6.1 of this document describes the forms
3116 allowed for subtypes of the "text" media type when transmitted over
3119 RFC 1521 requires that content with a Content-Type of "text"
3120 represent line breaks as CRLF and forbids the use of CR or LF outside
3121 of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
3122 indicate a line break within text content when a message is
3123 transmitted over HTTP.
3125 Where it is possible, a proxy or gateway from HTTP to a strict RFC
3126 1521 environment should translate all line breaks within the text
3127 media types described in Section 3.6.1 of this document to the RFC
3128 1521 canonical form of CRLF. Note, however, that this may be
3129 complicated by the presence of a Content-Encoding and by the fact
3130 that HTTP allows the use of some character sets which do not use
3131 octets 13 and 10 to represent CR and LF, as is the case for some
3132 multi-byte character sets.
3138 Berners-Lee, et al Informational [Page 56]
3140 RFC 1945 HTTP/1.0 May 1996
3143 C.2 Conversion of Date Formats
3145 HTTP/1.0 uses a restricted set of date formats (Section 3.3) to
3146 simplify the process of date comparison. Proxies and gateways from
3147 other protocols should ensure that any Date header field present in a
3148 message conforms to one of the HTTP/1.0 formats and rewrite the date
3151 C.3 Introduction of Content-Encoding
3153 RFC 1521 does not include any concept equivalent to HTTP/1.0's
3154 Content-Encoding header field. Since this acts as a modifier on the
3155 media type, proxies and gateways from HTTP to MIME-compliant
3156 protocols must either change the value of the Content-Type header
3157 field or decode the Entity-Body before forwarding the message. (Some
3158 experimental applications of Content-Type for Internet mail have used
3159 a media-type parameter of ";conversions=<content-coding>" to perform
3160 an equivalent function as Content-Encoding. However, this parameter
3161 is not part of RFC 1521.)
3163 C.4 No Content-Transfer-Encoding
3165 HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
3166 1521. Proxies and gateways from MIME-compliant protocols to HTTP must
3167 remove any non-identity CTE ("quoted-printable" or "base64") encoding
3168 prior to delivering the response message to an HTTP client.
3170 Proxies and gateways from HTTP to MIME-compliant protocols are
3171 responsible for ensuring that the message is in the correct format
3172 and encoding for safe transport on that protocol, where "safe
3173 transport" is defined by the limitations of the protocol being used.
3174 Such a proxy or gateway should label the data with an appropriate
3175 Content-Transfer-Encoding if doing so will improve the likelihood of
3176 safe transport over the destination protocol.
3178 C.5 HTTP Header Fields in Multipart Body-Parts
3180 In RFC 1521, most header fields in multipart body-parts are generally
3181 ignored unless the field name begins with "Content-". In HTTP/1.0,
3182 multipart body-parts may contain any HTTP header fields which are
3183 significant to the meaning of that part.
3185 D. Additional Features
3187 This appendix documents protocol elements used by some existing HTTP
3188 implementations, but not consistently and correctly across most
3189 HTTP/1.0 applications. Implementors should be aware of these
3190 features, but cannot rely upon their presence in, or interoperability
3194 Berners-Lee, et al Informational [Page 57]
3196 RFC 1945 HTTP/1.0 May 1996
3199 with, other HTTP/1.0 applications.
3201 D.1 Additional Request Methods
3205 The PUT method requests that the enclosed entity be stored under the
3206 supplied Request-URI. If the Request-URI refers to an already
3207 existing resource, the enclosed entity should be considered as a
3208 modified version of the one residing on the origin server. If the
3209 Request-URI does not point to an existing resource, and that URI is
3210 capable of being defined as a new resource by the requesting user
3211 agent, the origin server can create the resource with that URI.
3213 The fundamental difference between the POST and PUT requests is
3214 reflected in the different meaning of the Request-URI. The URI in a
3215 POST request identifies the resource that will handle the enclosed
3216 entity as data to be processed. That resource may be a data-accepting
3217 process, a gateway to some other protocol, or a separate entity that
3218 accepts annotations. In contrast, the URI in a PUT request identifies
3219 the entity enclosed with the request -- the user agent knows what URI
3220 is intended and the server should not apply the request to some other
3225 The DELETE method requests that the origin server delete the resource
3226 identified by the Request-URI.
3230 The LINK method establishes one or more Link relationships between
3231 the existing resource identified by the Request-URI and other
3236 The UNLINK method removes one or more Link relationships from the
3237 existing resource identified by the Request-URI.
3239 D.2 Additional Header Field Definitions
3243 The Accept request-header field can be used to indicate a list of
3244 media ranges which are acceptable as a response to the request. The
3245 asterisk "*" character is used to group media types into ranges, with
3246 "*/*" indicating all media types and "type/*" indicating all subtypes
3250 Berners-Lee, et al Informational [Page 58]
3252 RFC 1945 HTTP/1.0 May 1996
3255 of that type. The set of ranges given by the client should represent
3256 what types are acceptable given the context of the request.
3258 D.2.2 Accept-Charset
3260 The Accept-Charset request-header field can be used to indicate a
3261 list of preferred character sets other than the default US-ASCII and
3262 ISO-8859-1. This field allows clients capable of understanding more
3263 comprehensive or special-purpose character sets to signal that
3264 capability to a server which is capable of representing documents in
3265 those character sets.
3267 D.2.3 Accept-Encoding
3269 The Accept-Encoding request-header field is similar to Accept, but
3270 restricts the content-coding values which are acceptable in the
3273 D.2.4 Accept-Language
3275 The Accept-Language request-header field is similar to Accept, but
3276 restricts the set of natural languages that are preferred as a
3277 response to the request.
3279 D.2.5 Content-Language
3281 The Content-Language entity-header field describes the natural
3282 language(s) of the intended audience for the enclosed entity. Note
3283 that this may not be equivalent to all the languages used within the
3288 The Link entity-header field provides a means for describing a
3289 relationship between the entity and some other resource. An entity
3290 may include multiple Link values. Links at the metainformation level
3291 typically indicate relationships like hierarchical structure and
3296 HTTP messages may include a single MIME-Version general-header field
3297 to indicate what version of the MIME protocol was used to construct
3298 the message. Use of the MIME-Version header field, as defined by RFC
3299 1521 [5], should indicate that the message is MIME-conformant.
3300 Unfortunately, some older HTTP/1.0 servers send it indiscriminately,
3301 and thus this field should be ignored.
3306 Berners-Lee, et al Informational [Page 59]
3308 RFC 1945 HTTP/1.0 May 1996
3313 The Retry-After response-header field can be used with a 503 (service
3314 unavailable) response to indicate how long the service is expected to
3315 be unavailable to the requesting client. The value of this field can
3316 be either an HTTP-date or an integer number of seconds (in decimal)
3317 after the time of the response.
3321 The Title entity-header field indicates the title of the entity.
3325 The URI entity-header field may contain some or all of the Uniform
3326 Resource Identifiers (Section 3.2) by which the Request-URI resource
3327 can be identified. There is no guarantee that the resource can be
3328 accessed using the URI(s) specified.
3362 Berners-Lee, et al Informational [Page 60]
projects / profile / ivi / libsoup2.4.git / blob