www.archivc.org
`415.561.6767
`415.840-0391 c-fax
`
`Internet Archive
`300 Funston Avenue
`San Francisco, CA 94118
`
`AFFIDAVIT OF CHRISTOPHER BUTLER
`
`1. I am the Office Manager at the Internet Archive, located in San Francisco,
`California. I make this declaration of my own personal knowledge.
`2. The Internet Archive is a website that provides access to a digital library of
`Internet sites and other cultural artifacts in digital form. Like a paper library, we provide
`free access to researchers, historians, scholars, and the general public. The Internet
`Archive has partnered with and receives support from various institutions, including the
`Library of Congress.
`3. The Internet Archive has created a service known as the Way back Machine. The
`Wayback Machine makes it possible to surf more than 450 billion pages stored in the
`Internet Archive's web archive. Visitors to the Wayback Machine can search archives
`by URL (i.e., a website address). If archived records for a URL are available, the visitor
`will be presented with a list of available dates. The visitor may select one of those
`dates, and then begin surfing on an archived version of the Web. The links on the
`archived files, when served by the Wayback Machine, point to other archived files
`(whether HTML pages or images). If a visitor clicks on a link on an archived page, the
`Wayback Machine will serve the archived file with the closest available date to the page
`upon which the link appeared and was clicked.
`4. The archived data made viewable and browseable by the Wayback Machine is
`compiled using software programs known as crawlers, which surf the Web and
`automatically store copies of web files, preserving these files as they exist at the point of
`time of capture.
`5. The Internet Archive assigns a URL on its site to the archived files in the format
`http://web.archive.org/web/[Year
`in yyyy][Month in mm][Day in dd][Time code in
`hh:mm:ss]/[Archived URL]. Thus, the Internet Archive URL
`http://web.archive.org/web/19970126045828/http://www.archive.org/ would be the
`URL for the record of the Internet Archive home page HTML file
`(http://www.archive.org/) archived on January 26, 1997 at 4:58 a.m. and 28 seconds
`(1997/01/26 at 04:58:28). A web browser may be set such that a printout from it will
`display the URL of a web page in the printout's footer. The date assigned by the Internet
`Archive applies to the HTML file but not to image files linked therein. Thus images that
`appear on a page may not have been archived on the same date as the HTML file.
`Likewise, if a website is designed with "frames," the date assigned by the Internet
`Archive applies to the frameset as a whole, and not the individual pages within each
`frame.
`6. Attached hereto as Exhibit A are true and accurate copies of printouts of the
`Internet Archive's records of the HTML files or tx.t files for the URLs and the dates
`specified in the footer of the printout.
`7. I declare under penalty of perjury that the foregoing is true and correct.
`
`EX 1044 Page 1
`
`

`

`CALIFORNIA nJRA T
`
`See Attached Document.
`
`State of California
`County of San Francisco
`
`A notary public or other officer completing this
`certificate verifies only the identity of the
`individual who signed the document to which this
`certificate is attached, and not the truthfulness,
`accuracy, or validity of that document.
`
`Subscribed and sworn to ( or affirmed) before me on
`this
`
`1+- day of Nov(2rvlte/
`• a_orq , by
`
`1
`
`Christopher Butler,
`
`proved to me on the basis of satisfactory evidence to be
`the person who ap eared before
`I
`
`EX 1044 Page 2
`
`

`

`
`Exhibit A
`
`Exhibit A
`
`EX 1044 Page 3
`
`EX 1044 Page 3
`
`

`

`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`11/5/2019
`
`
`
`
`
`
`Network Working Group T. Berners-Lee
`Request for Comments: 1945 MIT/LCS
`Category: Informational 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
` 1.2 Terminology .......................................... 4
` 1.3 Overall Operation .................................... 6
` 1.4 HTTP and MIME ........................................ 8
` 2. Notational Conventions and Generic Grammar ................ 8
` 2.1 Augmented BNF ........................................ 8
` 2.2 Basic Rules .......................................... 10
` 3. Protocol Parameters ....................................... 12
`
`
`
`Berners-Lee, et al Informational [Page 1]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 3.1 HTTP Version ......................................... 12
` 3.2 Uniform Resource Identifiers ......................... 14
` 3.2.1 General Syntax ................................ 14
` 3.2.2 http URL ...................................... 15
` 3.3 Date/Time Formats .................................... 15
` 3.4 Character Sets ....................................... 17
` 3.5 Content Codings ...................................... 18
` 3.6 Media Types .......................................... 19
` 3.6.1 Canonicalization and Text Defaults ............ 19
` 3.6.2 Multipart Types ............................... 20
` 3.7 Product Tokens ....................................... 20
` 4. HTTP Message .............................................. 21
` 4.1 Message Types ........................................ 21
` 4.2 Message Headers ...................................... 22
` 4.3 General Header Fields ................................ 23
` 5. Request ................................................... 23
` 5.1 Request-Line ......................................... 23
` 5.1.1 Method ........................................ 24
` 5.1.2 Request-URI ................................... 24
` 5.2 Request Header Fields ................................ 25
` 6. Response .................................................. 25
` 6.1 Status-Line .......................................... 26
` 6.1.1 Status Code and Reason Phrase ................. 26
` 6.2 Response Header Fields ............................... 28
` 7. Entity .................................................... 28
` 7.1 Entity Header Fields ................................. 29
` 7.2 Entity Body .......................................... 29
` 7.2.1 Type .......................................... 29
` 7.2.2 Length ........................................ 30
` 8. Method Definitions ........................................ 30
` 8.1 GET .................................................. 31
` 8.2 HEAD ................................................. 31
` 8.3 POST ................................................. 31
` 9. Status Code Definitions ................................... 32
` 9.1 Informational 1xx .................................... 32
` 9.2 Successful 2xx ....................................... 32
` 9.3 Redirection 3xx ...................................... 34
` 9.4 Client Error 4xx ..................................... 35
` 9.5 Server Error 5xx ..................................... 37
` 10. Header Field Definitions .................................. 37
` 10.1 Allow ............................................... 38
` 10.2 Authorization ....................................... 38
` 10.3 Content-Encoding .................................... 39
` 10.4 Content-Length ...................................... 39
` 10.5 Content-Type ........................................ 40
` 10.6 Date ................................................ 40
` 10.7 Expires ............................................. 41
` 10.8 From ................................................ 42
`
`
`
`Berners-Lee, et al Informational [Page 2]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 10.9 If-Modified-Since ................................... 42
` 10.10 Last-Modified ....................................... 43
` 10.11 Location ............................................ 44
` 10.12 Pragma .............................................. 44
` 10.13 Referer ............................................. 44
` 10.14 Server .............................................. 45
` 10.15 User-Agent .......................................... 46
` 10.16 WWW-Authenticate .................................... 46
` 11. Access Authentication ..................................... 47
` 11.1 Basic Authentication Scheme ......................... 48
` 12. Security Considerations ................................... 49
` 12.1 Authentication of Clients ........................... 49
`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`1/26
`
`EX 1044 Page 4
`
`

`

`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`11/5/2019
` 12.2 Safe Methods ........................................ 49
` 12.3 Abuse of Server Log Information ..................... 50
` 12.4 Transfer of Sensitive Information ................... 50
` 12.5 Attacks Based On File and Path Names ................ 51
` 13. Acknowledgments ........................................... 51
` 14. References ................................................ 52
` 15. Authors' Addresses ........................................ 54
` Appendix A. Internet Media Type message/http ................ 55
` Appendix B. Tolerant Applications ........................... 55
` Appendix C. Relationship to MIME ............................ 56
` C.1 Conversion to Canonical Form ......................... 56
` C.2 Conversion of Date Formats ........................... 57
` C.3 Introduction of Content-Encoding ..................... 57
` C.4 No Content-Transfer-Encoding ......................... 57
` C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
` Appendix D. Additional Features ............................. 57
` D.1 Additional Request Methods ........................... 58
` D.1.1 PUT ........................................... 58
` D.1.2 DELETE ........................................ 58
` D.1.3 LINK .......................................... 58
` D.1.4 UNLINK ........................................ 58
` D.2 Additional Header Field Definitions .................. 58
` D.2.1 Accept ........................................ 58
` D.2.2 Accept-Charset ................................ 59
` D.2.3 Accept-Encoding ............................... 59
` D.2.4 Accept-Language ............................... 59
` D.2.5 Content-Language .............................. 59
` D.2.6 Link .......................................... 59
` D.2.7 MIME-Version .................................. 59
` D.2.8 Retry-After ................................... 60
` D.2.9 Title ......................................... 60
` D.2.10 URI ........................................... 60
`
`
`
`
`
`
`
`Berners-Lee, et al Informational [Page 3]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
`1. Introduction
`
`1.1 Purpose
`
` 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]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` request
`
` 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
`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`2/26
`
`EX 1044 Page 5
`
`

`

`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`11/5/2019
` 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 [Page 5]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 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 [Page 6]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 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
` <------------------------------------- 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
`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`3/26
`
`EX 1044 Page 6
`
`

`

`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`11/5/2019
`
`
`
`Berners-Lee, et al Informational [Page 7]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` cached copy of an earlier response from O (via C) for a request 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. 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 [Page 8]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 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.
`
`
`
`
`Berners-Lee, et al Informational [Page 9]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` #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.
`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`
`4/26
`
`EX 1044 Page 7
`
`

`

`https://web.archive.org/web/19980530060627if_/http://www.nic.it:80/mirrors/rfc/rfc1945.txt
`11/5/2019
` 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; "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 [17].
`
` 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">
`
`
`
`Berners-Lee, et al Informational [Page 10]
`
`RFC 1945 HTTP/1.0 May 1996
`
`
` 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.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 | 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-
` ASCII character set may assume that they represent ISO-8859-1
` characters.
`
` Hexadecimal numeric characters are used in several protocol elements.
`
` HEX = "A" | "B" | "C" | "D" | "E" | "F"
` | "a" | "b" | "c" | "d" | "e" | "f" | 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 | quoted-str