HTTP Working Group
`INTERNET-DRAFT
`<draft-ietf-http-v11-spec-00.txt>
`Expires May 22, 1996
`
`R. Fielding, UC Irvine
`H. Frystyk, MIT/LCS
`T. Berners-Lee, MIT/LCS
`November 22, 1995
`
`Hypertext Transfer Protocol -- HTTP/1.1
`
`Status of this Memo
`
` This document is an Internet-Draft. Internet-Drafts are working
` documents of the Internet Engineering Task Force (IETF), its areas,
` and its working groups. Note that other groups may also distribute
` working documents as Internet-Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of six
` months and may be updated, replaced, or obsoleted by other
` documents at any time. It is inappropriate to use Internet-Drafts
` as reference material or to cite them other than as "work in
` progress".
`
` To learn the current status of any Internet-Draft, please check the
` "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
` Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
` munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
` ftp.isi.edu (US West Coast).
`
` Distribution of this document is unlimited. Please send comments to
` the HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions
` of the working group are archived at
` <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
` about HTTP and the applications which use HTTP should take place on
` the <www-talk@w3.org> mailing list.
`
`Abstract
`
` The Hypertext Transfer Protocol (HTTP) is an application-level
` protocol for distributed, collaborative, hypermedia information
` systems. It is a generic, stateless, object-oriented protocol which
` can be used for many tasks, such as name servers and distributed
` object management systems, through extension of its request methods
` (commands). A feature of HTTP is the typing and negotiation of data
` representation, allowing systems to be built independently of the
` data being transferred.
`
` HTTP has been in use by the World-Wide Web global information
` initiative since 1990. This specification defines the protocol
` referred to as "HTTP/1.1".
`
`Table of Contents
`
`1. Introduction
`1.1 Purpose
`1.2 Requirements
`1.3 Terminology
`1.4 Overall Operation
`
`2. Notational Conventions and Generic Grammar
`2.1 Augmented BNF
`2.2 Basic Rules
`
`001
`
`Apple Inc.
`APL1111
`U.S. Patent No. 8,724,622
`
`

`

`3. Protocol Parameters
`3.1 HTTP Version
`3.2 Uniform Resource Identifiers
`3.2.1 General Syntax
`3.2.2 http URL
`3.3 Date/Time Formats
`3.3.1 Full Date
`3.3.2 Delta Seconds
`3.4 Character Sets
`3.5 Content Codings
`3.6 Transfer Codings
`3.7 Media Types
`3.7.1 Canonicalization and Text Defaults
`3.7.2 Multipart Types
`3.8 Product Tokens
`3.9 Quality Values
`3.10 Language Tags
`3.11 Logic Bags
`
`4. HTTP Message
`4.1 Message Types
`4.2 Message Headers
`4.3 General Header Fields
`
`5. Request
`5.1 Request-Line
`5.1.1 Method
`5.1.2 Request-URI
`5.2 Request Header Fields
`
`6. Response
`6.1 Status-Line
`6.1.1 Status Code and Reason Phrase
`6.2 Response Header Fields
`
`7. Entity
`7.1 Entity Header Fields
`7.2 Entity Body
`7.2.1 Type
`7.2.2 Length
`
`8. Method Definitions
`8.1 OPTIONS
`8.2 GET
`8.3 HEAD
`8.4 POST
`8.5 PUT
`8.6 PATCH
`8.7 COPY
`8.8 MOVE
`8.9 DELETE
`8.10 LINK
`8.11 UNLINK
`8.12 TRACE
`8.13 WRAPPED
`
`9. Status Code Definitions
`9.1 Informational 1xx
`9.2 Successful 2xx
`9.3 Redirection 3xx
`
`002
`
`

`

` 9.4 Client Error 4xx
` 9.5 Server Error 5xx
`
` 10. Header Field Definitions
` 10.1 Accept
` 10.2 Accept-Charset
` 10.3 Accept-Encoding
` 10.4 Accept-Language
` 10.5 Allow
` 10.6 Authorization
` 10.7 Base
` 10.8 Cache-Control
` 10.9 Connection
` 10.9.1 Persistent Connections
` 10.10 Content-Encoding
` 10.11 Content-Language
` 10.12 Content-Length
` 10.13 Content-MD5
` 10.14 Content-Range
` 10.15 Content-Type
` 10.16 Content-Version
` 10.17 Date
` 10.18 Derived-From
` 10.19 Expires
` 10.20 Forwarded
` 10.21 From
` 10.22 Host
` 10.23 If-Modified-Since
` 10.24 Keep-Alive
` 10.25 Last-Modified
` 10.26 Link
` 10.27 Location
` 10.28 MIME-Version
` 10.29 Pragma
` 10.30 Proxy-Authenticate
` 10.31 Proxy-Authorization
` 10.32 Public
` 10.33 Range
` 10.34 Referer
` 10.35 Refresh
` 10.36 Retry-After
` 10.37 Server
` 10.38 Title
` 10.39 Transfer Encoding
` 10.40 Unless
` 10.41 Upgrade
` 10.42 URI
` 10.43 User-Agent
` 10.44 WWW-Authenticate
`
` 11. Access Authentication
` 11.1 Basic Authentication Scheme
` 11.2 Digest Authentication Scheme
`
` 12. Content Negotiation
` 12.1 Preemptive Negotiation
`
` 13. Caching
`
` 14. Security Considerations
` 14.1 Authentication of Clients
`
`003
`
`

`

` 14.2 Safe Methods
` 14.3 Abuse of Server Log Information
` 14.4 Transfer of Sensitive Information
`
` 15. Acknowledgments
`
` 16. References
`
` 17. Authors’ Addresses
`
`Appendix A. Internet Media Type message/http
`Appendix B. Tolerant Applications
`Appendix C. Relationship to MIME
` C.1 Conversion to Canonical Form
` C.1.1 Representation of Line Breaks
` C.1.2 Default Character Set
` C.2 Conversion of Date Formats
` C.3 Introduction of Content-Encoding
` C.4 No Content-Transfer-Encoding
` C.5 Introduction of Transfer-Encoding
`Appendix D. Changes from HTTP/1.0
`
`1. Introduction
`
`1.1 Purpose
`
` The Hypertext Transfer Protocol (HTTP) is an application-level
` protocol for distributed, collaborative, hypermedia information
` systems. HTTP has been in use by the World-Wide Web global
` information initiative since 1990. The first version of HTTP,
` referred to as HTTP/0.9, was a simple protocol for raw data
` transfer across the Internet. HTTP/1.0, as defined by RFC xxxx [6],
` improved the protocol by allowing messages to be in the format of
` MIME-like entities, containing metainformation about the data
` transferred and modifiers on the request/response semantics.
` However, HTTP/1.0 does not sufficiently take into consideration the
` effect of hierarchical proxies and caching, the desire for
` persistent connections and virtual hosts, and a number of other
` details that slipped through the cracks of existing
` implementations. In addition, the proliferation of incompletely-
` implemented applications calling themselves "HTTP/1.0" has
` necessitated a protocol version change in order for two
` communicating applications to determine each other’s true
` capabilities.
`
` This specification defines the protocol referred to as "HTTP/1.1".
` This protocol is backwards-compatible with HTTP/1.0, but includes
` more stringent requirements in order to ensure reliable
` implementation of its features.
`
` Practical information systems require more functionality than
` simple retrieval, including search, front-end update, and
` annotation. HTTP allows an open-ended set of methods to be used to
` indicate the purpose of a request. It builds on the discipline of
` reference provided by the Uniform Resource Identifier (URI) [3], as
` a location (URL) [4] or name (URN) [20], for indicating the
` resource on which a method is to be applied. Messages are passed in
` a format similar to that used by Internet Mail [9] and the
` Multipurpose Internet Mail Extensions (MIME) [7].
`
`004
`
`

`

` HTTP is also used as a generic protocol for communication between
` user agents and proxies/gateways to other Internet protocols, such
` as SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10],
` allowing basic hypermedia access to resources available from
` diverse applications and simplifying the implementation of user
` agents.
`
`1.2 Requirements
`
` This specification uses the same words as RFC 1123 [8] for defining
` the significance of each particular requirement. These words are:
`
` must
`
` This word or the adjective "required" means that the item is an
` absolute requirement of the specification.
`
` should
`
` This word or the adjective "recommended" means that there may
` exist valid reasons in particular circumstances to ignore this
` item, but the full implications should be understood and the
` case carefully weighed before choosing a different course.
`
` may
`
` This word or the adjective "optional" means that this item is
` truly optional. One vendor may choose to include the item
` because a particular marketplace requires it or because it
` enhances the product, for example; another vendor may omit the
` same item.
`
` An implementation is not compliant if it fails to satisfy one or
` more of the must requirements for the protocols it implements. An
` implementation that satisfies all the must and all the should
` requirements for its protocols is said to be "unconditionally
` compliant"; one that satisfies all the must requirements but not
` all the should requirements for its protocols is said to be
` "conditionally compliant".
`
`1.3 Terminology
`
` This specification uses a number of terms to refer to the roles
` played by participants in, and objects of, the HTTP communication.
`
` connection
`
` A transport layer virtual circuit established between two
` application programs for the purpose of communication.
`
` message
`
` The basic unit of HTTP communication, consisting of a structured
` sequence of octets matching the syntax defined in Section 4 and
` transmitted via the connection.
`
` request
`
` An HTTP request message (as defined in Section 5).
`
`005
`
`

`

` response
`
` An HTTP response message (as defined in Section 6).
`
` resource
`
` A network data object or service which can be identified by a
` URI (Section 3.2).
`
` entity
`
` A particular representation or rendition of a data resource, or
` reply from a service resource, that may be enclosed within a
` request or response message. An entity consists of
` metainformation in the form of entity headers and content in the
` form of an entity body.
`
` client
`
` An application program that establishes connections for the
` purpose of sending requests.
`
` user agent
`
` The client which initiates a request. These are often browsers,
` editors, spiders (web-traversing robots), or other end user
` tools.
`
` server
`
` An application program that accepts connections in order to
` service requests by sending back responses.
`
` origin server
`
` The server on which a given resource resides or is to be created.
`
` proxy
`
` An intermediary program which acts as both a server and a client
` for the purpose of making requests on behalf of other clients.
` Requests are serviced internally or by passing them, with
` possible translation, on to other servers. A proxy must
` interpret and, if necessary, rewrite a request message before
` forwarding it. Proxies are often used as client-side portals
` through network firewalls and as helper applications for
` handling requests via protocols not implemented by the user
` agent.
`
` gateway
`
` A server which acts as an intermediary for some other server.
` Unlike a proxy, a gateway receives requests as if it were the
` origin server for the requested resource; the requesting client
` may not be aware that it is communicating with a gateway.
` Gateways are often used as server-side portals through network
` firewalls and as protocol translators for access to resources
` stored on non-HTTP systems.
`
` tunnel
`
`006
`
`

`

` A tunnel is an intermediary program which is acting as a blind
` relay between two connections. Once active, a tunnel is not
` considered a party to the HTTP communication, though the tunnel
` may have been initiated by an HTTP request. The tunnel ceases to
` exist when both ends of the relayed connections are closed.
` Tunnels are used when a portal is necessary and the intermediary
` cannot, or should not, interpret the relayed communication.
`
` cache
`
` A program’s local store of response messages and the subsystem
` that controls its message storage, retrieval, and deletion. A
` cache stores cachable responses in order to reduce the response
` time and network bandwidth consumption on future, equivalent
` requests. Any client or server may include a cache, though a
` cache cannot be used by a server while it is acting as a tunnel.
`
` Any given program may be capable of being both a client and a
` server; our use of these terms refers only to the role being
` performed by the program for a particular connection, rather than
` to the program’s capabilities in general. Likewise, any server may
` act as an origin server, proxy, gateway, or tunnel, switching
` behavior based on the nature of each request.
`
`1.4 Overall Operation
`
` The HTTP protocol is based on a request/response paradigm. A client
` establishes a connection with a server and sends a request to the
` server in the form of a request method, URI, and protocol version,
` followed by a MIME-like message containing request modifiers,
` client information, and possible body content. The server responds
` with a status line, including the message’s protocol version and a
` success or error code, followed by a MIME-like message containing
` server information, entity metainformation, and possible body
` content.
`
` Most HTTP communication is initiated by a user agent and consists
` of a request to be applied to a resource on some origin server. In
` the simplest case, this may be accomplished via a single connection
` (v) between the user agent (UA) and the origin server (O).
`
` request chain ------------------------>
` UA -------------------v------------------- O
` <----------------------- response chain
`
` A more complicated situation occurs when one or more intermediaries
` are present in the request/response chain. There are three common
` forms of intermediary: proxy, gateway, and tunnel. A proxy is a
` forwarding agent, receiving requests for a URI in its absolute
` form, rewriting all or parts of the message, and forwarding the
` reformatted request toward the server identified by the URI. A
` gateway is a receiving agent, acting as a layer above some other
` server(s) and, if necessary, translating the requests to the
` underlying server’s protocol. A tunnel acts as a relay point
` between two connections without changing the messages; tunnels are
` used when the communication needs to pass through an intermediary
` (such as a firewall) even when the intermediary cannot understand
` the contents of the messages.
`
` request chain -------------------------------------->
` UA -----v----- A -----v----- B -----v----- C -----v----- O
`
`007
`
`

`

` <------------------------------------- response chain
`
` The figure above shows three intermediaries (A, B, and C) between
` the user agent and origin server. A request or response message
` that travels the whole chain must pass through four separate
` connections. This distinction is important because some HTTP
` communication options may apply only to the connection with the
` nearest, non-tunnel neighbor, only to the end-points of the chain,
` or to all connections along the chain. Although the diagram is
` linear, each participant may be engaged in multiple, simultaneous
` communications. For example, B may be receiving requests from many
` clients other than A, and/or forwarding requests to servers other
` than C, at the same time that it is handling A’s request.
`
` Any party to the communication which is not acting as a tunnel may
` employ an internal cache for handling requests. The effect of a
` cache is that the request/response chain is shortened if one of the
` participants along the chain has a cached response applicable to
` that request. The following illustrates the resulting chain if B
` has a cached copy of an earlier response from O (via C) for a
` request which has not been cached by UA or A.
`
` request chain ---------->
` UA -----v----- A -----v----- B - - - - - - C - - - - - - O
` <--------- response chain
`
` Not all responses are cachable, and some requests may contain
` modifiers which place special requirements on cache behavior. HTTP
` requirements for cache behavior and cachable responses are defined
` in Section 13.
`
` On the Internet, HTTP communication generally takes place over
` TCP/IP connections. The default port is TCP 80 [19], but other
` ports can be used. This does not preclude HTTP from being
` implemented on top of any other protocol on the Internet, or on
` other networks. HTTP only presumes a reliable transport; any
` protocol that provides such guarantees can be used, and the mapping
` of the HTTP/1.1 request and response structures onto the transport
` data units of the protocol in question is outside the scope of this
` specification.
`
` For most implementations, each connection is established by the
` client prior to the request and closed by the server after sending
` the response. However, this is not a feature of the protocol and is
` not required by this specification. Both clients and servers must
` be capable of handling cases where either party closes the
` connection prematurely, due to user action, automated time-out, or
` program failure. In any case, the closing of the connection by
` either or both parties always terminates the current request,
` regardless of its status.
`
`2. Notational Conventions and Generic Grammar
`
`2.1 Augmented BNF
`
` All of the mechanisms specified in this document are described in
` both prose and an augmented Backus-Naur Form (BNF) similar to that
` used by RFC 822 [9]. Implementors will need to be familiar with the
` notation in order to understand this specification. The augmented
` BNF includes the following constructs:
`
`008
`
`

`

` name = definition
`
` The name of a rule is simply the name itself (without any
` enclosing "<" and ">") and is separated from its definition by
` the equal character "=". Whitespace is only significant in that
` indentation of continuation lines is used to indicate a rule
` definition that spans more than one line. Certain basic rules
` are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
` Angle brackets are used within definitions whenever their
` presence will facilitate discerning the use of rule names.
`
` "literal"
`
` Quotation marks surround literal text. Unless stated otherwise,
` the text is case-insensitive.
`
` rule1 | rule2
`
` Elements separated by a bar ("I") are alternatives, e.g.,
` "yes | no" will accept yes or no.
`
` (rule1 rule2)
`
` Elements enclosed in parentheses are treated as a single
` element. Thus, "(elem (foo | bar) elem)" allows the token
` sequences "elem foo elem" and "elem bar elem".
`
` *rule
`
` The character "*" preceding an element indicates repetition. The
` full form is "<n>*<m>element" indicating at least <n> and at
` most <m> occurrences of element. Default values are 0 and
` infinity so that "*(element)" allows any number, including zero;
` "1*element" requires at least one; and "1*2element" allows one
` or two.
`
` [rule]
`
` Square brackets enclose optional elements; "[foo bar]" is
` equivalent to "*1(foo bar)".
`
` N rule
`
` Specific repetition: "<n>(element)" is equivalent to
` "<n>*<n>(element)"; that is, exactly <n> occurrences of
` (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a
` string of three alphabetic characters.
`
` #rule
`
` A construct "#" is defined, similar to "*", for defining lists
` of elements. The full form is "<n>#<m>element" indicating at
` least <n> and at most <m> elements, each separated by one or
` more commas (",") and optional linear whitespace (LWS). This
` makes the usual form of lists very easy; a rule such as
` "( *LWS element *( *LWS "," *LWS element ))" can be shown as
` "1#element". Wherever this construct is used, null elements are
` allowed, but do not contribute to the count of elements present.
` That is, "(element), , (element)" is permitted, but counts as
` only two elements. Therefore, where at least one element is
` required, at least one non-null element must be present. Default
`
`009
`
`

`

` values are 0 and infinity so that "#(element)" allows any
` number, including zero; "1#element" requires at least one; and
` "1#2element" allows one or two.
`
` ; comment
`
` A semi-colon, set off some distance to the right of rule text,
` starts a comment that continues to the end of line. This is a
` simple way of including useful notes in parallel with the
` specifications.
`
` implied *LWS
`
` The grammar described by this specification is word-based.
` Except where noted otherwise, linear whitespace (LWS) can be
` included between any two adjacent words (token or
` quoted-string), and between adjacent tokens and delimiters
` (tspecials), without changing the interpretation of a field. At
` least one delimiter (tspecials) must exist between any two
` tokens, since they would otherwise be interpreted as a single
` token. However, applications should attempt to follow "common
` form" when generating HTTP constructs, since there exist some
` implementations that fail to accept anything beyond the common
` forms.
`
`2.2 Basic Rules
`
` The following rules are used throughout this specification to
` describe basic parsing constructs. The US-ASCII coded character set
` is defined by [21].
`
` OCTET = <any 8-bit sequence of data>
` CHAR = <any US-ASCII character (octets 0 - 127)>
` UPALPHA = <any US-ASCII uppercase letter "A".."Z">
` LOALPHA = <any US-ASCII lowercase letter "a".."z">
` ALPHA = UPALPHA | LOALPHA
` DIGIT = <any US-ASCII digit "0".."9">
` CTL = <any US-ASCII control character
` (octets 0 - 31) and DEL (127)>
` CR = <US-ASCII CR, carriage return (13)>
` LF = <US-ASCII LF, linefeed (10)>
` SP = <US-ASCII SP, space (32)>
` HT = <US-ASCII HT, horizontal-tab (9)>
` <"> = <US-ASCII double-quote mark (34)>
`
` HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker
` for all protocol elements except the Entity-Body (see Appendix B
` for tolerant applications). The end-of-line marker within an
` Entity-Body is defined by its associated media type, as described
` in Section 3.7.
`
` CRLF = CR LF
`
` HTTP/1.1 headers can be folded onto multiple lines if the
` continuation line begins with a space or horizontal tab. All linear
` whitespace, including folding, has the same semantics as SP.
`
` LWS = [CRLF] 1*( SP | HT )
`
` The TEXT rule is only used for descriptive field contents and
` values that are not intended to be interpreted by the message
`
`010
`
`

`

` parser. Words of *TEXT may contain octets from character sets other
` than US-ASCII only when encoded according to the rules of
`RFC 1522 [14].
`
` TEXT = <any OCTET except CTLs,
` but including LWS>
`
` Recipients of header field TEXT containing octets outside the
` US-ASCII character set range may assume that they represent
` ISO-8859-1 characters if there is no other encoding indicated by an
`RFC 1522 mechanism.
`
` Hexadecimal numeric characters are used in several protocol
` elements.
`
` HEX = "A" | "B" | "C" | "D" | "E" | "F"
` | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
`
` Many HTTP/1.1 header field values consist of words separated by LWS
` or special characters. These special characters must be in a quoted
` string to be used within a parameter value.
`
` word = token | quoted-string
`
` token = 1*<any CHAR except CTLs or tspecials>
`
` tspecials = "(" | ")" | "<" | ">" | "@"
` | "," | ";" | ":" | "\" | <">
` | "/" | "[" | "]" | "?" | "="
` | "{" | "}" | SP | HT
`
` Comments can be included in some HTTP header fields by surrounding
` the comment text with parentheses. Comments are only allowed in
` fields containing "comment" as part of their field value
` definition. In all other fields, parentheses are considered part of
` the field value.
`
` comment = "(" *( ctext | comment ) ")"
` ctext = <any TEXT excluding "(" and ")">
`
` A string of text is parsed as a single word if it is quoted using
` double-quote marks.
`
` quoted-string = ( <"> *(qdtext) <"> )
`
` qdtext = <any CHAR except <"> and CTLs,
` but including LWS>
`
` The backslash character ("\") may be used as a single-character
` quoting mechanism only within quoted-string and comment constructs.
`
` quoted-pair = "\" CHAR
`
` Braces are used to delimit an attribute-value bag, which may
` consist of a set, list, or recursively defined tokens and quoted
` strings. The bag semantics are defined by its context and the bag
` name, which may be a Uniform Resource Identifier (Section 3.2) in
` some fields.
`
` bag = "{" bagname 1*LWS *bagitem "}"
` bagname = token | URI
`
`011
`
`

`

` bagitem = bag | token | quoted-string
`
`3. Protocol Parameters
`
`3.1 HTTP Version
`
` HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
` of the protocol. The protocol versioning policy is intended to
` allow the sender to indicate the format of a message and its
` capacity for understanding further HTTP communication, rather than
` the features obtained via that communication. No change is made to
` the version number for the addition of message components which do
` not affect communication behavior or which only add to extensible
` field values. The <minor> number is incremented when the changes
` made to the protocol add features which do not change the general
` message parsing algorithm, but which may add to the message
` semantics and imply additional capabilities of the sender. The
` <major> number is incremented when the format of a message within
` the protocol is changed.
`
` The version of an HTTP message is indicated by an HTTP-Version
` field in the first line of the message. If the protocol version is
` not specified, the recipient must assume that the message is in the
` simple HTTP/0.9 format [6].
`
` HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
`
` Note that the major and minor numbers should be treated as separate
` integers and that each may be incremented higher than a single
` digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in
` turn is lower than HTTP/12.3. Leading zeros should be ignored by
` recipients and never generated by senders.
`
` Applications sending Full-Request or Full-Response messages, as
` defined by this specification, must include an HTTP-Version of
` "HTTP/1.1". Use of this version number indicates that the sending
` application is at least conditionally compliant with this
` specification.
`
` HTTP/1.1 servers must:
`
` o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
` 1.1 requests;
`
` o understand any valid request in the format of HTTP/0.9, 1.0, or
` 1.1;
`
` o respond appropriately with a message in the same major version
` used by the client.
`
` HTTP/1.1 clients must:
`
` o recognize the format of the Status-Line for HTTP/1.0 and 1.1
` responses;
`
` o understand any valid response in the format of HTTP/0.9, 1.0,
` or 1.1.
`
` Proxy and gateway applications must be careful in forwarding
` requests that are received in a format different than that of the
` application’s native HTTP version. Since the protocol version
`
`012
`
`

`

` indicates the protocol capability of the sender, a proxy/gateway
` must never send a message with a version indicator which is greater
` than its native version; if a higher version request is received,
` the proxy/gateway must either downgrade the request version,
` respond with an error, or switch to tunnel behavior. Requests with
` a version lower than that of the application’s native format may be
` upgraded before being forwarded; the proxy/gateway’s response to
` that request must follow the server requirements listed above.
`
`3.2 Uniform Resource Identifiers
`
` URIs have been known by many names: WWW addresses, Universal
` Document Identifiers, Universal Resource Identifiers [3], and
` finally the combination of Uniform Resource Locators (URL) [4] and
` Names (URN) [20]. As far as HTTP is concerned, Uniform Resource
` Identifiers are simply formatted strings which identify--via name,
` location, or any other characteristic--a network resource.
`
`3.2.1 General Syntax
`
` URIs in HTTP can be represented in absolute form or relative to
` some known base URI [11], depending upon the context of their use.
` The two forms are differentiated by the fact that absolute URIs
` always begin with a scheme name followed by a colon.
`
` URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
`
` absoluteURI = scheme ":" *( uchar | reserved )
`
` relativeURI = net_path | abs_path | rel_path
`
` net_path = "//" net_loc [ abs_path ]
` abs_path = "/" rel_path
` rel_path = [ path ] [ ";" params ] [ "?" query ]
`
` path = fsegment *( "/" segment )
` fsegment = 1*pchar
` segment = *pchar
`
` params = param *( ";" param )
` param = *( pchar | "/" )
`
` scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
` net_loc = *( pchar | ";" | "?" )
` query = *( uchar | reserved )
` fragment = *( uchar | reserved )
`
` pchar = uchar | ":" | "@" | "&" | "="
` uchar = unreserved | escape
` unreserved = ALPHA | DIGIT | safe | extra | national
`
` escape = "%" HEX HEX
` reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
` extra = "!" | "*" | "’" | "(" | ")" | ","
` safe = "$" | "-" | "_" | "." | "+"
` unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
` national = <any OCTET excluding ALPHA, DIGIT,
` reserved, extra, safe, and unsafe>
`
` For definitive information on URL syntax and semantics, see RFC
`1738 [4] and RFC 1808 [11]. The BNF above includes national
`
`013
`
`

`

` characters not allowed in valid URLs as specified by RFC 1738,
` since HTTP servers are not restricted in the set of unreserved
` characters allowed to represent the rel_path part of addresses, and
` HTTP proxies may receive requests for URIs not defined by RFC 1738.
`
`3.2.2 http URL
`
` The "http" scheme is used to locate network resources via the HTTP
` protocol. This section defines the scheme-specific syntax and
` semantics for http URLs.
`
` http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
`
` host = <A legal Internet host domain name
` or IP address (in dotted-decimal form),
` as defined by Section 2.1 of RFC 1123>
`
` port = *DIGIT
`
` If the port is empty or not given, port 80 is assumed. The
` semantics are that the identified resource is located at the server
` listening for TCP connections on that port of that host, and the
` Request-URI for the resource is abs_path. If the abs_path is not
` present in the URL, it must be given as "/" when used as a
` Request-URI for a resource (Section 5.1.2).
`
` Note: Although the HTTP protocol is independent of the
` transport layer protocol, the http URL only identifies
` resources by their TCP location, and thus non-TCP resources
` must be identified by some other URI scheme.
`
` The canonical form for "http" URLs is obtained by converting any
` UPALPHA characters in host to their LOALPHA equivalent (hostnames
` are case-insensitive), eliding the [ ":" port ] if the port is 80,
` and replacing an empty abs_path with "/".
`
`3.3 Date/Time Formats
`
`3.3.1 Full Date
`
` HTTP applications have historically allowed three diffe