`
`www.i etf.org /rfc/rfc1945.txt
`
`Network Working Group
`Request for Comments: 1945
`Category: Informational
`
`T. Berners-Lee
`MIT /LCS
`R. Fielding
`UC Irvine
`H. Frystyk
`MIT /LCS
`May 1996
`
`Hypertext Transfer Protocol -- HTTP/1.0
`
`Status of This Memo
`
`This memo provides information for the Internet community. This memo
`does not specify an Internet standard of any kind. Distribution of
`this memo is unlimited.
`
`IESG Note:
`
`The IESG has concerns about this protocol, and expects this document
`to be replaced relatively soon by a standards track document.
`
`Abstract
`
`The Hypertext Transfer Protocol (HTTP) is an application-level
`protocol with the lightness and speed necessary for distributed,
`collaborative, hypermedia information systems. It is a generic,
`stateless, object-oriented protocol which can be used for many tasks,
`such as name servers and distributed object management systems,
`through extension of its request methods (commands). A feature of
`HTTP is the typing 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 reflects common usage of
`the protocol referred to as "HTTP/1.0".
`
`Table of Contents
`
`1.
`
`Introduction
`4
`1.1 Purpose
`4
`4
`1. 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`6
`1. 3 Overall Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`8
`1. 4 HTTP and MIME ...... , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`8
`2. Notational Conventions and Generic Grammar
`. . . . . . . . . . . . . . . .
`8
`2. 1 Augmented BNF
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`2.2 Basic Rules .......................................... 10
`3. Protocol Parameters ....................................... 12
`
`www.ietf.org/rfc/rfc1945.txt
`
`1/60
`
`
`
`Petitioner Apple Inc. - Exhibit 1021, p. 1
`
`
`
`1/4/14
`
`WMN.i etf.org /rfc!rfc1945.txt
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 1]
`
`May 1996
`
`3.1 HTTP Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`3.2 Uniform Resource Identifiers ......................... 14
`3.2.1 General Syntax ................................ 14
`3.2.2 http URL ...................................... 15
`3. 3 Date/Time Formats .................................... 15
`3. 4 Character Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
`3. 5 Content Codings ...................................... 18
`3. 6 Media Types .......................................... 19
`3.6.1 Canonicalization and Text Defaults ............ 19
`3.6.2 Multipart Types ............................... 20
`3.7 Product Tokens ....................................... 20
`4. HTTP Message .............................................. 21
`4.1 Message Types ........................................ 21
`4.2 Message Headers ...................................... 22
`4.3 General Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3
`5. Request ................................................... 23
`5.1 Request-Line ......................................... 23
`5. 1. 1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4
`5.1.2 Request-URI ................................... 24
`5. 2 Request Header Fields ................................ 25
`6. Response .................................................. 25
`6.1 Status-Line .......................................... 26
`6.1.1 Status Code and Reason Phrase ................. 26
`6.2 Response Header Fields ............................... 28
`7. Entity .................................................... 28
`7. 1 Entity Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 9
`7.2 EntityBody .......................................... 29
`7 . 2 . 1 Type
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 9
`7. 2. 2 Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
`8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 0
`8.1 GET .................................................. 31
`8. 2 HEAD ................................................. 31
`8.3 POST ................................................. 31
`9. Status Code Definitions ................................... 32
`9.1
`Informational 1xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
`9.2 Successful 2xx ....................................... 32
`9. 3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
`9. 4 Client Error 4xx ..................................... 35
`9. 5 Server Error 5xx ..................................... 37
`10. Header Field Definitions .................................. 37
`10.1 Allow ............................................... 38
`10.2 Authorization ....................................... 38
`10.3 Content-Encoding .................................... 39
`10.4 Content-Length ...................................... 39
`10.5 Content-Type ........................................ 40
`10.6 Date ................................................ 40
`10.7 Expires ............................................. 41
`10.8 From ................................................ 42
`
`WMN.ietf.org/rfc!rfc1945.bd:
`
`2/60
`
`2
`
`Petitioner Apple Inc. - Exhibit 1021, p. 2
`
`
`
`1/4/14
`Berners-Lee, et al
`
`\\MM/.ietf.org /rfc/rfc1945. txt
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 2]
`
`May 1996
`
`If-Modified-Since ................................... 42
`10. 9
`10.10 Last-Modified ....................................... 43
`10.11 Location ............................................ 44
`10.12 Pragma .............................................. 44
`10.13 Referer ............................................. 44
`10.14 Server .............................................. 45
`10.15 User-Agent .......................................... 46
`10.16 WWW-Authenticate .................................... 46
`11. Access Authentication ..................................... 47
`11.1 Basic Authentication Scheme ......................... 48
`12. Security Considerations ................................... 49
`12.1 Authentication of Clients ........................... 49
`12.2 Safe Methods ........................................ 49
`12.3 Abuse of Server Log Information . . . . . . . . . . . . . . . . . . . . . 50
`12.4 Transfer of Sensitive Information ................... 50
`12.5 Attacks Based On File and Path Names ................ 51
`13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
`14. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
`15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
`Appendix A.
`Internet Media Type message/http ................ 55
`Appendix B.
`Tolerant Applications ........................... 55
`Appendix C.
`Relationship to MIME ............................ 56
`C.l Conversion to Canonical Form ......................... 56
`C. 2 Conversion of Date Formats .. . . . . . . . . . . . .. . . . . . . . . . . . . 57
`C.3
`Introduction of Content-Encoding ..................... 57
`C. 4 No Content-Transfer-Encoding ......................... 57
`C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
`Appendix D.
`Additional Features ............................. 57
`D.l Additional Request Methods ........................... 58
`D . 1 . 1
`PUT
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
`D.l.2 DELETE ........................................ 58
`0.1.3 LINK .......................................... 58
`D. 1. 4 UNLINK
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
`D.2 Additional Header Field Definitions .................. 58
`D.2.1 Accept ........................................ 58
`D.2.2 Accept-Charset ................................ 59
`D.2.3
`Accept-Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
`D.2.4
`Accept-Language ............................... 59
`0.2.5
`Content-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
`D.2.6
`Link .......................................... 59
`D.2.7
`MIME-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
`D.2.8
`Retry-After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
`D.2.9
`Title ......................................... 60
`D.2.10
`URI ........................................... 60
`
`Berners-Lee, et al
`
`Informational
`
`[Page 3]
`
`\\MM/.ietf.org /rfc/rfc1945.txt
`
`3/60
`
`3
`
`Petitioner Apple Inc. - Exhibit 1021, p. 3
`
`
`
`114114
`
`RFC 1945
`
`1.
`
`Introduction
`
`1.1 Purpose
`
`\WIM'.ietf.org lrfclrfc1945. txt
`
`HTTP/1.0
`
`May 1996
`
`The Hypertext Transfer Protocol (HTTP) is an application-level
`protocol with the lightness and speed necessary for distributed,
`collaborative, hypermedia information systems. HTTP has been in use
`by the World-Wide Web global information initiative since 1990. This
`specification reflects common usage of the protocol referred too as
`"HTTP/1.0". This specification describes the features that seem to be
`consistently implemented in most HTTP/1.0 clients and servers. The
`specification is split into two sections. Those features of HTTP for
`which implementations are usually consistent are described in the
`main body of this document. Those features which have few or
`inconsistent implementations are listed in Appendix D.
`
`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) [2], as a location
`(URL)
`[4] or name
`(URN)
`[16], 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 [7] and the Multipurpose Internet Mail
`Extensions (MIME)
`[5].
`
`HTTP is also used as a generic protocol for communication between
`user agents and proxies/gateways to other Internet protocols, such as
`SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing
`basic hypermedia access to resources available from diverse
`applications and simplifying the implementation of user agents.
`
`1.2 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.
`
`Berners-Lee, et al
`
`Informational
`
`[Page 4]
`
`\WIM'.ietf.org/rfc/rfc1945.txt
`
`4/60
`
`4
`
`Petitioner Apple Inc. - Exhibit 1021, p. 4
`
`
`
`1/4/14
`RFC 1945
`
`request
`
`V>MMJ.i etf.org /rfc/rfc1945. txt
`HTTP/1.0
`
`May 1996
`
`An HTTP request message (as defined in Section 5).
`
`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
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`V>MMJ.ietf.org /rfc/rfc 1945.txt
`
`HTTP/1.0
`
`5
`
`[Page 5]
`
`May 1996
`
`5/60
`
`Petitioner Apple Inc. - Exhibit 1021, p. 5
`
`
`
`1/4/14
`
`WNN.ietf.org/rfclrfc1945.txt
`
`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
`
`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.3 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
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 6]
`
`May 1996
`
`WNW.i etf.org /rfclrfc 1945.txt
`
`6/60
`
`6
`
`Petitioner Apple Inc. - Exhibit 1021, p. 6
`
`
`
`1/4/14
`
`\\MW.ietf.org /rfclrfc1945. txt
`
`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------------------- 0
`<----------------------- 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----- 0
`<------------------------------------- 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
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 7]
`
`May 1996
`
`\\MW.ietf.org/rfc/rfc1945.txt
`
`7/60
`
`7
`
`Petitioner Apple Inc. - Exhibit 1021, p. 7
`
`
`
`1/4/14
`
`\WIIW.ietf.org/rfc/rfc1945.txt
`cached copy of an earlier response from 0 (via C) for a request which
`has not been cached by UA or A.
`
`request chain ---------->
`UA -----v----- A -----v----- B -
`<--------- response chain
`
`-
`
`-
`
`-
`
`-
`
`- C -
`
`-
`
`-
`
`-
`
`-
`
`- 0
`
`Not all responses are cachable, and some requests may contain
`modifiers which place special requirements on cache behavior. Some
`HTTP/1.0 applications use heuristics to describe what is or is not a
`"cachable" response, but these rules are not standardized.
`
`On theĀ· Internet, HTTP communication generally takes place over TCP/IP
`connections. The default port is TCP 80 [15], 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.0 request and
`response structures onto the transport data units of the protocol in
`question is outside the scope of this specification.
`
`Except for experimental applications, current practice requires that
`the connection be established by the client prior to each request and
`closed by the server after sending the response. Both clients and
`servers should be aware that either party may close the connection
`prematurely, due to user action, automated time-out, or program
`failure, and should handle such closing in a predictable fashion. In
`any case, the closing of the connection by either or both parties
`always terminates the current request, regardless of its status.
`
`1.4 HTTP and MIME
`
`HTTP/1.0 uses many of the constructs defined for MIME, as defined in
`RFC 1521 [5] . Appendix C describes the ways in which the context of
`HTTP allows for different use of Internet Media Types than is
`typically found in Internet mail, and gives the rationale for those
`differences.
`
`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 [7]. Implementors will need to be familiar with the
`notation in order to understand this specification. The augmented BNF
`includes the following constructs:
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 8]
`
`May 1996
`
`name
`
`definition
`
`\WIIW.ietf.org /rfc/rfc 1945.txt
`
`8
`
`8/60
`
`Petitioner Apple Inc. - Exhibit 1021, p. 8
`
`
`
`1/4/14
`
`V>MMJ.i etf.org /rfc!rfc1945. txt
`
`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.
`
`rulel
`
`rule2
`
`Elements separated by a bar ("I") are alternatives,
`e.g., "yes I no" will accept yes or no.
`
`(rulel rule2)
`
`Elements enclosed in parentheses are treated as a single
`I bar) elem)" allows the token
`element. Thus, "(elem (foo
`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;
`"l*element" requires at least one; and "1*2element" allows one
`or two.
`
`[rule]
`
`Square brackets enclose optional elements; "[foo bar]" is
`equivalent to "*l(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.
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`#rule
`
`V>MMJ.i etf.org /rfc/rfc1945.txt
`
`HTTP/1.0
`
`9
`
`[Page 9]
`
`May 1996
`
`9/60
`
`Petitioner Apple Inc. - Exhibit 1021, p. 9
`
`
`
`1/4/14
`
`WNN.i etf.org /rfclrfc1945.txt
`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
`"l#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
`values are 0 and infinity so that "#(element)" allows any
`number, including zero; "l#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 [17].
`
`OCTET
`CHAR
`UP ALPHA
`LOALPHA
`
`<any 8-bit sequence of data>
`0 - 127)>
`<any US-ASCII character (octets
`"A" ... "Z">
`<any US-ASCII uppercase letter
`"a" .. "z 11 >
`<any US-ASCII lowercase letter
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 10]
`
`May 1996
`
`ALPHA
`DIGIT
`CTL
`
`I LOALPHA
`UPALPHA
`<any US-ASCII digit "0" .. "9">
`<any US-ASCII control character
`
`WNN.ietf.org/rfclrfc1945.txt
`
`10/60
`
`10
`
`Petitioner Apple Inc. - Exhibit 1021, p. 10
`
`
`
`1/4/14
`
`CR
`LF
`SP
`HT
`<">
`
`WMN.i etf.org /rfc/rfc1945.txt
`(octets 0 - 31) and DEL (127)>
`<US-ASCII CR, carriage return (13)>
`<US-ASCII LF, linefeed (10)>
`<US-ASCII SP, space (32)>
`<US-ASCII HT, horizontal-tab (9)>
`<US-ASCII double-quote mark (34)>
`
`HTTP/1.0 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.6.
`
`CRLF
`
`CR LF
`
`HTTP/1.0 headers may be folded onto multiple lines if each
`continuation line begins with a space or horizontal tab. All linear
`whitespace, including folding, has the same semantics as SP.
`
`LWS
`
`=
`
`[CRLF] 1*( SP
`
`I HT
`
`However, folding of header lines is not expected by some
`applications, and should not be generated by HTTP/1.0 applications.
`
`The TEXT rule is only used for descriptive field contents and values
`that are not intended to be interpreted by the message parser. Words
`of *TEXT may contain octets from character sets other than US-ASCII.
`
`TEXT
`
`<any OCTET except CTLs,
`but including LWS>
`
`Recipients of header field TEXT containing octets outside the US(cid:173)
`ASCII character set may assume that they represent IS0-8859-1
`characters.
`
`Hexadecimal numeric characters are used in several protocol elements.
`
`HEX
`
`"A"
`"a"
`
`"B"
`"b"
`
`"C"
`"c"
`
`"D"
`"d"
`
`"E"
`"e"
`
`"F"
`"f" I DIGIT
`
`Many HTTP/1.0 header field values consist of words separated by LWS
`or special characters. These special characters must be in a quoted
`string to be used within a parameter value.
`
`word
`
`=
`
`token I quoted-string
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 11]
`
`May 1996
`
`token
`
`1*<any CHAR except CTLs or tspecials>
`
`tspecials
`
`"("
`" " ,
`
`")"
`"." ,
`
`"<"
`"."
`
`">"
`"\"
`
`"@"
`<">
`
`W~MV.ietf.org /rfc!rfc 1945.txt
`
`11/60
`
`11
`
`Petitioner Apple Inc. - Exhibit 1021, p. 11
`
`
`
`1/4114
`
`n;n
`" { "
`
`"
`
`[ 1l
`
`"}"
`
`\\MMI.ietf.org /rfc/rfc1945. b<t
`n?"
`n] n
`"="
`I HT
`SP
`
`Comments may 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
`
`"(" *( ctext I comment) ")"
`<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>
`
`Single-character quoting using the backslash ("\") character is not
`permitted in HTTP/1.0.
`
`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
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 12]
`
`May 1996
`
`simple HTTP/0.9 format.
`
`HTTP-Version
`
`= "HTTP" "/" l*DIGIT "." 1*DIGIT
`
`Note that the major and minor numbers should be treated as separate
`
`\\MMI.ietf.org /rfc/rfc1945. b<t
`
`12/60
`
`12
`
`Petitioner Apple Inc. - Exhibit 1021, p. 12
`
`
`
`1/4114
`
`vmN.i etf.org /rfc/rfc1945. txt
`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.
`
`This document defines both the 0.9 and 1.0 versions of the HTTP
`protocol. Applications sending Full-Request or Full-Response
`messages, as defined by this specification, must include an HTTP(cid:173)
`Version of "HTTP/1.0".
`
`HTTP/1.0 servers must:
`
`o recognize the format of the Request-Line for HTTP/0.9 and
`HTTP/1.0 requests;
`
`o understand any valid request in the format of HTTP/0.9 or
`HTTP/1.0;
`
`o respond appropriately with a message in the same protocol
`version used by the client.
`
`HTTP/1.0 clients must:
`
`o recognize the format of the Status-Line for HTTP/1.0 responses;
`
`o understand any valid response in the format of HTTP/0.9 or
`HTTP/1.0.
`
`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
`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 or respond
`with an error. 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.
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 13]
`
`May 1996
`
`3.2 Uniform Resource Identifiers
`
`URis have been known by many names: WWW addresses, Universal Document
`Identifiers, Universal Resource Identifiers [2], and finally the
`combination of Uniform Resource Locators (URL)
`[4] and Names
`(URN)
`[16]. As far as HTTP is concerned, Uniform Resource Identifiers are
`
`WMV.ietf.org /rfc/rfc1945.txt
`
`13/60
`
`13
`
`Petitioner Apple Inc. - Exhibit 1021, p. 13
`
`
`
`1/4/14
`
`\\M\11/.ietf.org /rfc/rfc1945. txt
`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 [9], 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
`
`I relativeURI
`
`[ "#" fragment ]
`
`absoluteURI
`
`scheme":"*( uchar
`
`reserved
`
`relativeURI
`
`net_path
`
`abs_path
`
`rel_path
`
`net_path
`abs_path
`rel_path
`
`path
`fsegment
`segment
`
`params
`par am
`
`scheme
`net loc
`query
`fragment
`
`pchar
`uchar
`unreserved
`
`escape
`reserved
`extra
`safe
`unsafe
`national
`
`"//" net loc
`"/" rel_path
`[path] [ ";" params ]
`
`abs_path
`
`fsegment *( "/"segment
`1*pchar
`*pchar
`
`param *(
`*( pchar
`
`";" param
`"/" )
`
`1 * ( ALPHA
`* ( pchar
`* ( uchar
`* ( uchar
`
`I
`
`"+"
`I DIGIT
`I
`I "." I "?"
`)
`I reserved
`I reserved
`
`uchar I ":" I "@"
`unreserved I escape
`I DIGIT
`I safe
`ALPHA
`
`"&"
`
`"?" query ]
`
`n_n
`
`" "
`
`"="
`
`"+"
`
`extra I national
`
`I
`
`"%" HEX HEX
`"." I "/" I "?"
`I "'"
`"'" I "*"
`I "-" I " "
`"$"
`" "
`"<"
`I SP
`I <"> I "#"
`CTL
`"%"
`<any OCTET excluding ALPHA, DIGIT,
`
`n. n
`
`"
`
`( 11
`
`"@"
`")"
`
`"&"
`" "
`
`I
`
`"="
`
`"+"
`
`">"
`
`Berners-Lee, et al
`
`Informational
`
`RFC 1945
`
`HTTP/1.0
`
`[Page 14]
`
`May 1996
`
`reserved, extra, safe, and unsafe>
`
`For definitive information on URL syntax and semantics, see RFC 1738
`[4] and RFC 1808 [9]. The BNF above includes national characters not
`allowed in valid