REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`read chunk-data and CRLF
`append chunk-data to entity—body
`length := length + chunk-size
`read chunk-size and CRLF
`
`} r
`
`ead entity—header
`{
`while (entity-header not empty)
`append entity-header to existing header fields
`read entity-headez
`
`
`
`} C
`
`ontent-Length := length
`Remove "chunked" from Transfer—-Encoding
`
`19.4.7 MHTMLandLine Length Limitations
`
`HTTP implementations which share code with MHTML[45] implementations need to be aware of MIMEline length
`limitations. Since HTTP does not havethis limitation, HTTP does not fold long lines. MHTML messages being
`transported by HTTP follow all conventions of MHTML,including line length limitations and folding,
`canonicalization, etc., since HTTP transports all message-bodies as payload (see section 3.7.2) and does not interpret
`the content or any MIMEheaderlines that might be contained therein.
`
`19.5 Additional Features
`
`REC 1945 and RFC 2068 document protocol elements used by some existing HTTP implementations, but not
`consistently and correctly across most HTTP/1.1 applications. Implementors are advised to be aware of these
`features, but cannot rely upon their presencein, or interoperability with, other HTTP/1.1 applications. Someof these
`describe proposed experimental features, and some describe features that experimental deployment found lacking
`that are nowaddressed in the base HTTP/1.1 specification.
`
`A numberof other headers, such as Content-Disposition and Title, from SMTP and MIMEarealso often
`implemented (see RFC 2076 [37]).
`
`19.5.1 Content-Disposition
`
`The Content —Disposition response-header field has been proposed as a meansfor the origin server to suggest
`a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of
`Content—Disposition in RIC 1806 [35].
`
`content—disposition = "Content-—Disposition" ":"
`disposition-type *( ";" disposition-parm )
`disposition-type = “attachment™ | disp-extension-token
`disposition-parm = filename-pazm | disp-extension-pazm
`
`=ilename-parm = "filename" "=" quoted-string
`
`disp-extension-token = token
`
`disp-extension-parm = token "="
`
`(
`
`token
`
`quoted-string )
`
`An exampleis Content—Disposition: attachment,
`
`filename="fname.ext"
`The receiving user agent SHOULD NOTrespect any directory path information present in the =i lename-parm
`parameter, which is the only parameter believed to apply to HTTP implementationsat this time. The filename
`SHOULDbetreated as a terminal componentonly.
`
`If this header is used in a response with the application/octet-—stream content-type, the implied suggestion
`is that the user agent should not display the response, but directly enter a ‘save responseas...’ dialog.
`
`See section 15.5 for Content. Disposition security issues.
`
`Fielding, et al
`
`Standards Track
`
`[Page 104]
`
`Ex. 1002 - Page 413
`Ex. 1002 - Page 413
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`19.6 Compatibility with Previous Versions
`
`It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was
`deliberately designed, however, to make supporting previous versions easy.It is worth noting that, at the time of
`composing this specification (1996), we would expect commercial HTTP/1.1 servers to:
`
`®
`
`®
`
`recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 requests;
`
`understand anyvalid request in the format of HTTP/0.9, 1.0, or 1.1;
`
`respond appropriately with a message in the same major version used bytheclient.
`®
`And we would expect HTTP/1.1 clients to:
`
`®
`
`recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
`
`understand anyvalid response in the format of HTTP/0.9, 1.0, or 1.1.
`®
`For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed
`bythe server after sending the response. Some implementations implement the Keep—A1 ive version ofpersistent
`connections described in section 19.7.1 of RFC 2068 [33].
`
`19.6.1 Changes from HTTP/1.0
`
`This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.
`
`19.6.1.1| Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
`
`The requirements that clients and servers support the Host request-header, report an error if the Host request-
`header(section 14.23) is missing from an HTTP/1.1 request, and accept absolute URIs (section 5.1.2) are among the
`most important changes defined by this specification.
`
`Older H'T'TP/1.0 clients assumed a one-to-one relationship of 1P addresses and servers; there was no other
`established mechanism for distinguishing the intended server of a request than the IP address to which that request
`was directed. The changes outlined above will allow the Internet, once older HTTP clients are no longer common,to
`support multiple Web sites from a single IP address, greatly simplifying large operational Web servers, where
`allocation of many IP addresses to a single host has created serious problems. The Internet will also be able to
`recover the IP addresses that have been allocated for the sole purpose of allowing special-purpose domain names to
`be used in root-level HTTP URLs. Given the rate of growth of the Web, and the numberofservers already deployed,
`it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications)
`correctly implement these requirements:
`
`®
`
`Both clients and servers MUST support the Host request-header.
`
`® Aclient that sends an HTTP/1.1 request MUST send a Host header.
`
`©
`
`©
`
`Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host. request-
`header.
`
`Servers MUSTaccept absolute URIs.
`
`19.6.2. Compatibility with HTTP/1.0 Persistent Connections
`
`Someclients and servers might wish to be compatible with some previous implementations of persistent connections
`in HTTP/1.0 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the
`default behavior. HTTP/1.0 experimental implementations of persistent connections are faulty, and the newfacilities
`in HTTP/1.1 are designed to rectify these problems. The problem was that someexisting 1.0 clients maybe sending
`Keep-Alive to a proxy server that doesn’t understand Connection, which would then erroneously forward it to
`
`Fielding, et al
`
`Standards Track
`
`[Page 105]
`
`Ex. 1002 - Page 414
`Ex. 1002 - Page 414
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy
`waiting for the close on the response. Theresult is that HTTP/1.0 clients must be prevented from using Keep—
`Alive whentalking to proxies.
`
`However, talking to proxies is the most important use of persistent connections, so that prohibitionis clearly
`unacceptable. Therefore, we need some other mechanism for indicating a persistent connection is desired, which is
`safe to use even whentalking to an old proxy that ignores Connection. Persistent connections are the default for
`HTTP/1.1 messages; we introduce a new keyword (Connecticn: close)for declaring non-persistence. See
`section 14.10.
`
`
`The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Aliv
`header) is documented in RFC 2068. [33]
`
`19.6.3 Changes from RFC 2068
`
`This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many
`problems in respect to the conventionslaid out in RFC 2119 [34].
`
`Clarified which error code should be used for inboundserverfailures (e.g. DNS failures). (Section 10.5.5)
`
`CREATEhada race that required an Et.ag be sent when a resourceis first created. (Section 10.2.2
`
`ConLlenl—Base wasdeleted fromthe specification: it was not implemented widely, and there is no simple, safe
`wayto introduceit without a robust extension mechanism.In addition, it is used in a similar, but not identical fashion
`in MHTML[45].
`
`Transfer-coding and message lengthsall interact in ways that required fixing exactly when chunked encoding is used
`(to allowfor transfer encoding that may notbe self delimiting); it was important to straighten out exactly how
`message lengths are computed. (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
`
`A content-coding of “identity” was introduced, to solve problems discovered in caching. (Section 3.5)
`
`Quality Values of zero should indicate that “I don’t want something”to allow clients to refuse a representation.
`(Section 3.9)
`
`The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade
`requests to highest protocol version they support to deal with problems discovered in HIT'P/1.0 implementations
`(Section 3.1).
`
`Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (Section 14.2)
`
`A case was missed in the Cache-—Contzol model of HTTP/1.1; s-maxage wasintroducedto add this missing
`case. (Sections 13.4, 14.8, 14.9, 14.9.3)
`
`The Cache-Control: max—age directive was not properly defined for responses. (Section 14.9.3)
`
`There are situations where a server (especially a proxy) does not knowthefull length ofa response but is capable of
`serving a byterange request. We therefore need a mechanism to allow byteranges with a content-range not indicating
`the full length of the message. (Section 14.16)
`
`Range request responses would become very verbose if all meta-data were always returned; by allowing the server to
`only send needed headers in a 206 response, this problem can be avoided. (Section 10.2.7, 13.5.3, and 14.27)
`
`Tix problem with unsatisfiable range requests; there are two cases: syntactic problems, and range doesn’t exist in the
`document. The 416 status code was needed to resolve this ambiguity needed to indicate an error for a byte range
`request that falls outside of the actual contents of a document. (Section 10.4.17, 14.16)
`
`Rewrite of message transmission requirements to make it much harder for implementors to get it wrong, as the
`consequencesoferrors here can have significant impact on the Internet, and to deal with the following problems:
`
`1. Changing “HTTP/1.1 or later” to “HTTP/1.1”, in contexts where this was incorrectly placing a requirement
`on the behavior of an implementation of a future version of HTTP/1.x
`
`Fielding, et al
`
`Standards Track
`
`[Page 106]
`
`Ex. 1002 - Page 415
`Ex. 1002 - Page 415
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`2. Madeit clear that user-agents should retry requests, not “clients” in general.
`
`3. Converted requirements for clients to ignore unexpected 100 (Continue) responses, and for proxies to
`forward 100 responses, into a general requirement for 1xx responses.
`
`4. Modified some TCP-specitic language, to makeit clearer that non-TCP transports are possible for HTTP.
`
`5. Require that the origin server MUST NOTwait for the request body before it sends a required 100
`(Continue) response.
`
`6. Allow,rather than require, a server to omit 100 (Continue)if it has already seen someof the request body.
`
`7. Allow servers to defend against denial-of-service attacks and brokenclients.
`
`This change adds the Expect header and 417 status code. The message transmission requirements fixes are in
`sections 8.2, 10.4.18, 8.1.2.2, 13.11, and 14.20.
`
`Proxies should be able to add Content—Length when appropriate. (Section 13.5.2)
`
`Clean up confusion between 403 and 404 responses. (Section 10.4.4, 10.4.5, and 10.4.11)
`
`Warnings could be cachedincorrectly, or not updated appropriately. (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3,
`and 14.46). Warning also neededto be a general header, as PUT or other methods may have need forit in requests.
`
`‘Transfer-coding had significant problems, particularly with interactions with chunked encoding. ‘The solutionis that
`transfer-codings becomeas full fledged as content-codings. This involves adding an IANAregistryfor transfer-
`
`codings (separate from content codings), a new headerfield (TE) and enabling trailer headers in the future. Transfer
`
`encoding is a major performance benefit, so it was worth fixing [39]. TE also solves another, obscure, downward
`interoperability problemthat could have occurred due to interactions betweenauthenticationtrailers, chunked
`encoding and HTTP/1.0 clients.(Section 3.6, 3.6.1, and 14.39)
`
`The PATCH, LINK, UNLINK methods were defined but not commonly implemented in previous versions of this
`specification. See RFC 2068 [33].
`
`The Alternates, Content—Version, Derived-From, Link, URI, Public and Content-—Base header
`fields were defined in previous versionsofthis specification, but not commonly implemented. See RFC 2068 [33].
`
`Fielding, et al
`
`Standards Track
`
`[Page 107]
`
`Ex. 1002 - Page 416
`Ex. 1002 - Page 416
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`20 Full Copyright Statement
`Copyright (C) The Internet Society (1999). All Rights Reserved.
`
`This document andtranslations of it may be copied and furnished to others, and derivative works that comment on or
`otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in
`part, without restriction of any kind, provided that the above copyright notice and this paragraph are included onall
`such copies and derivative works. However, this documentitself may not be modified in any way, such as by
`removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed
`for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet
`Standards process must be followed, or as required to translate it into languages other than English.
`
`The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors
`or assigns.
`
`This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET
`SOCIETY AND 'THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS
`OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
`INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
`MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
`
`20.1 Acknowledgement
`
`Funding for the RFC Editor function is currently provided by the Internet Society.
`
`Fielding, et al
`
`Standards Track
`
`[Page 108]
`
`Ex. 1002 - Page 417
`Ex. 1002 - Page 417
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`21 Index
`
`While some care was taken producing this index, there is no guarantee thatall occurrences of an index term have
`been entered into the index. Bold faceitalic is used for the definition of a term.
`
`"literal", 11
`#rule, 12
`(rulel rule2), £7
`*rule, 11
`; comment, 12
`[rule], 27
`<">, 12
`100, 27, 32, 33, 37, 62, 77, 78
`101, 27, 38, 77, 88
`1xx Informational Status Codes, 37
`200, 27, 34, 36, 37, 38, 39, 41, 57, 61, 71, 76, 77, 81,
`82, 86
`201, 27, 36, 38, 83
`202, 27, 37, 38
`203, 27, 39, 57
`204, 22, 23, 27, 36, 37, 39
`205, 27, 39
`206, 27, 39, 40, 57, 59, 61, 76, 82, 85, 86, 101, 106
`2xx, 82
`2xx Successful Status Codes, 38
`300, 27, 40, 47, 57
`301, 27, 36, 40, 57, 89
`302, 27, 40, 41, 42, 57, 89
`303, 27, 36, 41, 89
`304, 22, 23, 27, 41, 48, 54, 56, 59, 60, 71, 80, 81, 82,
`86
`305, 27, 41, 48, 89
`306, 41
`307, 27, 41, 42, 57
`3xx Redirection Status Codes, 40
`400, 23, 25, 27, 28, 42, 80, 105
`401, 27, 42, 43, 66, 92
`402, 27, 42
`403, 27, 42, 107
`404, 27, 42, 43, 44, 107
`405, 24, 27, 43, 66
`406, 27, 43, 47, 63, 64
`407, 27, 43, 84
`408, 27, 43
`409, 27, 43
`410, 27, 44, 57
`411, 23, 27, 44
`412, 27, 44, 80, 82, 83
`413, 27, 44
`414, 14, 27, 44
`415, 27, 44, 73
`416, 27, 44, 76, 77, 85, 106
`417, 27, 45, 78, 107
`
`4xx Client Error Status Codes, 42
`500, 27, 45, 77
`501, 18, 24, 27, 36, 45
`502, 27, 45
`503, 27, 45, 77, 87
`504, 27, 45, 71
`505, 27, 45
`5xx Server Error Status Codes, 45
`abs_path, 14, 15, 24, 25
`absoluteURI, 14, 24, 25, 74, 83, 86
`Accept, 18, 26, 46, 49, 62, 63, 64, 65, 94
`acceptable-ranges, 66
`Accept-Charset, 26, 46, 64
`Accept-Encoding, 16, 17, 26, 46, 47, 64, 65
`accept-extension, 62
`Accept-Language, 20, 26, 46, 47, 65, 91, 94
`accept-params, 62, 87
`Accept-Ranges, 28, 66
`Access Authentication, 46
`Basic and Digest. See [43]
`Acknowledgements, 96
`age, 9
`Age, 28, 51, 52, 66
`age-value, 66
`Allow, 24, 28, 34, 43, 66
`ALPHA, 11, 12
`Alternates. See RFC 2068
`ANSI X3.4-1986, 12, 98
`asctime-date, 15
`attribute, 17
`authority, 14, 24, 25
`Authorization, 26, 42, 57, 66, 67, 68, 85
`Backus-Naur Form, 11
`Basic Authentication. See [43]
`BCP 18, 99
`BCP 9, 99
`byte-content-range-spec, 75, 76
`byte-range, 55
`byte-range-resp-spec, 75, 76
`byte-range-set, 85
`byte-range-spec, 44, 76, 85
`byte-ranges-specifier, 85
`bytes, 66
`bytes-unit, 27
`cachable, 9
`cache, 9
`Cache
`
`cachability of responses, 57
`
`Fielding, et al
`
`Standards Track
`
`[Page 109]
`
`Ex. 1002 - Page 418
`Ex. 1002 - Page 418
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`calculating the age of a response, 51
`combining byte ranges, 59
`combining headers, 59
`combining negotiated responses, 60
`constructing responses, 57
`correctness, 48
`disambiguating expiration values, 53
`disambiguating multiple responses, 53
`entity tags used as cache validators, 54
`entry validation, 53
`errors or incomplete responses, 61
`expiration calculation, 52
`explicit expiration time, 50
`GET and HEADcannotaffect caching, 61
`heuristic expiration, 51
`history list behavior, 62
`invalidation cannot be complete, 61
`Last-Modified values used as validators, 54
`mechanisms, 49
`replacement of cached responses, 62
`shared and non-shared, 60
`Warnings, 49
`weak and strong cache validators, 54
`write-through mandatory, 61
`Cache-Control, 23, 36, 39, 40, 41, 42, 49, 50, 51, 52,
`53, 54, 57, 58, 61, 67, 68, 69, 70, 73, 79, 84
`cache-extension, 67
`extensions, 72
`max-age, 51, 52, 53, 57, 67, 68, 69, 70, 71, 79, 106
`max-stale, 49, 67, 70, 71
`min-fresh, 67, 70
`must-revalidate, 67, 70, 71
`no-cache,48, 53, 67, 68, 69, 70, 71, 84
`no-store, 48, 67, 69
`no-transform, 67, 72, 73
`only-if-cached, 67, 7Z
`Private, 57, 67, 68, 69, 72
`proxy-revalidate, 57, 67, 71
`public, 49, 57, 67, 68, 69, 71
`s-maxage, 53, 57, 67, 68, 69, 106
`cache-directive, 67, 72, 84
`cache-request-directive, 48, 67
`Changes from HTTP/1.0. See RFC 1945 and RFC
`2068
`
`Host requirement, 105
`CHAR,12
`charset, 16, 64
`chunk, 78
`chunk-data, 18
`chunked, 87, 88
`Chunked-Body, 78
`chunk-extension, 18
`chunk-ext-name, 18
`chunk-ext-val, 18
`
`chunk-size, 18
`client, 8
`codings, 64
`comment, 23, 89, 90
`Compatibility
`missing charset, 16
`multipart/x-byteranges, 102
`Compatibility with previous HTTP versions, 105
`CONNECT,24, 25. See [44].
`connection, 8
`Connection, 23, 30, 31, 58, 72, 73, 87, 89, 105, 106
`close, 30, 73, 106
`Keep-Alive, 106. See RFC 2068
`connection-token, 72, 73
`Content Codings
`compress, 17
`deflate, 17
`gzip, 17
`identity, 77
`content negotiation, 8
`Content Negotiation, 46
`Content-Base, 106. See RFC 2068
`content-cncoding, 73
`content-coding, 16, 17, 18, 19, 46, 64, 65, 73, 88, 92,
`107
`
`identity, 106
`newtokens SHOULDberegistered with IANA,17
`qvalues used with, 65
`content-disposition, 104
`Content-Disposition, 95, 98, 104
`Content-Encoding, 16, 17, 28, 29, 58, 73, 75, 92, 103
`Content-Language, 20, 28, 73, 74, 91
`Content-Length, 22, 23, 28, 32, 34, 35, 39, 44, 59,
`61, 74, 76, 88, 104, 107
`Content-Location, 28, 39, 41, 58, 60, 61, 74, 83, 95
`Content-MD5, 28, 35, 58, 75, 98
`Content-Range, 39, 40, 57, 75
`content-range-spec, 75
`Content-Transfer-Encoding, 17, 75, 103
`Content-Type, 16, 18, 28, 29, 34, 37, 38, 39, 40, 43,
`58, 73, 76, 77, 92, 101, 103
`Content-Version. See RFC 2068
`CR, 12, 19, 24, 26, 27, 102, 103
`CRLE’, 11, 72, 13, 18, 19, 21, 24, 26, 75, 102, 103
`ctext, 13
`CTL, 12
`Date, 23, 39, 41, 51, 53, 55, 57, 60, 62, 69, 77, 79,
`83, 92, 103
`date1, 15
`date2, 15
`date3, 15
`DELETE,24, 34, 36, 61
`delta-seconds, 16, 87
`Derived-From. See RFC 2068
`
`Fielding, et al
`
`Standards Track
`
`[Page 110]
`
`Ex. 1002 - Page 419
`Ex. 1002 - Page 419
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`Differences between MIME and HTTP, 102
`canonical form, 103
`Content-Encoding, 103
`Content-Transfer-Encoding, 103
`date formats, 103
`MIME-Version, 102
`Transfer-Encoding, 103
`Digest Authentication, 58. See [43]
`DIGIT, 11, 12, 13, 15, 20, 84, 102
`disp-extension-token, 104
`disposition-parm, 104
`disposition-type, 104
`DNS, 94, 95, 106
`HTTP applications MUSTobey TTL information,
`94
`downstream, 10
`End-to-end headers, 58
`entity, 8
`Entity, 28
`Entity body, 29
`Entity Tags, 20, 54
`entity-body, 29
`entity-header, 24, 26, 28
`Entity-header fields, 28
`entity-length, 29, 59
`entity-tag, 27, 81, 82
`
`Etag, 106
`ETag, 20, 28, 35, 38, 39, 41, 54, 58, 59, 60, 78, 82
`Expect, 26, 32, 33, 37, 45, 78, 107
`expectation, 78
`expectation-extension, 78
`expect-params, 78
`Expires, 28, 36, 39, 40, 41, 42, 51, 52, 53, 57, 58, 69,
`70, 71, 78, 79, 102
`explicit expiration time, 9
`extension-code, 27
`extension-header, 28
`extension-pragma, 84
`field-content, 22
`field-name, 22
`field-value, 22
`filename-parm, 104
`first-byte-pos, 44, 76, 85
`first-hand, 9
`fresh, 9
`freshness lifetime, 9
`freshness_lifetime, 53
`From, 26, 31, 79, 93
`gateway, 9
`General HeaderFields, 23
`general-header, 23, 24, 26
`generic-message, 21
`GET, 14, 24, 25, 34, 35, 38, 39, 40, 41, 42, 44, 54,
`55, 56, 61, 66, 74, 77, 80, 81, 82, 86, 93
`
`HEAD, 22, 23, 24, 34, 35, 38, 40, 41, 42, 43, 45, 61,
`66, 74, 77, 82
`Headers
`
`end-to-end, 58, 59, 73, 78
`hop-by-hop, 10, 58
`non-modifiable headers, 58
`Henrik Frystyk Nielsen, 100
`heuristic expiration time, 9
`HEX,13, 15, 18
`Hop-by-hop headers, 58
`host, 74, 90, 91
`Host, 25, 26, 33, 79, 80, 105
`HT, 11, 22, 13, 22, 102
`http_URL, 24
`HTTP-date, 15,77, 79, 80, 82, 83, 87, 91
`HTTP-message, 27
`HTTP-Version, £3, 24, 26
`IANA,16, 77, 19, 20, 63, 100
`identity, 17, 64, 65, 73, 106
`If-Match, 20, 26, 35, 56, 80, 81, 82, 86
`If-Modified-Since, 26, 35, 55, 56, 80, 81, 82, 83, 86
`If-None-Match, 20, 26, 35, 56, 60, 80, 87, 82, 83, 86
`If-Range, 20, 26, 35, 39, 44, 56, 76, 82, 86
`If-Unmodified-Since, 26, 35, 55, 56, 81, 82, 83, 86
`If-Unmodified-Since, 83
`implied *LWS, 12
`inbound, 20
`instance-length, 76
`TSO-10646, 99
`ISO-2022, 16
`ISO-3166, 20
`1SO-639, 20
`ISO-8859, 98
`1SO-8859-1, 13, 16, 19, 64, 91, 102
`James Gettys, 99
`Jeffrey C. Mogul, 99
`Keep-Alive, 31, 58, 105, 106. See RFC 2068
`Language Tags, 20
`language-range, 65
`language-tag, 20, 65
`Larry Masinter, 100
`last-byte-pos, 76, 85
`last-chunk, 18
`Last-Modified, 10, 28, 35, 39, 51, 53, 54, 55, 56, 57,
`58, 59, 78, 81, 82, 83
`LF, 72, 19, 24, 26, 27, 102, 103
`lifetime, 9, 51, 52, 53, 66, 70, 92
`Link. See RFC 2068
`LINK.See REC 2068
`LOALPHA, 2
`Location, 28, 36, 38, 40, 41, 42, 61, 83, 95
`Lws, 11, 72, 13, 22
`Max-Forwards, 26, 34, 37, 83, 84
`MAY,7
`
`Fielding, et al
`
`Standards Track
`
`[Page 111]
`
`Ex. 1002 - Page 420
`Ex. 1002 - Page 420
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`media type, 12, 16, 19, 23, 29, 38, 40, 43, 46, 63, 72,
`73, 74, 77, 100, 101, 102, 103
`Media Types, 18
`media-range, 62
`media-type, £8, 19, 73, 75, 92
`message, 8
`Message Body, 22
`Message Headers, 27
`Message Length, 23
`Message Transmission Requirements, 31
`Message Types, 27
`message-body, 21, 22, 24, 26, 29
`message-header, 21, 22, 28
`Method, 24, 66
`Method Definitions, 33
`Methods
`
`Idempotent, 34
`Safe and Idempotent, 33
`MIME, 7, 10, 16, 17, 19, 74, 75, 96, 97, 99, 102,
`103, 104
`multipart, 79
`MIME-Version, 102
`month, 75
`multipart/byteranges, 19, 23, 39, 45, 76, 101
`multipart/x-byteranges, 102
`MUST, 7
`MUST NOT,7
`N tule, 12
`name, 11
`non-shared cache, 60, 68, 72
`non-transparent proxy. See proxy: non-transparent
`OCTET, 22, 29
`opaque-tag, 27
`OPTIONAL,7
`OPTIONS, 24, 25, 34, 83, 84
`origin server, 8
`other-range-unit, 27
`outbound, 20
`parameter, 17
`PATCH. See RFC 2068
`Paul J. Leach, 100
`Persistent Connections, 29
`Overall Operation, 30
`Purpose, 29
`Use of Connection Header, 30
`Pipelining, 30
`port, 14, 90, 91
`POST,20, 21, 24, 32, 34, 35, 36, 38, 40, 41, 44, 61,
`77, 93
`Pragma, 23, 67, 70, 84
`no-cache,48, 53, 67, 84
`pragma-directive, 84
`primary-tag, 20
`product, 20, 89
`
`Product tokens, 20
`product-version, 20
`protocol-name, 90
`protocol-version, 90
`proxy, 9
`non-transparent, 9, 59, 72, 73
`transparent, 9, 29, 58
`Proxy-Authenticate, 28, 43, 58, 84, 85
`Proxy-Authorization, 26, 43, 58, 85
`pseudonym, 90, 91
`Public. See RFC 2068
`
`public cache, 46, 47
`PUT,24, 32, 34, 36, 43, 61, 66, 77, 80, 82
`qdtext, 13
`Quality Values, 20
`query, 14
`quoted-pair, 73
`quoted-string, 12, 23, 18, 21, 22, 62, 68, 78, 84, 91,
`104
`
`qvalue, 20, 62, 64
`Range, 21, 26, 28, 35, 36, 39, 40, 44, 45, 57, 58, 59,
`76, 77, 81, 82, 85, 86, 101
`Range Units, 27
`tanges-specifier, 76, 85, 86
`range-unit, 27, 66
`Reason-Phrase, 26, 27
`teceived-by, 90
`received-protocol, 90, 91
`RECOMMENDED,7
`References, 97
`Referer, 26, 86, 93
`rel_path, 24, 61
`trelativeURI, 14, 74, 86
`representation, 8
`request, 8
`Request, 24
`Request headerfields, 26
`request-header, 24, 26
`Request-Line, 21, 24, 25
`3
`Request-URI, 14, 24, 25
`42, 43, 44, 60, 61, 66, 73, 74, 83, 84, 86, 92, 93,
`94
`
`;
`
`REQUIRED, 7
`Requirements
`compliance, 7
`key words, 7
`resource, 8
`response, 8
`Response, 26
`Response HeaderFields, 28
`tesponse-header, 26, 28
`Retry-After, 28, 44, 45, 87
`Revalidation
`end-to-end, 70
`
`Fielding, et al
`
`Standards Track
`
`[Page 112]
`
`Ex. 1002 - Page 421
`Ex. 1002 - Page 421
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`
`
`end-to-end reload, 70
`end-to-end specific revalidation, 70
`end-to-end unspecific revalidation, 70
`RFC 1036, 15, 97
`RFC 1123, 15,77, 79, 97
`RFC 1305, 98
`RFC 1436, 97
`RFC 1590, 19, 97
`RFC 1630, 97
`RFC 1700, 97
`RFC 1737, 98
`RFC 1738, 14, 97
`RFC 1766, 20, 97
`RFC 1806, 95, 98, 104
`RFC 1808, 14, 97
`RFC 1864, 75, 98
`RFC 1866, 97
`RFC 1867, 20, 97
`RFC 1900, 14, 98
`RFC 1945, 7, 41, 97, 104
`REC 1950, 17, 98
`RFC 1951, 17, 98
`REC 1952, 98
`RFC 2026, 99
`REC 2045, 97, 102, 103
`RFC 2046, 19, 99, 101, 103
`REC 2047, 13,91, 97
`RFC 2049, 99, 103
`REC 2068, 1, 14, 29, 31, 32, 41, 97, 98, 104, 105,
`106
`
`
`
`changesfrom, 106
`RFC 2069, 98
`RFC 2076, 99, 104
`REC 2110, 99
`RFC 2119, 7, 98, 106
`REC 2145, 13, 98, 106
`RFC 2277, 99
`RFC 2279, 99
`RFC 2324, 99
`REC 2396, 14, 99
`RFC 821, 97
`REC 822, 11, 15, 21, 77, 79, 90, 96, 97, 102
`RFC 850, 15
`REC 959, 97
`RFC 977, 97
`rfc1123-date, 75
`RFC-850, 102
`rfc850-date, 15
`RoyT. Fielding, 99
`rile! | rule2, 17
`Safe and Idempotent Methods, 33
`Security Considerations, 92
`abuse of server logs, 93
`Accept header, 94
`
`Accept headers can reveal ethnic information, 94
`attacks based on path names, 94
`Authentication Credentials and Idle Clients, 95
`be careful about personal information, 92
`Content-Disposition Header, 95
`Content-Location header, 95
`encoding information in URT's, 93
`Fromheader, 93, 94
`GET method, 93
`Location header, 95
`Location headers and spoofing, 95
`Proxies and Caching, 95
`Referer header, 93
`sensitive headers, 93
`Server header, 93
`Transfer of Sensitive Information, 93
`Via header, 93
`selecting request-headers, 60
`semantically transparent, 70
`separators, 73
`server, 8
`Server, 20, 28, 87, 90, 93
`SHALL,7
`SHALL NOT,7
`shared caches, 60, 69
`SHOULD, 7
`SHOULD NOT, 7
`Sb, 11, 72, 13, 15, 22, 24, 26, 75, 91, 102
`stale, 9
`start-line, 27
`Status Code Definitions, 37
`Status-Code, 26, 27, 37
`Status-Line, 21, 26, 28, 37, 102, 105
`STD 1,1
`strong entity tag, 22
`strong validators, 55
`subtag, 20
`subtype, 18
`suffix-byte-range-spec, 85
`suffix-length, 85
`T/TCP, 29
`t-codings, 87
`TE, 18, 26, 58, 87, 88, 107
`TEXT,13
`Tim Berners-Lee, 100
`time, 15
`token, 11, 12, 13, 16, 17, 18, 20, 21, 22, 24, 62, 68,
`72, 78, 84, 89, 90, 104
`Tolerant Applications, 102
`bad dates, 102
`should tolerate whitespace in request and status
`lines, 102
`tolerate LF and ignore CR in line terminators, 102
`
`Fielding, et al
`
`Standards Track
`
`[Page 113]
`
`Ex. 1002 - Page 422
`Ex. 1002 - Page 422
`
`

`

`REC 2616
`
`HYTp/1.1
`
`June, 1999
`
`use lowest common denominator of characterset,
`102
`TRACE,24, 34, 37, 38, 83, 84
`trailer, 18
`Trailer, 18, 23, 88
`trailers, 87
`Trailers, 58
`Transfer Encoding
`chunked, 17
`transfer-coding
`chunked, 17
`deflate, 17
`gzip, 17
`identity, 17
`transfer-coding, 77, 18, 22, 23, 29, 75, 87, 88, 103,
`106, 107
`chunked, 17, 78, 23, 31, 87, 88, 103, 107
`chunked REQUIRED, 23
`compress, 17
`identity, 23
`trailers, 87
`Transfer-Encoding, 17, 22, 23, 29, 34, 58, 88, 103,
`104
`transfer-extension, 17, 87
`transter-length, 29, 59
`transparent
`proxy, 58
`transparent proxy. See proxy: transparent
`tunnel, 9
`type, 18
`UNLINK.See RFC 2068
`UPALPHA,22
`Upgrade, 24, 38, 58, 88, 89
`upstream, 10
`URI. See RFC 2396
`
`URI-reference, 14
`US-ASCI, 12, 16, 102
`user agent, 8
`User-Agent, 20, 26, 47, 89, 90, 93
`validators, 10, 21, 49, 53, 54, 55, 56, 57, 59
`rules on use of, 56
`value, 17
`variant, 8
`Vary, 28, 39, 41, 47, 60, 80, 82, 8&9, 94
`Via, 24, 37, 87, 90, 93
`warn-agent, 91
`warn-code, 59, 91
`warn-codes, 49
`warn-date, 91, 92
`Warning, 24, 48, 49, 50, 53, 57, 59, 70, 91, 92, 107
`Warnings
`110 Responseis stale, 97
`111 Revalidation failed, 92
`112 Disconnected operation, 92
`113 Heuristic expiration, 92
`199 Miscellaneous warning, 92
`214 Transformation applied, 92
`299 Miscellaneouspersistent warning, 92
`warning-value, 91, 92
`warn-text, 91
`weak, 21
`weakentity tag, 27
`weak validators, 55
`weekday, 25
`wkday, 15
`WWW-Authenticate, 28, 42, 84, 92
`x-compress, 65
`X-g7ip, 65
`
`Fielding, et al
`
`Standards Track
`
`[Page 114]
`
`Ex. 1002 - Page 423
`Ex. 1002 - Page 423
`
`

`

`Slice Embedding Solutions for Distributed Service Architectures
`
`Flavio Esposito
`flavio@cs.bu.edu
`
`Ibrahim Matta
`matta@cs.bu.edu
`
`Vatche Ishakian
`visahak @cs.bu.edu
`
`Computer Science Department
`Boston University
`Boston, MA
`
`Technical Report BUCS-TR-2011-025
`
`Abstract—Networkvirtualization provides a novel approach to
`run multiple concurrent virtual networks over a common phys-
`ical network infrastructure. From a research perspective, this
`enables the networking community to concurrently experiment
`with new Internet architectures and protocols. From a market
`perspective, on the other hand, this paradigm is appealing as it
`enables infrastructure service providers to experiment with new
`business models that range from leasing virtual slices of their
`infrastructure to host multiple concurrent network services.
`In this paper, we present the slice embedding problem and
`recent developments in the area. A slice is a set of virtual
`instances spanning a set of physical resources. The embedding
`problem consists of three main tasks:
`(1) resource discovery,
`which involves monitoring the state of the physical resources,
`(2) virtual network mapping, which involves matching users’
`requests with the available resources, and (3) allocation, which
`involves assigning the resources that match the users’ query.
`We also outline how these three tasks are tightly connected,
`and how there exists a wide spectrum of solutions that either
`solve a particular task, or jointly solve multiple tasks along with
`the interactions among them. To dissect the space of solutions, we
`introduce three main classification criteria, namely, (1) the type
`of constraints imposed by the user,
`(2) the type of dynamics
`considered in the embedding process, and (3)
`the allocation
`strategy adopted. Finally, we conclude with a few interesting
`research directions.
`
`T.
`
`INTRODUCTION
`
`Weall became familiar with the layered reference model of
`ISO OSI as well as the layered TCP/IP architecture [47]. In
`these models, a layer is said to provide a service to the layer
`immediately above it. For example, the transport layer pro-
`vides services (logical end-to-end channels) to the application
`layer, and the internetworking layer provides services (packet
`delivery across individual networks) to the transport layer.
`The notion of distributed service architecture extends this
`
`service paradigm to manyother (large scale) distributed sys-
`tems.
`
`including its future archi-
`Aside from the Internet itself,
`tecture design, e.g., NetServ [73] or RINA [23], with the
`term distributed service architecture we refer to a large scale
`distributed system whose architecture is based on a service
`paradigm.
`Some examples are datacenter-based systems [39], Cloud
`Computing [36] (ncluding high performance computing sys-
`tems such as cluster-on-demand services), where the rentable
`resources can scale both up and downas needed, Grid Comput-
`ing [45], overlay networks(e.g., content delivery networks[6],
`
`large scale distributed testbed platforms (e.g., Plan-
`[10]),
`etLab [65], Emulab/Nethed [77], VINI [7], GENT [31]), or
`Service-oriented Architecture (SoA), where web applications
`are the result of the composition of services that need to be
`instantiated across a collection of distributed resources [80].
`A commoncharacteristic of all the above distributed sys-
`tems is that they all provide a service to a set of users or,
`recursively, to another service. In this survey, we restrict our
`focus on a particular type of service: a slice. We define a
`slice to be a set of virtual instances spanning a set of physical
`resources.
`
`The lifetime span of a slice ranges from few seconds (in
`the case of cluster-on-demand services) to several years (in
`case of a virtual network hosting a content distribution service
`similar to Akamai, or even a GENI experiment hostin