Load cups into easysw/current.
[thirdparty/cups.git] / standards / rfc2616.txt
1
2
3
4
5
6
7 Network Working Group                                      R. Fielding
8 Request for Comments: 2616                                   UC Irvine
9 Obsoletes: 2068                                              J. Gettys
10 Category: Standards Track                                   Compaq/W3C
11                                                               J. Mogul
12                                                                 Compaq
13                                                             H. Frystyk
14                                                                W3C/MIT
15                                                            L. Masinter
16                                                                  Xerox
17                                                               P. Leach
18                                                              Microsoft
19                                                         T. Berners-Lee
20                                                                W3C/MIT
21                                                              June 1999
22
23
24                 Hypertext Transfer Protocol -- HTTP/1.1
25
26 Status of this Memo
27
28    This document specifies an Internet standards track protocol for the
29    Internet community, and requests discussion and suggestions for
30    improvements.  Please refer to the current edition of the "Internet
31    Official Protocol Standards" (STD 1) for the standardization state
32    and status of this protocol.  Distribution of this memo is unlimited.
33
34 Copyright Notice
35
36    Copyright (C) The Internet Society (1999).  All Rights Reserved.
37
38 Abstract
39
40    The Hypertext Transfer Protocol (HTTP) is an application-level
41    protocol for distributed, collaborative, hypermedia information
42    systems. It is a generic, stateless, protocol which can be used for
43    many tasks beyond its use for hypertext, such as name servers and
44    distributed object management systems, through extension of its
45    request methods, error codes and headers [47]. A feature of HTTP is
46    the typing and negotiation of data representation, allowing systems
47    to be built independently of the data being transferred.
48
49    HTTP has been in use by the World-Wide Web global information
50    initiative since 1990. This specification defines the protocol
51    referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
52
53
54
55
56
57
58 Fielding, et al.            Standards Track                     [Page 1]
59 \f
60 RFC 2616                        HTTP/1.1                       June 1999
61
62
63 Table of Contents
64
65    1   Introduction ...................................................7
66    1.1    Purpose......................................................7
67    1.2   Requirements .................................................8
68    1.3   Terminology ..................................................8
69    1.4   Overall Operation ...........................................12
70    2   Notational Conventions and Generic Grammar ....................14
71    2.1   Augmented BNF ...............................................14
72    2.2   Basic Rules .................................................15
73    3   Protocol Parameters ...........................................17
74    3.1   HTTP Version ................................................17
75    3.2   Uniform Resource Identifiers ................................18
76    3.2.1    General Syntax ...........................................19
77    3.2.2    http URL .................................................19
78    3.2.3    URI Comparison ...........................................20
79    3.3   Date/Time Formats ...........................................20
80    3.3.1    Full Date ................................................20
81    3.3.2    Delta Seconds ............................................21
82    3.4   Character Sets ..............................................21
83    3.4.1    Missing Charset ..........................................22
84    3.5   Content Codings .............................................23
85    3.6   Transfer Codings ............................................24
86    3.6.1    Chunked Transfer Coding ..................................25
87    3.7   Media Types .................................................26
88    3.7.1    Canonicalization and Text Defaults .......................27
89    3.7.2    Multipart Types ..........................................27
90    3.8   Product Tokens ..............................................28
91    3.9   Quality Values ..............................................29
92    3.10  Language Tags ...............................................29
93    3.11  Entity Tags .................................................30
94    3.12  Range Units .................................................30
95    4   HTTP Message ..................................................31
96    4.1   Message Types ...............................................31
97    4.2   Message Headers .............................................31
98    4.3   Message Body ................................................32
99    4.4   Message Length ..............................................33
100    4.5   General Header Fields .......................................34
101    5   Request .......................................................35
102    5.1   Request-Line ................................................35
103    5.1.1    Method ...................................................36
104    5.1.2    Request-URI ..............................................36
105    5.2   The Resource Identified by a Request ........................38
106    5.3   Request Header Fields .......................................38
107    6   Response ......................................................39
108    6.1   Status-Line .................................................39
109    6.1.1    Status Code and Reason Phrase ............................39
110    6.2   Response Header Fields ......................................41
111
112
113
114 Fielding, et al.            Standards Track                     [Page 2]
115 \f
116 RFC 2616                        HTTP/1.1                       June 1999
117
118
119    7   Entity ........................................................42
120    7.1   Entity Header Fields ........................................42
121    7.2   Entity Body .................................................43
122    7.2.1    Type .....................................................43
123    7.2.2    Entity Length ............................................43
124    8   Connections ...................................................44
125    8.1   Persistent Connections ......................................44
126    8.1.1    Purpose ..................................................44
127    8.1.2    Overall Operation ........................................45
128    8.1.3    Proxy Servers ............................................46
129    8.1.4    Practical Considerations .................................46
130    8.2   Message Transmission Requirements ...........................47
131    8.2.1    Persistent Connections and Flow Control ..................47
132    8.2.2    Monitoring Connections for Error Status Messages .........48
133    8.2.3    Use of the 100 (Continue) Status .........................48
134    8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
135    9   Method Definitions ............................................51
136    9.1   Safe and Idempotent Methods .................................51
137    9.1.1    Safe Methods .............................................51
138    9.1.2    Idempotent Methods .......................................51
139    9.2   OPTIONS .....................................................52
140    9.3   GET .........................................................53
141    9.4   HEAD ........................................................54
142    9.5   POST ........................................................54
143    9.6   PUT .........................................................55
144    9.7   DELETE ......................................................56
145    9.8   TRACE .......................................................56
146    9.9   CONNECT .....................................................57
147    10   Status Code Definitions ......................................57
148    10.1  Informational 1xx ...........................................57
149    10.1.1   100 Continue .............................................58
150    10.1.2   101 Switching Protocols ..................................58
151    10.2  Successful 2xx ..............................................58
152    10.2.1   200 OK ...................................................58
153    10.2.2   201 Created ..............................................59
154    10.2.3   202 Accepted .............................................59
155    10.2.4   203 Non-Authoritative Information ........................59
156    10.2.5   204 No Content ...........................................60
157    10.2.6   205 Reset Content ........................................60
158    10.2.7   206 Partial Content ......................................60
159    10.3  Redirection 3xx .............................................61
160    10.3.1   300 Multiple Choices .....................................61
161    10.3.2   301 Moved Permanently ....................................62
162    10.3.3   302 Found ................................................62
163    10.3.4   303 See Other ............................................63
164    10.3.5   304 Not Modified .........................................63
165    10.3.6   305 Use Proxy ............................................64
166    10.3.7   306 (Unused) .............................................64
167
168
169
170 Fielding, et al.            Standards Track                     [Page 3]
171 \f
172 RFC 2616                        HTTP/1.1                       June 1999
173
174
175    10.3.8   307 Temporary Redirect ...................................65
176    10.4  Client Error 4xx ............................................65
177    10.4.1    400 Bad Request .........................................65
178    10.4.2    401 Unauthorized ........................................66
179    10.4.3    402 Payment Required ....................................66
180    10.4.4    403 Forbidden ...........................................66
181    10.4.5    404 Not Found ...........................................66
182    10.4.6    405 Method Not Allowed ..................................66
183    10.4.7    406 Not Acceptable ......................................67
184    10.4.8    407 Proxy Authentication Required .......................67
185    10.4.9    408 Request Timeout .....................................67
186    10.4.10   409 Conflict ............................................67
187    10.4.11   410 Gone ................................................68
188    10.4.12   411 Length Required .....................................68
189    10.4.13   412 Precondition Failed .................................68
190    10.4.14   413 Request Entity Too Large ............................69
191    10.4.15   414 Request-URI Too Long ................................69
192    10.4.16   415 Unsupported Media Type ..............................69
193    10.4.17   416 Requested Range Not Satisfiable .....................69
194    10.4.18   417 Expectation Failed ..................................70
195    10.5  Server Error 5xx ............................................70
196    10.5.1   500 Internal Server Error ................................70
197    10.5.2   501 Not Implemented ......................................70
198    10.5.3   502 Bad Gateway ..........................................70
199    10.5.4   503 Service Unavailable ..................................70
200    10.5.5   504 Gateway Timeout ......................................71
201    10.5.6   505 HTTP Version Not Supported ...........................71
202    11   Access Authentication ........................................71
203    12   Content Negotiation ..........................................71
204    12.1  Server-driven Negotiation ...................................72
205    12.2  Agent-driven Negotiation ....................................73
206    12.3  Transparent Negotiation .....................................74
207    13   Caching in HTTP ..............................................74
208    13.1.1   Cache Correctness ........................................75
209    13.1.2   Warnings .................................................76
210    13.1.3   Cache-control Mechanisms .................................77
211    13.1.4   Explicit User Agent Warnings .............................78
212    13.1.5   Exceptions to the Rules and Warnings .....................78
213    13.1.6   Client-controlled Behavior ...............................79
214    13.2  Expiration Model ............................................79
215    13.2.1   Server-Specified Expiration ..............................79
216    13.2.2   Heuristic Expiration .....................................80
217    13.2.3   Age Calculations .........................................80
218    13.2.4   Expiration Calculations ..................................83
219    13.2.5   Disambiguating Expiration Values .........................84
220    13.2.6   Disambiguating Multiple Responses ........................84
221    13.3  Validation Model ............................................85
222    13.3.1   Last-Modified Dates ......................................86
223
224
225
226 Fielding, et al.            Standards Track                     [Page 4]
227 \f
228 RFC 2616                        HTTP/1.1                       June 1999
229
230
231    13.3.2   Entity Tag Cache Validators ..............................86
232    13.3.3   Weak and Strong Validators ...............................86
233    13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
234    13.3.5   Non-validating Conditionals ..............................90
235    13.4  Response Cacheability .......................................91
236    13.5  Constructing Responses From Caches ..........................92
237    13.5.1   End-to-end and Hop-by-hop Headers ........................92
238    13.5.2   Non-modifiable Headers ...................................92
239    13.5.3   Combining Headers ........................................94
240    13.5.4   Combining Byte Ranges ....................................95
241    13.6  Caching Negotiated Responses ................................95
242    13.7  Shared and Non-Shared Caches ................................96
243    13.8  Errors or Incomplete Response Cache Behavior ................97
244    13.9  Side Effects of GET and HEAD ................................97
245    13.10   Invalidation After Updates or Deletions ...................97
246    13.11   Write-Through Mandatory ...................................98
247    13.12   Cache Replacement .........................................99
248    13.13   History Lists .............................................99
249    14   Header Field Definitions ....................................100
250    14.1  Accept .....................................................100
251    14.2  Accept-Charset .............................................102
252    14.3  Accept-Encoding ............................................102
253    14.4  Accept-Language ............................................104
254    14.5  Accept-Ranges ..............................................105
255    14.6  Age ........................................................106
256    14.7  Allow ......................................................106
257    14.8  Authorization ..............................................107
258    14.9  Cache-Control ..............................................108
259    14.9.1   What is Cacheable .......................................109
260    14.9.2   What May be Stored by Caches ............................110
261    14.9.3   Modifications of the Basic Expiration Mechanism .........111
262    14.9.4   Cache Revalidation and Reload Controls ..................113
263    14.9.5   No-Transform Directive ..................................115
264    14.9.6   Cache Control Extensions ................................116
265    14.10   Connection ...............................................117
266    14.11   Content-Encoding .........................................118
267    14.12   Content-Language .........................................118
268    14.13   Content-Length ...........................................119
269    14.14   Content-Location .........................................120
270    14.15   Content-MD5 ..............................................121
271    14.16   Content-Range ............................................122
272    14.17   Content-Type .............................................124
273    14.18   Date .....................................................124
274    14.18.1   Clockless Origin Server Operation ......................125
275    14.19   ETag .....................................................126
276    14.20   Expect ...................................................126
277    14.21   Expires ..................................................127
278    14.22   From .....................................................128
279
280
281
282 Fielding, et al.            Standards Track                     [Page 5]
283 \f
284 RFC 2616                        HTTP/1.1                       June 1999
285
286
287    14.23   Host .....................................................128
288    14.24   If-Match .................................................129
289    14.25   If-Modified-Since ........................................130
290    14.26   If-None-Match ............................................132
291    14.27   If-Range .................................................133
292    14.28   If-Unmodified-Since ......................................134
293    14.29   Last-Modified ............................................134
294    14.30   Location .................................................135
295    14.31   Max-Forwards .............................................136
296    14.32   Pragma ...................................................136
297    14.33   Proxy-Authenticate .......................................137
298    14.34   Proxy-Authorization ......................................137
299    14.35   Range ....................................................138
300    14.35.1    Byte Ranges ...........................................138
301    14.35.2    Range Retrieval Requests ..............................139
302    14.36   Referer ..................................................140
303    14.37   Retry-After ..............................................141
304    14.38   Server ...................................................141
305    14.39   TE .......................................................142
306    14.40   Trailer ..................................................143
307    14.41  Transfer-Encoding..........................................143
308    14.42   Upgrade ..................................................144
309    14.43   User-Agent ...............................................145
310    14.44   Vary .....................................................145
311    14.45   Via ......................................................146
312    14.46   Warning ..................................................148
313    14.47   WWW-Authenticate .........................................150
314    15 Security Considerations .......................................150
315    15.1      Personal Information....................................151
316    15.1.1   Abuse of Server Log Information .........................151
317    15.1.2   Transfer of Sensitive Information .......................151
318    15.1.3   Encoding Sensitive Information in URI's .................152
319    15.1.4   Privacy Issues Connected to Accept Headers ..............152
320    15.2  Attacks Based On File and Path Names .......................153
321    15.3  DNS Spoofing ...............................................154
322    15.4  Location Headers and Spoofing ..............................154
323    15.5  Content-Disposition Issues .................................154
324    15.6  Authentication Credentials and Idle Clients ................155
325    15.7  Proxies and Caching ........................................155
326    15.7.1    Denial of Service Attacks on Proxies....................156
327    16   Acknowledgments .............................................156
328    17   References ..................................................158
329    18   Authors' Addresses ..........................................162
330    19   Appendices ..................................................164
331    19.1  Internet Media Type message/http and application/http ......164
332    19.2  Internet Media Type multipart/byteranges ...................165
333    19.3  Tolerant Applications ......................................166
334    19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
335
336
337
338 Fielding, et al.            Standards Track                     [Page 6]
339 \f
340 RFC 2616                        HTTP/1.1                       June 1999
341
342
343    19.4.1   MIME-Version ............................................167
344    19.4.2   Conversion to Canonical Form ............................167
345    19.4.3   Conversion of Date Formats ..............................168
346    19.4.4   Introduction of Content-Encoding ........................168
347    19.4.5   No Content-Transfer-Encoding ............................168
348    19.4.6   Introduction of Transfer-Encoding .......................169
349    19.4.7   MHTML and Line Length Limitations .......................169
350    19.5  Additional Features ........................................169
351    19.5.1   Content-Disposition .....................................170
352    19.6  Compatibility with Previous Versions .......................170
353    19.6.1   Changes from HTTP/1.0 ...................................171
354    19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
355    19.6.3   Changes from RFC 2068 ...................................172
356    20   Index .......................................................175
357    21   Full Copyright Statement ....................................176
358
359 1 Introduction
360
361 1.1 Purpose
362
363    The Hypertext Transfer Protocol (HTTP) is an application-level
364    protocol for distributed, collaborative, hypermedia information
365    systems. HTTP has been in use by the World-Wide Web global
366    information initiative since 1990. The first version of HTTP,
367    referred to as HTTP/0.9, was a simple protocol for raw data transfer
368    across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
369    the protocol by allowing messages to be in the format of MIME-like
370    messages, containing metainformation about the data transferred and
371    modifiers on the request/response semantics. However, HTTP/1.0 does
372    not sufficiently take into consideration the effects of hierarchical
373    proxies, caching, the need for persistent connections, or virtual
374    hosts. In addition, the proliferation of incompletely-implemented
375    applications calling themselves "HTTP/1.0" has necessitated a
376    protocol version change in order for two communicating applications
377    to determine each other's true capabilities.
378
379    This specification defines the protocol referred to as "HTTP/1.1".
380    This protocol includes more stringent requirements than HTTP/1.0 in
381    order to ensure reliable implementation of its features.
382
383    Practical information systems require more functionality than simple
384    retrieval, including search, front-end update, and annotation. HTTP
385    allows an open-ended set of methods and headers that indicate the
386    purpose of a request [47]. It builds on the discipline of reference
387    provided by the Uniform Resource Identifier (URI) [3], as a location
388    (URL) [4] or name (URN) [20], for indicating the resource to which a
389
390
391
392
393
394 Fielding, et al.            Standards Track                     [Page 7]
395 \f
396 RFC 2616                        HTTP/1.1                       June 1999
397
398
399    method is to be applied. Messages are passed in a format similar to
400    that used by Internet mail [9] as defined by the Multipurpose
401    Internet Mail Extensions (MIME) [7].
402
403    HTTP is also used as a generic protocol for communication between
404    user agents and proxies/gateways to other Internet systems, including
405    those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
406    and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
407    access to resources available from diverse applications.
408
409 1.2 Requirements
410
411    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
412    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
413    document are to be interpreted as described in RFC 2119 [34].
414
415    An implementation is not compliant if it fails to satisfy one or more
416    of the MUST or REQUIRED level requirements for the protocols it
417    implements. An implementation that satisfies all the MUST or REQUIRED
418    level and all the SHOULD level requirements for its protocols is said
419    to be "unconditionally compliant"; one that satisfies all the MUST
420    level requirements but not all the SHOULD level requirements for its
421    protocols is said to be "conditionally compliant."
422
423 1.3 Terminology
424
425    This specification uses a number of terms to refer to the roles
426    played by participants in, and objects of, the HTTP communication.
427
428    connection
429       A transport layer virtual circuit established between two programs
430       for the purpose of communication.
431
432    message
433       The basic unit of HTTP communication, consisting of a structured
434       sequence of octets matching the syntax defined in section 4 and
435       transmitted via the connection.
436
437    request
438       An HTTP request message, as defined in section 5.
439
440    response
441       An HTTP response message, as defined in section 6.
442
443
444
445
446
447
448
449
450 Fielding, et al.            Standards Track                     [Page 8]
451 \f
452 RFC 2616                        HTTP/1.1                       June 1999
453
454
455    resource
456       A network data object or service that can be identified by a URI,
457       as defined in section 3.2. Resources may be available in multiple
458       representations (e.g. multiple languages, data formats, size, and
459       resolutions) or vary in other ways.
460
461    entity
462       The information transferred as the payload of a request or
463       response. An entity consists of metainformation in the form of
464       entity-header fields and content in the form of an entity-body, as
465       described in section 7.
466
467    representation
468       An entity included with a response that is subject to content
469       negotiation, as described in section 12. There may exist multiple
470       representations associated with a particular response status.
471
472    content negotiation
473       The mechanism for selecting the appropriate representation when
474       servicing a request, as described in section 12. The
475       representation of entities in any response can be negotiated
476       (including error responses).
477
478    variant
479       A resource may have one, or more than one, representation(s)
480       associated with it at any given instant. Each of these
481       representations is termed a `varriant'.  Use of the term `variant'
482       does not necessarily imply that the resource is subject to content
483       negotiation.
484
485    client
486       A program that establishes connections for the purpose of sending
487       requests.
488
489    user agent
490       The client which initiates a request. These are often browsers,
491       editors, spiders (web-traversing robots), or other end user tools.
492
493    server
494       An application program that accepts connections in order to
495       service requests by sending back responses. Any given program may
496       be capable of being both a client and a server; our use of these
497       terms refers only to the role being performed by the program for a
498       particular connection, rather than to the program's capabilities
499       in general. Likewise, any server may act as an origin server,
500       proxy, gateway, or tunnel, switching behavior based on the nature
501       of each request.
502
503
504
505
506 Fielding, et al.            Standards Track                     [Page 9]
507 \f
508 RFC 2616                        HTTP/1.1                       June 1999
509
510
511    origin server
512       The server on which a given resource resides or is to be created.
513
514    proxy
515       An intermediary program which acts as both a server and a client
516       for the purpose of making requests on behalf of other clients.
517       Requests are serviced internally or by passing them on, with
518       possible translation, to other servers. A proxy MUST implement
519       both the client and server requirements of this specification. A
520       "transparent proxy" is a proxy that does not modify the request or
521       response beyond what is required for proxy authentication and
522       identification. A "non-transparent proxy" is a proxy that modifies
523       the request or response in order to provide some added service to
524       the user agent, such as group annotation services, media type
525       transformation, protocol reduction, or anonymity filtering. Except
526       where either transparent or non-transparent behavior is explicitly
527       stated, the HTTP proxy requirements apply to both types of
528       proxies.
529
530    gateway
531       A server which acts as an intermediary for some other server.
532       Unlike a proxy, a gateway receives requests as if it were the
533       origin server for the requested resource; the requesting client
534       may not be aware that it is communicating with a gateway.
535
536    tunnel
537       An intermediary program which is acting as a blind relay between
538       two connections. Once active, a tunnel is not considered a party
539       to the HTTP communication, though the tunnel may have been
540       initiated by an HTTP request. The tunnel ceases to exist when both
541       ends of the relayed connections are closed.
542
543    cache
544       A program's local store of response messages and the subsystem
545       that controls its message storage, retrieval, and deletion. A
546       cache stores cacheable responses in order to reduce the response
547       time and network bandwidth consumption on future, equivalent
548       requests. Any client or server may include a cache, though a cache
549       cannot be used by a server that is acting as a tunnel.
550
551    cacheable
552       A response is cacheable if a cache is allowed to store a copy of
553       the response message for use in answering subsequent requests. The
554       rules for determining the cacheability of HTTP responses are
555       defined in section 13. Even if a resource is cacheable, there may
556       be additional constraints on whether a cache can use the cached
557       copy for a particular request.
558
559
560
561
562 Fielding, et al.            Standards Track                    [Page 10]
563 \f
564 RFC 2616                        HTTP/1.1                       June 1999
565
566
567    first-hand
568       A response is first-hand if it comes directly and without
569       unnecessary delay from the origin server, perhaps via one or more
570       proxies. A response is also first-hand if its validity has just
571       been checked directly with the origin server.
572
573    explicit expiration time
574       The time at which the origin server intends that an entity should
575       no longer be returned by a cache without further validation.
576
577    heuristic expiration time
578       An expiration time assigned by a cache when no explicit expiration
579       time is available.
580
581    age
582       The age of a response is the time since it was sent by, or
583       successfully validated with, the origin server.
584
585    freshness lifetime
586       The length of time between the generation of a response and its
587       expiration time.
588
589    fresh
590       A response is fresh if its age has not yet exceeded its freshness
591       lifetime.
592
593    stale
594       A response is stale if its age has passed its freshness lifetime.
595
596    semantically transparent
597       A cache behaves in a "semantically transparent" manner, with
598       respect to a particular response, when its use affects neither the
599       requesting client nor the origin server, except to improve
600       performance. When a cache is semantically transparent, the client
601       receives exactly the same response (except for hop-by-hop headers)
602       that it would have received had its request been handled directly
603       by the origin server.
604
605    validator
606       A protocol element (e.g., an entity tag or a Last-Modified time)
607       that is used to find out whether a cache entry is an equivalent
608       copy of an entity.
609
610    upstream/downstream
611       Upstream and downstream describe the flow of a message: all
612       messages flow from upstream to downstream.
613
614
615
616
617
618 Fielding, et al.            Standards Track                    [Page 11]
619 \f
620 RFC 2616                        HTTP/1.1                       June 1999
621
622
623    inbound/outbound
624       Inbound and outbound refer to the request and response paths for
625       messages: "inbound" means "traveling toward the origin server",
626       and "outbound" means "traveling toward the user agent"
627
628 1.4 Overall Operation
629
630    The HTTP protocol is a request/response protocol. A client sends a
631    request to the server in the form of a request method, URI, and
632    protocol version, followed by a MIME-like message containing request
633    modifiers, client information, and possible body content over a
634    connection with a server. The server responds with a status line,
635    including the message's protocol version and a success or error code,
636    followed by a MIME-like message containing server information, entity
637    metainformation, and possible entity-body content. The relationship
638    between HTTP and MIME is described in appendix 19.4.
639
640    Most HTTP communication is initiated by a user agent and consists of
641    a request to be applied to a resource on some origin server. In the
642    simplest case, this may be accomplished via a single connection (v)
643    between the user agent (UA) and the origin server (O).
644
645           request chain ------------------------>
646        UA -------------------v------------------- O
647           <----------------------- response chain
648
649    A more complicated situation occurs when one or more intermediaries
650    are present in the request/response chain. There are three common
651    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
652    forwarding agent, receiving requests for a URI in its absolute form,
653    rewriting all or part of the message, and forwarding the reformatted
654    request toward the server identified by the URI. A gateway is a
655    receiving agent, acting as a layer above some other server(s) and, if
656    necessary, translating the requests to the underlying server's
657    protocol. A tunnel acts as a relay point between two connections
658    without changing the messages; tunnels are used when the
659    communication needs to pass through an intermediary (such as a
660    firewall) even when the intermediary cannot understand the contents
661    of the messages.
662
663           request chain -------------------------------------->
664        UA -----v----- A -----v----- B -----v----- C -----v----- O
665           <------------------------------------- response chain
666
667    The figure above shows three intermediaries (A, B, and C) between the
668    user agent and origin server. A request or response message that
669    travels the whole chain will pass through four separate connections.
670    This distinction is important because some HTTP communication options
671
672
673
674 Fielding, et al.            Standards Track                    [Page 12]
675 \f
676 RFC 2616                        HTTP/1.1                       June 1999
677
678
679    may apply only to the connection with the nearest, non-tunnel
680    neighbor, only to the end-points of the chain, or to all connections
681    along the chain. Although the diagram is linear, each participant may
682    be engaged in multiple, simultaneous communications. For example, B
683    may be receiving requests from many clients other than A, and/or
684    forwarding requests to servers other than C, at the same time that it
685    is handling A's request.
686
687    Any party to the communication which is not acting as a tunnel may
688    employ an internal cache for handling requests. The effect of a cache
689    is that the request/response chain is shortened if one of the
690    participants along the chain has a cached response applicable to that
691    request. The following illustrates the resulting chain if B has a
692    cached copy of an earlier response from O (via C) for a request which
693    has not been cached by UA or A.
694
695           request chain ---------->
696        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
697           <--------- response chain
698
699    Not all responses are usefully cacheable, and some requests may
700    contain modifiers which place special requirements on cache behavior.
701    HTTP requirements for cache behavior and cacheable responses are
702    defined in section 13.
703
704    In fact, there are a wide variety of architectures and configurations
705    of caches and proxies currently being experimented with or deployed
706    across the World Wide Web. These systems include national hierarchies
707    of proxy caches to save transoceanic bandwidth, systems that
708    broadcast or multicast cache entries, organizations that distribute
709    subsets of cached data via CD-ROM, and so on. HTTP systems are used
710    in corporate intranets over high-bandwidth links, and for access via
711    PDAs with low-power radio links and intermittent connectivity. The
712    goal of HTTP/1.1 is to support the wide diversity of configurations
713    already deployed while introducing protocol constructs that meet the
714    needs of those who build web applications that require high
715    reliability and, failing that, at least reliable indications of
716    failure.
717
718    HTTP communication usually takes place over TCP/IP connections. The
719    default port is TCP 80 [19], but other ports can be used. This does
720    not preclude HTTP from being implemented on top of any other protocol
721    on the Internet, or on other networks. HTTP only presumes a reliable
722    transport; any protocol that provides such guarantees can be used;
723    the mapping of the HTTP/1.1 request and response structures onto the
724    transport data units of the protocol in question is outside the scope
725    of this specification.
726
727
728
729
730 Fielding, et al.            Standards Track                    [Page 13]
731 \f
732 RFC 2616                        HTTP/1.1                       June 1999
733
734
735    In HTTP/1.0, most implementations used a new connection for each
736    request/response exchange. In HTTP/1.1, a connection may be used for
737    one or more request/response exchanges, although connections may be
738    closed for a variety of reasons (see section 8.1).
739
740 2 Notational Conventions and Generic Grammar
741
742 2.1 Augmented BNF
743
744    All of the mechanisms specified in this document are described in
745    both prose and an augmented Backus-Naur Form (BNF) similar to that
746    used by RFC 822 [9]. Implementors will need to be familiar with the
747    notation in order to understand this specification. The augmented BNF
748    includes the following constructs:
749
750    name = definition
751       The name of a rule is simply the name itself (without any
752       enclosing "<" and ">") and is separated from its definition by the
753       equal "=" character. White space is only significant in that
754       indentation of continuation lines is used to indicate a rule
755       definition that spans more than one line. Certain basic rules are
756       in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
757       brackets are used within definitions whenever their presence will
758       facilitate discerning the use of rule names.
759
760    "literal"
761       Quotation marks surround literal text. Unless stated otherwise,
762       the text is case-insensitive.
763
764    rule1 | rule2
765       Elements separated by a bar ("|") are alternatives, e.g., "yes |
766       no" will accept yes or no.
767
768    (rule1 rule2)
769       Elements enclosed in parentheses are treated as a single element.
770       Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
771       foo elem" and "elem bar elem".
772
773    *rule
774       The character "*" preceding an element indicates repetition. The
775       full form is "<n>*<m>element" indicating at least <n> and at most
776       <m> occurrences of element. Default values are 0 and infinity so
777       that "*(element)" allows any number, including zero; "1*element"
778       requires at least one; and "1*2element" allows one or two.
779
780    [rule]
781       Square brackets enclose optional elements; "[foo bar]" is
782       equivalent to "*1(foo bar)".
783
784
785
786 Fielding, et al.            Standards Track                    [Page 14]
787 \f
788 RFC 2616                        HTTP/1.1                       June 1999
789
790
791    N rule
792       Specific repetition: "<n>(element)" is equivalent to
793       "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
794       Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
795       alphabetic characters.
796
797    #rule
798       A construct "#" is defined, similar to "*", for defining lists of
799       elements. The full form is "<n>#<m>element" indicating at least
800       <n> and at most <m> elements, each separated by one or more commas
801       (",") and OPTIONAL linear white space (LWS). This makes the usual
802       form of lists very easy; a rule such as
803          ( *LWS element *( *LWS "," *LWS element ))
804       can be shown as
805          1#element
806       Wherever this construct is used, null elements are allowed, but do
807       not contribute to the count of elements present. That is,
808       "(element), , (element) " is permitted, but counts as only two
809       elements. Therefore, where at least one element is required, at
810       least one non-null element MUST be present. Default values are 0
811       and infinity so that "#element" allows any number, including zero;
812       "1#element" requires at least one; and "1#2element" allows one or
813       two.
814
815    ; comment
816       A semi-colon, set off some distance to the right of rule text,
817       starts a comment that continues to the end of line. This is a
818       simple way of including useful notes in parallel with the
819       specifications.
820
821    implied *LWS
822       The grammar described by this specification is word-based. Except
823       where noted otherwise, linear white space (LWS) can be included
824       between any two adjacent words (token or quoted-string), and
825       between adjacent words and separators, without changing the
826       interpretation of a field. At least one delimiter (LWS and/or
827
828       separators) MUST exist between any two tokens (for the definition
829       of "token" below), since they would otherwise be interpreted as a
830       single token.
831
832 2.2 Basic Rules
833
834    The following rules are used throughout this specification to
835    describe basic parsing constructs. The US-ASCII coded character set
836    is defined by ANSI X3.4-1986 [21].
837
838
839
840
841
842 Fielding, et al.            Standards Track                    [Page 15]
843 \f
844 RFC 2616                        HTTP/1.1                       June 1999
845
846
847        OCTET          = <any 8-bit sequence of data>
848        CHAR           = <any US-ASCII character (octets 0 - 127)>
849        UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
850        LOALPHA        = <any US-ASCII lowercase letter "a".."z">
851        ALPHA          = UPALPHA | LOALPHA
852        DIGIT          = <any US-ASCII digit "0".."9">
853        CTL            = <any US-ASCII control character
854                         (octets 0 - 31) and DEL (127)>
855        CR             = <US-ASCII CR, carriage return (13)>
856        LF             = <US-ASCII LF, linefeed (10)>
857        SP             = <US-ASCII SP, space (32)>
858        HT             = <US-ASCII HT, horizontal-tab (9)>
859        <">            = <US-ASCII double-quote mark (34)>
860
861    HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
862    protocol elements except the entity-body (see appendix 19.3 for
863    tolerant applications). The end-of-line marker within an entity-body
864    is defined by its associated media type, as described in section 3.7.
865
866        CRLF           = CR LF
867
868    HTTP/1.1 header field values can be folded onto multiple lines if the
869    continuation line begins with a space or horizontal tab. All linear
870    white space, including folding, has the same semantics as SP. A
871    recipient MAY replace any linear white space with a single SP before
872    interpreting the field value or forwarding the message downstream.
873
874        LWS            = [CRLF] 1*( SP | HT )
875
876    The TEXT rule is only used for descriptive field contents and values
877    that are not intended to be interpreted by the message parser. Words
878    of *TEXT MAY contain characters from character sets other than ISO-
879    8859-1 [22] only when encoded according to the rules of RFC 2047
880    [14].
881
882        TEXT           = <any OCTET except CTLs,
883                         but including LWS>
884
885    A CRLF is allowed in the definition of TEXT only as part of a header
886    field continuation. It is expected that the folding LWS will be
887    replaced with a single SP before interpretation of the TEXT value.
888
889    Hexadecimal numeric characters are used in several protocol elements.
890
891        HEX            = "A" | "B" | "C" | "D" | "E" | "F"
892                       | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
893
894
895
896
897
898 Fielding, et al.            Standards Track                    [Page 16]
899 \f
900 RFC 2616                        HTTP/1.1                       June 1999
901
902
903    Many HTTP/1.1 header field values consist of words separated by LWS
904    or special characters. These special characters MUST be in a quoted
905    string to be used within a parameter value (as defined in section
906    3.6).
907
908        token          = 1*<any CHAR except CTLs or separators>
909        separators     = "(" | ")" | "<" | ">" | "@"
910                       | "," | ";" | ":" | "\" | <">
911                       | "/" | "[" | "]" | "?" | "="
912                       | "{" | "}" | SP | HT
913
914    Comments can be included in some HTTP header fields by surrounding
915    the comment text with parentheses. Comments are only allowed in
916    fields containing "comment" as part of their field value definition.
917    In all other fields, parentheses are considered part of the field
918    value.
919
920        comment        = "(" *( ctext | quoted-pair | comment ) ")"
921        ctext          = <any TEXT excluding "(" and ")">
922
923    A string of text is parsed as a single word if it is quoted using
924    double-quote marks.
925
926        quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
927        qdtext         = <any TEXT except <">>
928
929    The backslash character ("\") MAY be used as a single-character
930    quoting mechanism only within quoted-string and comment constructs.
931
932        quoted-pair    = "\" CHAR
933
934 3 Protocol Parameters
935
936 3.1 HTTP Version
937
938    HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
939    of the protocol. The protocol versioning policy is intended to allow
940    the sender to indicate the format of a message and its capacity for
941    understanding further HTTP communication, rather than the features
942    obtained via that communication. No change is made to the version
943    number for the addition of message components which do not affect
944    communication behavior or which only add to extensible field values.
945    The <minor> number is incremented when the changes made to the
946    protocol add features which do not change the general message parsing
947    algorithm, but which may add to the message semantics and imply
948    additional capabilities of the sender. The <major> number is
949    incremented when the format of a message within the protocol is
950    changed. See RFC 2145 [36] for a fuller explanation.
951
952
953
954 Fielding, et al.            Standards Track                    [Page 17]
955 \f
956 RFC 2616                        HTTP/1.1                       June 1999
957
958
959    The version of an HTTP message is indicated by an HTTP-Version field
960    in the first line of the message.
961
962        HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
963
964    Note that the major and minor numbers MUST be treated as separate
965    integers and that each MAY be incremented higher than a single digit.
966    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
967    lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
968    MUST NOT be sent.
969
970    An application that sends a request or response message that includes
971    HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
972    with this specification. Applications that are at least conditionally
973    compliant with this specification SHOULD use an HTTP-Version of
974    "HTTP/1.1" in their messages, and MUST do so for any message that is
975    not compatible with HTTP/1.0. For more details on when to send
976    specific HTTP-Version values, see RFC 2145 [36].
977
978    The HTTP version of an application is the highest HTTP version for
979    which the application is at least conditionally compliant.
980
981    Proxy and gateway applications need to be careful when forwarding
982    messages in protocol versions different from that of the application.
983    Since the protocol version indicates the protocol capability of the
984    sender, a proxy/gateway MUST NOT send a message with a version
985    indicator which is greater than its actual version. If a higher
986    version request is received, the proxy/gateway MUST either downgrade
987    the request version, or respond with an error, or switch to tunnel
988    behavior.
989
990    Due to interoperability problems with HTTP/1.0 proxies discovered
991    since the publication of RFC 2068[33], caching proxies MUST, gateways
992    MAY, and tunnels MUST NOT upgrade the request to the highest version
993    they support. The proxy/gateway's response to that request MUST be in
994    the same major version as the request.
995
996       Note: Converting between versions of HTTP may involve modification
997       of header fields required or forbidden by the versions involved.
998
999 3.2 Uniform Resource Identifiers
1000
1001    URIs have been known by many names: WWW addresses, Universal Document
1002    Identifiers, Universal Resource Identifiers [3], and finally the
1003    combination of Uniform Resource Locators (URL) [4] and Names (URN)
1004    [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
1005    simply formatted strings which identify--via name, location, or any
1006    other characteristic--a resource.
1007
1008
1009
1010 Fielding, et al.            Standards Track                    [Page 18]
1011 \f
1012 RFC 2616                        HTTP/1.1                       June 1999
1013
1014
1015 3.2.1 General Syntax
1016
1017    URIs in HTTP can be represented in absolute form or relative to some
1018    known base URI [11], depending upon the context of their use. The two
1019    forms are differentiated by the fact that absolute URIs always begin
1020    with a scheme name followed by a colon. For definitive information on
1021    URL syntax and semantics, see "Uniform Resource Identifiers (URI):
1022    Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1023    1738 [4] and RFC 1808 [11]). This specification adopts the
1024    definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
1025    "host","abs_path", "rel_path", and "authority" from that
1026    specification.
1027
1028    The HTTP protocol does not place any a priori limit on the length of
1029    a URI. Servers MUST be able to handle the URI of any resource they
1030    serve, and SHOULD be able to handle URIs of unbounded length if they
1031    provide GET-based forms that could generate such URIs. A server
1032    SHOULD return 414 (Request-URI Too Long) status if a URI is longer
1033    than the server can handle (see section 10.4.15).
1034
1035       Note: Servers ought to be cautious about depending on URI lengths
1036       above 255 bytes, because some older client or proxy
1037       implementations might not properly support these lengths.
1038
1039 3.2.2 http URL
1040
1041    The "http" scheme is used to locate network resources via the HTTP
1042    protocol. This section defines the scheme-specific syntax and
1043    semantics for http URLs.
1044
1045    http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
1046
1047    If the port is empty or not given, port 80 is assumed. The semantics
1048    are that the identified resource is located at the server listening
1049    for TCP connections on that port of that host, and the Request-URI
1050    for the resource is abs_path (section 5.1.2). The use of IP addresses
1051    in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
1052    the abs_path is not present in the URL, it MUST be given as "/" when
1053    used as a Request-URI for a resource (section 5.1.2). If a proxy
1054    receives a host name which is not a fully qualified domain name, it
1055    MAY add its domain to the host name it received. If a proxy receives
1056    a fully qualified domain name, the proxy MUST NOT change the host
1057    name.
1058
1059
1060
1061
1062
1063
1064
1065
1066 Fielding, et al.            Standards Track                    [Page 19]
1067 \f
1068 RFC 2616                        HTTP/1.1                       June 1999
1069
1070
1071 3.2.3 URI Comparison
1072
1073    When comparing two URIs to decide if they match or not, a client
1074    SHOULD use a case-sensitive octet-by-octet comparison of the entire
1075    URIs, with these exceptions:
1076
1077       - A port that is empty or not given is equivalent to the default
1078         port for that URI-reference;
1079
1080         - Comparisons of host names MUST be case-insensitive;
1081
1082         - Comparisons of scheme names MUST be case-insensitive;
1083
1084         - An empty abs_path is equivalent to an abs_path of "/".
1085
1086    Characters other than those in the "reserved" and "unsafe" sets (see
1087    RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
1088
1089    For example, the following three URIs are equivalent:
1090
1091       http://abc.com:80/~smith/home.html
1092       http://ABC.com/%7Esmith/home.html
1093       http://ABC.com:/%7esmith/home.html
1094
1095 3.3 Date/Time Formats
1096
1097 3.3.1 Full Date
1098
1099    HTTP applications have historically allowed three different formats
1100    for the representation of date/time stamps:
1101
1102       Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
1103       Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
1104       Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
1105
1106    The first format is preferred as an Internet standard and represents
1107    a fixed-length subset of that defined by RFC 1123 [8] (an update to
1108    RFC 822 [9]). The second format is in common use, but is based on the
1109    obsolete RFC 850 [12] date format and lacks a four-digit year.
1110    HTTP/1.1 clients and servers that parse the date value MUST accept
1111    all three formats (for compatibility with HTTP/1.0), though they MUST
1112    only generate the RFC 1123 format for representing HTTP-date values
1113    in header fields. See section 19.3 for further information.
1114
1115       Note: Recipients of date values are encouraged to be robust in
1116       accepting date values that may have been sent by non-HTTP
1117       applications, as is sometimes the case when retrieving or posting
1118       messages via proxies/gateways to SMTP or NNTP.
1119
1120
1121
1122 Fielding, et al.            Standards Track                    [Page 20]
1123 \f
1124 RFC 2616                        HTTP/1.1                       June 1999
1125
1126
1127    All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1128    (GMT), without exception. For the purposes of HTTP, GMT is exactly
1129    equal to UTC (Coordinated Universal Time). This is indicated in the
1130    first two formats by the inclusion of "GMT" as the three-letter
1131    abbreviation for time zone, and MUST be assumed when reading the
1132    asctime format. HTTP-date is case sensitive and MUST NOT include
1133    additional LWS beyond that specifically included as SP in the
1134    grammar.
1135
1136        HTTP-date    = rfc1123-date | rfc850-date | asctime-date
1137        rfc1123-date = wkday "," SP date1 SP time SP "GMT"
1138        rfc850-date  = weekday "," SP date2 SP time SP "GMT"
1139        asctime-date = wkday SP date3 SP time SP 4DIGIT
1140        date1        = 2DIGIT SP month SP 4DIGIT
1141                       ; day month year (e.g., 02 Jun 1982)
1142        date2        = 2DIGIT "-" month "-" 2DIGIT
1143                       ; day-month-year (e.g., 02-Jun-82)
1144        date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
1145                       ; month day (e.g., Jun  2)
1146        time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
1147                       ; 00:00:00 - 23:59:59
1148        wkday        = "Mon" | "Tue" | "Wed"
1149                     | "Thu" | "Fri" | "Sat" | "Sun"
1150        weekday      = "Monday" | "Tuesday" | "Wednesday"
1151                     | "Thursday" | "Friday" | "Saturday" | "Sunday"
1152        month        = "Jan" | "Feb" | "Mar" | "Apr"
1153                     | "May" | "Jun" | "Jul" | "Aug"
1154                     | "Sep" | "Oct" | "Nov" | "Dec"
1155
1156       Note: HTTP requirements for the date/time stamp format apply only
1157       to their usage within the protocol stream. Clients and servers are
1158       not required to use these formats for user presentation, request
1159       logging, etc.
1160
1161 3.3.2 Delta Seconds
1162
1163    Some HTTP header fields allow a time value to be specified as an
1164    integer number of seconds, represented in decimal, after the time
1165    that the message was received.
1166
1167        delta-seconds  = 1*DIGIT
1168
1169 3.4 Character Sets
1170
1171    HTTP uses the same definition of the term "character set" as that
1172    described for MIME:
1173
1174
1175
1176
1177
1178 Fielding, et al.            Standards Track                    [Page 21]
1179 \f
1180 RFC 2616                        HTTP/1.1                       June 1999
1181
1182
1183    The term "character set" is used in this document to refer to a
1184    method used with one or more tables to convert a sequence of octets
1185    into a sequence of characters. Note that unconditional conversion in
1186    the other direction is not required, in that not all characters may
1187    be available in a given character set and a character set may provide
1188    more than one sequence of octets to represent a particular character.
1189    This definition is intended to allow various kinds of character
1190    encoding, from simple single-table mappings such as US-ASCII to
1191    complex table switching methods such as those that use ISO-2022's
1192    techniques. However, the definition associated with a MIME character
1193    set name MUST fully specify the mapping to be performed from octets
1194    to characters. In particular, use of external profiling information
1195    to determine the exact mapping is not permitted.
1196
1197       Note: This use of the term "character set" is more commonly
1198       referred to as a "character encoding." However, since HTTP and
1199       MIME share the same registry, it is important that the terminology
1200       also be shared.
1201
1202    HTTP character sets are identified by case-insensitive tokens. The
1203    complete set of tokens is defined by the IANA Character Set registry
1204    [19].
1205
1206        charset = token
1207
1208    Although HTTP allows an arbitrary token to be used as a charset
1209    value, any token that has a predefined value within the IANA
1210    Character Set registry [19] MUST represent the character set defined
1211    by that registry. Applications SHOULD limit their use of character
1212    sets to those defined by the IANA registry.
1213
1214    Implementors should be aware of IETF character set requirements [38]
1215    [41].
1216
1217 3.4.1 Missing Charset
1218
1219    Some HTTP/1.0 software has interpreted a Content-Type header without
1220    charset parameter incorrectly to mean "recipient should guess."
1221    Senders wishing to defeat this behavior MAY include a charset
1222    parameter even when the charset is ISO-8859-1 and SHOULD do so when
1223    it is known that it will not confuse the recipient.
1224
1225    Unfortunately, some older HTTP/1.0 clients did not deal properly with
1226    an explicit charset parameter. HTTP/1.1 recipients MUST respect the
1227    charset label provided by the sender; and those user agents that have
1228    a provision to "guess" a charset MUST use the charset from the
1229
1230
1231
1232
1233
1234 Fielding, et al.            Standards Track                    [Page 22]
1235 \f
1236 RFC 2616                        HTTP/1.1                       June 1999
1237
1238
1239    content-type field if they support that charset, rather than the
1240    recipient's preference, when initially displaying a document. See
1241    section 3.7.1.
1242
1243 3.5 Content Codings
1244
1245    Content coding values indicate an encoding transformation that has
1246    been or can be applied to an entity. Content codings are primarily
1247    used to allow a document to be compressed or otherwise usefully
1248    transformed without losing the identity of its underlying media type
1249    and without loss of information. Frequently, the entity is stored in
1250    coded form, transmitted directly, and only decoded by the recipient.
1251
1252        content-coding   = token
1253
1254    All content-coding values are case-insensitive. HTTP/1.1 uses
1255    content-coding values in the Accept-Encoding (section 14.3) and
1256    Content-Encoding (section 14.11) header fields. Although the value
1257    describes the content-coding, what is more important is that it
1258    indicates what decoding mechanism will be required to remove the
1259    encoding.
1260
1261    The Internet Assigned Numbers Authority (IANA) acts as a registry for
1262    content-coding value tokens. Initially, the registry contains the
1263    following tokens:
1264
1265    gzip An encoding format produced by the file compression program
1266         "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
1267         Lempel-Ziv coding (LZ77) with a 32 bit CRC.
1268
1269    compress
1270         The encoding format produced by the common UNIX file compression
1271         program "compress". This format is an adaptive Lempel-Ziv-Welch
1272         coding (LZW).
1273
1274         Use of program names for the identification of encoding formats
1275         is not desirable and is discouraged for future encodings. Their
1276         use here is representative of historical practice, not good
1277         design. For compatibility with previous implementations of HTTP,
1278         applications SHOULD consider "x-gzip" and "x-compress" to be
1279         equivalent to "gzip" and "compress" respectively.
1280
1281    deflate
1282         The "zlib" format defined in RFC 1950 [31] in combination with
1283         the "deflate" compression mechanism described in RFC 1951 [29].
1284
1285
1286
1287
1288
1289
1290 Fielding, et al.            Standards Track                    [Page 23]
1291 \f
1292 RFC 2616                        HTTP/1.1                       June 1999
1293
1294
1295    identity
1296         The default (identity) encoding; the use of no transformation
1297         whatsoever. This content-coding is used only in the Accept-
1298         Encoding header, and SHOULD NOT be used in the Content-Encoding
1299         header.
1300
1301    New content-coding value tokens SHOULD be registered; to allow
1302    interoperability between clients and servers, specifications of the
1303    content coding algorithms needed to implement a new value SHOULD be
1304    publicly available and adequate for independent implementation, and
1305    conform to the purpose of content coding defined in this section.
1306
1307 3.6 Transfer Codings
1308
1309    Transfer-coding values are used to indicate an encoding
1310    transformation that has been, can be, or may need to be applied to an
1311    entity-body in order to ensure "safe transport" through the network.
1312    This differs from a content coding in that the transfer-coding is a
1313    property of the message, not of the original entity.
1314
1315        transfer-coding         = "chunked" | transfer-extension
1316        transfer-extension      = token *( ";" parameter )
1317
1318    Parameters are in  the form of attribute/value pairs.
1319
1320        parameter               = attribute "=" value
1321        attribute               = token
1322        value                   = token | quoted-string
1323
1324    All transfer-coding values are case-insensitive. HTTP/1.1 uses
1325    transfer-coding values in the TE header field (section 14.39) and in
1326    the Transfer-Encoding header field (section 14.41).
1327
1328    Whenever a transfer-coding is applied to a message-body, the set of
1329    transfer-codings MUST include "chunked", unless the message is
1330    terminated by closing the connection. When the "chunked" transfer-
1331    coding is used, it MUST be the last transfer-coding applied to the
1332    message-body. The "chunked" transfer-coding MUST NOT be applied more
1333    than once to a message-body. These rules allow the recipient to
1334    determine the transfer-length of the message (section 4.4).
1335
1336    Transfer-codings are analogous to the Content-Transfer-Encoding
1337    values of MIME [7], which were designed to enable safe transport of
1338    binary data over a 7-bit transport service. However, safe transport
1339    has a different focus for an 8bit-clean transfer protocol. In HTTP,
1340    the only unsafe characteristic of message-bodies is the difficulty in
1341    determining the exact body length (section 7.2.2), or the desire to
1342    encrypt data over a shared transport.
1343
1344
1345
1346 Fielding, et al.            Standards Track                    [Page 24]
1347 \f
1348 RFC 2616                        HTTP/1.1                       June 1999
1349
1350
1351    The Internet Assigned Numbers Authority (IANA) acts as a registry for
1352    transfer-coding value tokens. Initially, the registry contains the
1353    following tokens: "chunked" (section 3.6.1), "identity" (section
1354    3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
1355    (section 3.5).
1356
1357    New transfer-coding value tokens SHOULD be registered in the same way
1358    as new content-coding value tokens (section 3.5).
1359
1360    A server which receives an entity-body with a transfer-coding it does
1361    not understand SHOULD return 501 (Unimplemented), and close the
1362    connection. A server MUST NOT send transfer-codings to an HTTP/1.0
1363    client.
1364
1365 3.6.1 Chunked Transfer Coding
1366
1367    The chunked encoding modifies the body of a message in order to
1368    transfer it as a series of chunks, each with its own size indicator,
1369    followed by an OPTIONAL trailer containing entity-header fields. This
1370    allows dynamically produced content to be transferred along with the
1371    information necessary for the recipient to verify that it has
1372    received the full message.
1373
1374        Chunked-Body   = *chunk
1375                         last-chunk
1376                         trailer
1377                         CRLF
1378
1379        chunk          = chunk-size [ chunk-extension ] CRLF
1380                         chunk-data CRLF
1381        chunk-size     = 1*HEX
1382        last-chunk     = 1*("0") [ chunk-extension ] CRLF
1383
1384        chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1385        chunk-ext-name = token
1386        chunk-ext-val  = token | quoted-string
1387        chunk-data     = chunk-size(OCTET)
1388        trailer        = *(entity-header CRLF)
1389
1390    The chunk-size field is a string of hex digits indicating the size of
1391    the chunk. The chunked encoding is ended by any chunk whose size is
1392    zero, followed by the trailer, which is terminated by an empty line.
1393
1394    The trailer allows the sender to include additional HTTP header
1395    fields at the end of the message. The Trailer header field can be
1396    used to indicate which header fields are included in a trailer (see
1397    section 14.40).
1398
1399
1400
1401
1402 Fielding, et al.            Standards Track                    [Page 25]
1403 \f
1404 RFC 2616                        HTTP/1.1                       June 1999
1405
1406
1407    A server using chunked transfer-coding in a response MUST NOT use the
1408    trailer for any header fields unless at least one of the following is
1409    true:
1410
1411    a)the request included a TE header field that indicates "trailers" is
1412      acceptable in the transfer-coding of the  response, as described in
1413      section 14.39; or,
1414
1415    b)the server is the origin server for the response, the trailer
1416      fields consist entirely of optional metadata, and the recipient
1417      could use the message (in a manner acceptable to the origin server)
1418      without receiving this metadata.  In other words, the origin server
1419      is willing to accept the possibility that the trailer fields might
1420      be silently discarded along the path to the client.
1421
1422    This requirement prevents an interoperability failure when the
1423    message is being received by an HTTP/1.1 (or later) proxy and
1424    forwarded to an HTTP/1.0 recipient. It avoids a situation where
1425    compliance with the protocol would have necessitated a possibly
1426    infinite buffer on the proxy.
1427
1428    An example process for decoding a Chunked-Body is presented in
1429    appendix 19.4.6.
1430
1431    All HTTP/1.1 applications MUST be able to receive and decode the
1432    "chunked" transfer-coding, and MUST ignore chunk-extension extensions
1433    they do not understand.
1434
1435 3.7 Media Types
1436
1437    HTTP uses Internet Media Types [17] in the Content-Type (section
1438    14.17) and Accept (section 14.1) header fields in order to provide
1439    open and extensible data typing and type negotiation.
1440
1441        media-type     = type "/" subtype *( ";" parameter )
1442        type           = token
1443        subtype        = token
1444
1445    Parameters MAY follow the type/subtype in the form of attribute/value
1446    pairs (as defined in section 3.6).
1447
1448    The type, subtype, and parameter attribute names are case-
1449    insensitive. Parameter values might or might not be case-sensitive,
1450    depending on the semantics of the parameter name. Linear white space
1451    (LWS) MUST NOT be used between the type and subtype, nor between an
1452    attribute and its value. The presence or absence of a parameter might
1453    be significant to the processing of a media-type, depending on its
1454    definition within the media type registry.
1455
1456
1457
1458 Fielding, et al.            Standards Track                    [Page 26]
1459 \f
1460 RFC 2616                        HTTP/1.1                       June 1999
1461
1462
1463    Note that some older HTTP applications do not recognize media type
1464    parameters. When sending data to older HTTP applications,
1465    implementations SHOULD only use media type parameters when they are
1466    required by that type/subtype definition.
1467
1468    Media-type values are registered with the Internet Assigned Number
1469    Authority (IANA [19]). The media type registration process is
1470    outlined in RFC 1590 [17]. Use of non-registered media types is
1471    discouraged.
1472
1473 3.7.1 Canonicalization and Text Defaults
1474
1475    Internet media types are registered with a canonical form. An
1476    entity-body transferred via HTTP messages MUST be represented in the
1477    appropriate canonical form prior to its transmission except for
1478    "text" types, as defined in the next paragraph.
1479
1480    When in canonical form, media subtypes of the "text" type use CRLF as
1481    the text line break. HTTP relaxes this requirement and allows the
1482    transport of text media with plain CR or LF alone representing a line
1483    break when it is done consistently for an entire entity-body. HTTP
1484    applications MUST accept CRLF, bare CR, and bare LF as being
1485    representative of a line break in text media received via HTTP. In
1486    addition, if the text is represented in a character set that does not
1487    use octets 13 and 10 for CR and LF respectively, as is the case for
1488    some multi-byte character sets, HTTP allows the use of whatever octet
1489    sequences are defined by that character set to represent the
1490    equivalent of CR and LF for line breaks. This flexibility regarding
1491    line breaks applies only to text media in the entity-body; a bare CR
1492    or LF MUST NOT be substituted for CRLF within any of the HTTP control
1493    structures (such as header fields and multipart boundaries).
1494
1495    If an entity-body is encoded with a content-coding, the underlying
1496    data MUST be in a form defined above prior to being encoded.
1497
1498    The "charset" parameter is used with some media types to define the
1499    character set (section 3.4) of the data. When no explicit charset
1500    parameter is provided by the sender, media subtypes of the "text"
1501    type are defined to have a default charset value of "ISO-8859-1" when
1502    received via HTTP. Data in character sets other than "ISO-8859-1" or
1503    its subsets MUST be labeled with an appropriate charset value. See
1504    section 3.4.1 for compatibility problems.
1505
1506 3.7.2 Multipart Types
1507
1508    MIME provides for a number of "multipart" types -- encapsulations of
1509    one or more entities within a single message-body. All multipart
1510    types share a common syntax, as defined in section 5.1.1 of RFC 2046
1511
1512
1513
1514 Fielding, et al.            Standards Track                    [Page 27]
1515 \f
1516 RFC 2616                        HTTP/1.1                       June 1999
1517
1518
1519    [40], and MUST include a boundary parameter as part of the media type
1520    value. The message body is itself a protocol element and MUST
1521    therefore use only CRLF to represent line breaks between body-parts.
1522    Unlike in RFC 2046, the epilogue of any multipart message MUST be
1523    empty; HTTP applications MUST NOT transmit the epilogue (even if the
1524    original multipart contains an epilogue). These restrictions exist in
1525    order to preserve the self-delimiting nature of a multipart message-
1526    body, wherein the "end" of the message-body is indicated by the
1527    ending multipart boundary.
1528
1529    In general, HTTP treats a multipart message-body no differently than
1530    any other media type: strictly as payload. The one exception is the
1531    "multipart/byteranges" type (appendix 19.2) when it appears in a 206
1532    (Partial Content) response, which will be interpreted by some HTTP
1533    caching mechanisms as described in sections 13.5.4 and 14.16. In all
1534    other cases, an HTTP user agent SHOULD follow the same or similar
1535    behavior as a MIME user agent would upon receipt of a multipart type.
1536    The MIME header fields within each body-part of a multipart message-
1537    body do not have any significance to HTTP beyond that defined by
1538    their MIME semantics.
1539
1540    In general, an HTTP user agent SHOULD follow the same or similar
1541    behavior as a MIME user agent would upon receipt of a multipart type.
1542    If an application receives an unrecognized multipart subtype, the
1543    application MUST treat it as being equivalent to "multipart/mixed".
1544
1545       Note: The "multipart/form-data" type has been specifically defined
1546       for carrying form data suitable for processing via the POST
1547       request method, as described in RFC 1867 [15].
1548
1549 3.8 Product Tokens
1550
1551    Product tokens are used to allow communicating applications to
1552    identify themselves by software name and version. Most fields using
1553    product tokens also allow sub-products which form a significant part
1554    of the application to be listed, separated by white space. By
1555    convention, the products are listed in order of their significance
1556    for identifying the application.
1557
1558        product         = token ["/" product-version]
1559        product-version = token
1560
1561    Examples:
1562
1563        User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1564        Server: Apache/0.8.4
1565
1566
1567
1568
1569
1570 Fielding, et al.            Standards Track                    [Page 28]
1571 \f
1572 RFC 2616                        HTTP/1.1                       June 1999
1573
1574
1575    Product tokens SHOULD be short and to the point. They MUST NOT be
1576    used for advertising or other non-essential information. Although any
1577    token character MAY appear in a product-version, this token SHOULD
1578    only be used for a version identifier (i.e., successive versions of
1579    the same product SHOULD only differ in the product-version portion of
1580    the product value).
1581
1582 3.9 Quality Values
1583
1584    HTTP content negotiation (section 12) uses short "floating point"
1585    numbers to indicate the relative importance ("weight") of various
1586    negotiable parameters.  A weight is normalized to a real number in
1587    the range 0 through 1, where 0 is the minimum and 1 the maximum
1588    value. If a parameter has a quality value of 0, then content with
1589    this parameter is `not acceptable' for the client. HTTP/1.1
1590    applications MUST NOT generate more than three digits after the
1591    decimal point. User configuration of these values SHOULD also be
1592    limited in this fashion.
1593
1594        qvalue         = ( "0" [ "." 0*3DIGIT ] )
1595                       | ( "1" [ "." 0*3("0") ] )
1596
1597    "Quality values" is a misnomer, since these values merely represent
1598    relative degradation in desired quality.
1599
1600 3.10 Language Tags
1601
1602    A language tag identifies a natural language spoken, written, or
1603    otherwise conveyed by human beings for communication of information
1604    to other human beings. Computer languages are explicitly excluded.
1605    HTTP uses language tags within the Accept-Language and Content-
1606    Language fields.
1607
1608    The syntax and registry of HTTP language tags is the same as that
1609    defined by RFC 1766 [1]. In summary, a language tag is composed of 1
1610    or more parts: A primary language tag and a possibly empty series of
1611    subtags:
1612
1613         language-tag  = primary-tag *( "-" subtag )
1614         primary-tag   = 1*8ALPHA
1615         subtag        = 1*8ALPHA
1616
1617    White space is not allowed within the tag and all tags are case-
1618    insensitive. The name space of language tags is administered by the
1619    IANA. Example tags include:
1620
1621        en, en-US, en-cockney, i-cherokee, x-pig-latin
1622
1623
1624
1625
1626 Fielding, et al.            Standards Track                    [Page 29]
1627 \f
1628 RFC 2616                        HTTP/1.1                       June 1999
1629
1630
1631    where any two-letter primary-tag is an ISO-639 language abbreviation
1632    and any two-letter initial subtag is an ISO-3166 country code. (The
1633    last three tags above are not registered tags; all but the last are
1634    examples of tags which could be registered in future.)
1635
1636 3.11 Entity Tags
1637
1638    Entity tags are used for comparing two or more entities from the same
1639    requested resource. HTTP/1.1 uses entity tags in the ETag (section
1640    14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
1641    If-Range (section 14.27) header fields. The definition of how they
1642    are used and compared as cache validators is in section 13.3.3. An
1643    entity tag consists of an opaque quoted string, possibly prefixed by
1644    a weakness indicator.
1645
1646       entity-tag = [ weak ] opaque-tag
1647       weak       = "W/"
1648       opaque-tag = quoted-string
1649
1650    A "strong entity tag" MAY be shared by two entities of a resource
1651    only if they are equivalent by octet equality.
1652
1653    A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
1654    two entities of a resource only if the entities are equivalent and
1655    could be substituted for each other with no significant change in
1656    semantics. A weak entity tag can only be used for weak comparison.
1657
1658    An entity tag MUST be unique across all versions of all entities
1659    associated with a particular resource. A given entity tag value MAY
1660    be used for entities obtained by requests on different URIs. The use
1661    of the same entity tag value in conjunction with entities obtained by
1662    requests on different URIs does not imply the equivalence of those
1663    entities.
1664
1665 3.12 Range Units
1666
1667    HTTP/1.1 allows a client to request that only part (a range of) the
1668    response entity be included within the response. HTTP/1.1 uses range
1669    units in the Range (section 14.35) and Content-Range (section 14.16)
1670    header fields. An entity can be broken down into subranges according
1671    to various structural units.
1672
1673       range-unit       = bytes-unit | other-range-unit
1674       bytes-unit       = "bytes"
1675       other-range-unit = token
1676
1677    The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
1678    implementations MAY ignore ranges specified using other units.
1679
1680
1681
1682 Fielding, et al.            Standards Track                    [Page 30]
1683 \f
1684 RFC 2616                        HTTP/1.1                       June 1999
1685
1686
1687    HTTP/1.1 has been designed to allow implementations of applications
1688    that do not depend on knowledge of ranges.
1689
1690 4 HTTP Message
1691
1692 4.1 Message Types
1693
1694    HTTP messages consist of requests from client to server and responses
1695    from server to client.
1696
1697        HTTP-message   = Request | Response     ; HTTP/1.1 messages
1698
1699    Request (section 5) and Response (section 6) messages use the generic
1700    message format of RFC 822 [9] for transferring entities (the payload
1701    of the message). Both types of message consist of a start-line, zero
1702    or more header fields (also known as "headers"), an empty line (i.e.,
1703    a line with nothing preceding the CRLF) indicating the end of the
1704    header fields, and possibly a message-body.
1705
1706         generic-message = start-line
1707                           *(message-header CRLF)
1708                           CRLF
1709                           [ message-body ]
1710         start-line      = Request-Line | Status-Line
1711
1712    In the interest of robustness, servers SHOULD ignore any empty
1713    line(s) received where a Request-Line is expected. In other words, if
1714    the server is reading the protocol stream at the beginning of a
1715    message and receives a CRLF first, it should ignore the CRLF.
1716
1717    Certain buggy HTTP/1.0 client implementations generate extra CRLF's
1718    after a POST request. To restate what is explicitly forbidden by the
1719    BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
1720    extra CRLF.
1721
1722 4.2 Message Headers
1723
1724    HTTP header fields, which include general-header (section 4.5),
1725    request-header (section 5.3), response-header (section 6.2), and
1726    entity-header (section 7.1) fields, follow the same generic format as
1727    that given in Section 3.1 of RFC 822 [9]. Each header field consists
1728    of a name followed by a colon (":") and the field value. Field names
1729    are case-insensitive. The field value MAY be preceded by any amount
1730    of LWS, though a single SP is preferred. Header fields can be
1731    extended over multiple lines by preceding each extra line with at
1732    least one SP or HT. Applications ought to follow "common form", where
1733    one is known or indicated, when generating HTTP constructs, since
1734    there might exist some implementations that fail to accept anything
1735
1736
1737
1738 Fielding, et al.            Standards Track                    [Page 31]
1739 \f
1740 RFC 2616                        HTTP/1.1                       June 1999
1741
1742
1743    beyond the common forms.
1744
1745        message-header = field-name ":" [ field-value ]
1746        field-name     = token
1747        field-value    = *( field-content | LWS )
1748        field-content  = <the OCTETs making up the field-value
1749                         and consisting of either *TEXT or combinations
1750                         of token, separators, and quoted-string>
1751
1752    The field-content does not include any leading or trailing LWS:
1753    linear white space occurring before the first non-whitespace
1754    character of the field-value or after the last non-whitespace
1755    character of the field-value. Such leading or trailing LWS MAY be
1756    removed without changing the semantics of the field value. Any LWS
1757    that occurs between field-content MAY be replaced with a single SP
1758    before interpreting the field value or forwarding the message
1759    downstream.
1760
1761    The order in which header fields with differing field names are
1762    received is not significant. However, it is "good practice" to send
1763    general-header fields first, followed by request-header or response-
1764    header fields, and ending with the entity-header fields.
1765
1766    Multiple message-header fields with the same field-name MAY be
1767    present in a message if and only if the entire field-value for that
1768    header field is defined as a comma-separated list [i.e., #(values)].
1769    It MUST be possible to combine the multiple header fields into one
1770    "field-name: field-value" pair, without changing the semantics of the
1771    message, by appending each subsequent field-value to the first, each
1772    separated by a comma. The order in which header fields with the same
1773    field-name are received is therefore significant to the
1774    interpretation of the combined field value, and thus a proxy MUST NOT
1775    change the order of these field values when a message is forwarded.
1776
1777 4.3 Message Body
1778
1779    The message-body (if any) of an HTTP message is used to carry the
1780    entity-body associated with the request or response. The message-body
1781    differs from the entity-body only when a transfer-coding has been
1782    applied, as indicated by the Transfer-Encoding header field (section
1783    14.41).
1784
1785        message-body = entity-body
1786                     | <entity-body encoded as per Transfer-Encoding>
1787
1788    Transfer-Encoding MUST be used to indicate any transfer-codings
1789    applied by an application to ensure safe and proper transfer of the
1790    message. Transfer-Encoding is a property of the message, not of the
1791
1792
1793
1794 Fielding, et al.            Standards Track                    [Page 32]
1795 \f
1796 RFC 2616                        HTTP/1.1                       June 1999
1797
1798
1799    entity, and thus MAY be added or removed by any application along the
1800    request/response chain. (However, section 3.6 places restrictions on
1801    when certain transfer-codings may be used.)
1802
1803    The rules for when a message-body is allowed in a message differ for
1804    requests and responses.
1805
1806    The presence of a message-body in a request is signaled by the
1807    inclusion of a Content-Length or Transfer-Encoding header field in
1808    the request's message-headers. A message-body MUST NOT be included in
1809    a request if the specification of the request method (section 5.1.1)
1810    does not allow sending an entity-body in requests. A server SHOULD
1811    read and forward a message-body on any request; if the request method
1812    does not include defined semantics for an entity-body, then the
1813    message-body SHOULD be ignored when handling the request.
1814
1815    For response messages, whether or not a message-body is included with
1816    a message is dependent on both the request method and the response
1817    status code (section 6.1.1). All responses to the HEAD request method
1818    MUST NOT include a message-body, even though the presence of entity-
1819    header fields might lead one to believe they do. All 1xx
1820    (informational), 204 (no content), and 304 (not modified) responses
1821    MUST NOT include a message-body. All other responses do include a
1822    message-body, although it MAY be of zero length.
1823
1824 4.4 Message Length
1825
1826    The transfer-length of a message is the length of the message-body as
1827    it appears in the message; that is, after any transfer-codings have
1828    been applied. When a message-body is included with a message, the
1829    transfer-length of that body is determined by one of the following
1830    (in order of precedence):
1831
1832    1.Any response message which "MUST NOT" include a message-body (such
1833      as the 1xx, 204, and 304 responses and any response to a HEAD
1834      request) is always terminated by the first empty line after the
1835      header fields, regardless of the entity-header fields present in
1836      the message.
1837
1838    2.If a Transfer-Encoding header field (section 14.41) is present and
1839      has any value other than "identity", then the transfer-length is
1840      defined by use of the "chunked" transfer-coding (section 3.6),
1841      unless the message is terminated by closing the connection.
1842
1843    3.If a Content-Length header field (section 14.13) is present, its
1844      decimal value in OCTETs represents both the entity-length and the
1845      transfer-length. The Content-Length header field MUST NOT be sent
1846      if these two lengths are different (i.e., if a Transfer-Encoding
1847
1848
1849
1850 Fielding, et al.            Standards Track                    [Page 33]
1851 \f
1852 RFC 2616                        HTTP/1.1                       June 1999
1853
1854
1855      header field is present). If a message is received with both a
1856      Transfer-Encoding header field and a Content-Length header field,
1857      the latter MUST be ignored.
1858
1859    4.If the message uses the media type "multipart/byteranges", and the
1860      ransfer-length is not otherwise specified, then this self-
1861      elimiting media type defines the transfer-length. This media type
1862      UST NOT be used unless the sender knows that the recipient can arse
1863      it; the presence in a request of a Range header with ultiple byte-
1864      range specifiers from a 1.1 client implies that the lient can parse
1865      multipart/byteranges responses.
1866
1867        A range header might be forwarded by a 1.0 proxy that does not
1868        understand multipart/byteranges; in this case the server MUST
1869        delimit the message using methods defined in items 1,3 or 5 of
1870        this section.
1871
1872    5.By the server closing the connection. (Closing the connection
1873      cannot be used to indicate the end of a request body, since that
1874      would leave no possibility for the server to send back a response.)
1875
1876    For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
1877    containing a message-body MUST include a valid Content-Length header
1878    field unless the server is known to be HTTP/1.1 compliant. If a
1879    request contains a message-body and a Content-Length is not given,
1880    the server SHOULD respond with 400 (bad request) if it cannot
1881    determine the length of the message, or with 411 (length required) if
1882    it wishes to insist on receiving a valid Content-Length.
1883
1884    All HTTP/1.1 applications that receive entities MUST accept the
1885    "chunked" transfer-coding (section 3.6), thus allowing this mechanism
1886    to be used for messages when the message length cannot be determined
1887    in advance.
1888
1889    Messages MUST NOT include both a Content-Length header field and a
1890    non-identity transfer-coding. If the message does include a non-
1891    identity transfer-coding, the Content-Length MUST be ignored.
1892
1893    When a Content-Length is given in a message where a message-body is
1894    allowed, its field value MUST exactly match the number of OCTETs in
1895    the message-body. HTTP/1.1 user agents MUST notify the user when an
1896    invalid length is received and detected.
1897
1898 4.5 General Header Fields
1899
1900    There are a few header fields which have general applicability for
1901    both request and response messages, but which do not apply to the
1902    entity being transferred. These header fields apply only to the
1903
1904
1905
1906 Fielding, et al.            Standards Track                    [Page 34]
1907 \f
1908 RFC 2616                        HTTP/1.1                       June 1999
1909
1910
1911    message being transmitted.
1912
1913        general-header = Cache-Control            ; Section 14.9
1914                       | Connection               ; Section 14.10
1915                       | Date                     ; Section 14.18
1916                       | Pragma                   ; Section 14.32
1917                       | Trailer                  ; Section 14.40
1918                       | Transfer-Encoding        ; Section 14.41
1919                       | Upgrade                  ; Section 14.42
1920                       | Via                      ; Section 14.45
1921                       | Warning                  ; Section 14.46
1922
1923    General-header field names can be extended reliably only in
1924    combination with a change in the protocol version. However, new or
1925    experimental header fields may be given the semantics of general
1926    header fields if all parties in the communication recognize them to
1927    be general-header fields. Unrecognized header fields are treated as
1928    entity-header fields.
1929
1930 5 Request
1931
1932    A request message from a client to a server includes, within the
1933    first line of that message, the method to be applied to the resource,
1934    the identifier of the resource, and the protocol version in use.
1935
1936         Request       = Request-Line              ; Section 5.1
1937                         *(( general-header        ; Section 4.5
1938                          | request-header         ; Section 5.3
1939                          | entity-header ) CRLF)  ; Section 7.1
1940                         CRLF
1941                         [ message-body ]          ; Section 4.3
1942
1943 5.1 Request-Line
1944
1945    The Request-Line begins with a method token, followed by the
1946    Request-URI and the protocol version, and ending with CRLF. The
1947    elements are separated by SP characters. No CR or LF is allowed
1948    except in the final CRLF sequence.
1949
1950         Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Fielding, et al.            Standards Track                    [Page 35]
1963 \f
1964 RFC 2616                        HTTP/1.1                       June 1999
1965
1966
1967 5.1.1 Method
1968
1969    The Method  token indicates the method to be performed on the
1970    resource identified by the Request-URI. The method is case-sensitive.
1971
1972        Method         = "OPTIONS"                ; Section 9.2
1973                       | "GET"                    ; Section 9.3
1974                       | "HEAD"                   ; Section 9.4
1975                       | "POST"                   ; Section 9.5
1976                       | "PUT"                    ; Section 9.6
1977                       | "DELETE"                 ; Section 9.7
1978                       | "TRACE"                  ; Section 9.8
1979                       | "CONNECT"                ; Section 9.9
1980                       | extension-method
1981        extension-method = token
1982
1983    The list of methods allowed by a resource can be specified in an
1984    Allow header field (section 14.7). The return code of the response
1985    always notifies the client whether a method is currently allowed on a
1986    resource, since the set of allowed methods can change dynamically. An
1987    origin server SHOULD return the status code 405 (Method Not Allowed)
1988    if the method is known by the origin server but not allowed for the
1989    requested resource, and 501 (Not Implemented) if the method is
1990    unrecognized or not implemented by the origin server. The methods GET
1991    and HEAD MUST be supported by all general-purpose servers. All other
1992    methods are OPTIONAL; however, if the above methods are implemented,
1993    they MUST be implemented with the same semantics as those specified
1994    in section 9.
1995
1996 5.1.2 Request-URI
1997
1998    The Request-URI is a Uniform Resource Identifier (section 3.2) and
1999    identifies the resource upon which to apply the request.
2000
2001        Request-URI    = "*" | absoluteURI | abs_path | authority
2002
2003    The four options for Request-URI are dependent on the nature of the
2004    request. The asterisk "*" means that the request does not apply to a
2005    particular resource, but to the server itself, and is only allowed
2006    when the method used does not necessarily apply to a resource. One
2007    example would be
2008
2009        OPTIONS * HTTP/1.1
2010
2011    The absoluteURI form is REQUIRED when the request is being made to a
2012    proxy. The proxy is requested to forward the request or service it
2013    from a valid cache, and return the response. Note that the proxy MAY
2014    forward the request on to another proxy or directly to the server
2015
2016
2017
2018 Fielding, et al.            Standards Track                    [Page 36]
2019 \f
2020 RFC 2616                        HTTP/1.1                       June 1999
2021
2022
2023    specified by the absoluteURI. In order to avoid request loops, a
2024    proxy MUST be able to recognize all of its server names, including
2025    any aliases, local variations, and the numeric IP address. An example
2026    Request-Line would be:
2027
2028        GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
2029
2030    To allow for transition to absoluteURIs in all requests in future
2031    versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
2032    form in requests, even though HTTP/1.1 clients will only generate
2033    them in requests to proxies.
2034
2035    The authority form is only used by the CONNECT method (section 9.9).
2036
2037    The most common form of Request-URI is that used to identify a
2038    resource on an origin server or gateway. In this case the absolute
2039    path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
2040    the Request-URI, and the network location of the URI (authority) MUST
2041    be transmitted in a Host header field. For example, a client wishing
2042    to retrieve the resource above directly from the origin server would
2043    create a TCP connection to port 80 of the host "www.w3.org" and send
2044    the lines:
2045
2046        GET /pub/WWW/TheProject.html HTTP/1.1
2047        Host: www.w3.org
2048
2049    followed by the remainder of the Request. Note that the absolute path
2050    cannot be empty; if none is present in the original URI, it MUST be
2051    given as "/" (the server root).
2052
2053    The Request-URI is transmitted in the format specified in section
2054    3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
2055    [42], the origin server MUST decode the Request-URI in order to
2056    properly interpret the request. Servers SHOULD respond to invalid
2057    Request-URIs with an appropriate status code.
2058
2059    A transparent proxy MUST NOT rewrite the "abs_path" part of the
2060    received Request-URI when forwarding it to the next inbound server,
2061    except as noted above to replace a null abs_path with "/".
2062
2063       Note: The "no rewrite" rule prevents the proxy from changing the
2064       meaning of the request when the origin server is improperly using
2065       a non-reserved URI character for a reserved purpose.  Implementors
2066       should be aware that some pre-HTTP/1.1 proxies have been known to
2067       rewrite the Request-URI.
2068
2069
2070
2071
2072
2073
2074 Fielding, et al.            Standards Track                    [Page 37]
2075 \f
2076 RFC 2616                        HTTP/1.1                       June 1999
2077
2078
2079 5.2 The Resource Identified by a Request
2080
2081    The exact resource identified by an Internet request is determined by
2082    examining both the Request-URI and the Host header field.
2083
2084    An origin server that does not allow resources to differ by the
2085    requested host MAY ignore the Host header field value when
2086    determining the resource identified by an HTTP/1.1 request. (But see
2087    section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
2088
2089    An origin server that does differentiate resources based on the host
2090    requested (sometimes referred to as virtual hosts or vanity host
2091    names) MUST use the following rules for determining the requested
2092    resource on an HTTP/1.1 request:
2093
2094    1. If Request-URI is an absoluteURI, the host is part of the
2095      Request-URI. Any Host header field value in the request MUST be
2096      ignored.
2097
2098    2. If the Request-URI is not an absoluteURI, and the request includes
2099      a Host header field, the host is determined by the Host header
2100      field value.
2101
2102    3. If the host as determined by rule 1 or 2 is not a valid host on
2103      the server, the response MUST be a 400 (Bad Request) error message.
2104
2105    Recipients of an HTTP/1.0 request that lacks a Host header field MAY
2106    attempt to use heuristics (e.g., examination of the URI path for
2107    something unique to a particular host) in order to determine what
2108    exact resource is being requested.
2109
2110 5.3 Request Header Fields
2111
2112    The request-header fields allow the client to pass additional
2113    information about the request, and about the client itself, to the
2114    server. These fields act as request modifiers, with semantics
2115    equivalent to the parameters on a programming language method
2116    invocation.
2117
2118        request-header = Accept                   ; Section 14.1
2119                       | Accept-Charset           ; Section 14.2
2120                       | Accept-Encoding          ; Section 14.3
2121                       | Accept-Language          ; Section 14.4
2122                       | Authorization            ; Section 14.8
2123                       | Expect                   ; Section 14.20
2124                       | From                     ; Section 14.22
2125                       | Host                     ; Section 14.23
2126                       | If-Match                 ; Section 14.24
2127
2128
2129
2130 Fielding, et al.            Standards Track                    [Page 38]
2131 \f
2132 RFC 2616                        HTTP/1.1                       June 1999
2133
2134
2135                       | If-Modified-Since        ; Section 14.25
2136                       | If-None-Match            ; Section 14.26
2137                       | If-Range                 ; Section 14.27
2138                       | If-Unmodified-Since      ; Section 14.28
2139                       | Max-Forwards             ; Section 14.31
2140                       | Proxy-Authorization      ; Section 14.34
2141                       | Range                    ; Section 14.35
2142                       | Referer                  ; Section 14.36
2143                       | TE                       ; Section 14.39
2144                       | User-Agent               ; Section 14.43
2145
2146    Request-header field names can be extended reliably only in
2147    combination with a change in the protocol version. However, new or
2148    experimental header fields MAY be given the semantics of request-
2149    header fields if all parties in the communication recognize them to
2150    be request-header fields. Unrecognized header fields are treated as
2151    entity-header fields.
2152
2153 6 Response
2154
2155    After receiving and interpreting a request message, a server responds
2156    with an HTTP response message.
2157
2158        Response      = Status-Line               ; Section 6.1
2159                        *(( general-header        ; Section 4.5
2160                         | response-header        ; Section 6.2
2161                         | entity-header ) CRLF)  ; Section 7.1
2162                        CRLF
2163                        [ message-body ]          ; Section 7.2
2164
2165 6.1 Status-Line
2166
2167    The first line of a Response message is the Status-Line, consisting
2168    of the protocol version followed by a numeric status code and its
2169    associated textual phrase, with each element separated by SP
2170    characters. No CR or LF is allowed except in the final CRLF sequence.
2171
2172        Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
2173
2174 6.1.1 Status Code and Reason Phrase
2175
2176    The Status-Code element is a 3-digit integer result code of the
2177    attempt to understand and satisfy the request. These codes are fully
2178    defined in section 10. The Reason-Phrase is intended to give a short
2179    textual description of the Status-Code. The Status-Code is intended
2180    for use by automata and the Reason-Phrase is intended for the human
2181    user. The client is not required to examine or display the Reason-
2182    Phrase.
2183
2184
2185
2186 Fielding, et al.            Standards Track                    [Page 39]
2187 \f
2188 RFC 2616                        HTTP/1.1                       June 1999
2189
2190
2191    The first digit of the Status-Code defines the class of response. The
2192    last two digits do not have any categorization role. There are 5
2193    values for the first digit:
2194
2195       - 1xx: Informational - Request received, continuing process
2196
2197       - 2xx: Success - The action was successfully received,
2198         understood, and accepted
2199
2200       - 3xx: Redirection - Further action must be taken in order to
2201         complete the request
2202
2203       - 4xx: Client Error - The request contains bad syntax or cannot
2204         be fulfilled
2205
2206       - 5xx: Server Error - The server failed to fulfill an apparently
2207         valid request
2208
2209    The individual values of the numeric status codes defined for
2210    HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
2211    presented below. The reason phrases listed here are only
2212    recommendations -- they MAY be replaced by local equivalents without
2213    affecting the protocol.
2214
2215       Status-Code    =
2216             "100"  ; Section 10.1.1: Continue
2217           | "101"  ; Section 10.1.2: Switching Protocols
2218           | "200"  ; Section 10.2.1: OK
2219           | "201"  ; Section 10.2.2: Created
2220           | "202"  ; Section 10.2.3: Accepted
2221           | "203"  ; Section 10.2.4: Non-Authoritative Information
2222           | "204"  ; Section 10.2.5: No Content
2223           | "205"  ; Section 10.2.6: Reset Content
2224           | "206"  ; Section 10.2.7: Partial Content
2225           | "300"  ; Section 10.3.1: Multiple Choices
2226           | "301"  ; Section 10.3.2: Moved Permanently
2227           | "302"  ; Section 10.3.3: Found
2228           | "303"  ; Section 10.3.4: See Other
2229           | "304"  ; Section 10.3.5: Not Modified
2230           | "305"  ; Section 10.3.6: Use Proxy
2231           | "307"  ; Section 10.3.8: Temporary Redirect
2232           | "400"  ; Section 10.4.1: Bad Request
2233           | "401"  ; Section 10.4.2: Unauthorized
2234           | "402"  ; Section 10.4.3: Payment Required
2235           | "403"  ; Section 10.4.4: Forbidden
2236           | "404"  ; Section 10.4.5: Not Found
2237           | "405"  ; Section 10.4.6: Method Not Allowed
2238           | "406"  ; Section 10.4.7: Not Acceptable
2239
2240
2241
2242 Fielding, et al.            Standards Track                    [Page 40]
2243 \f
2244 RFC 2616                        HTTP/1.1                       June 1999
2245
2246
2247           | "407"  ; Section 10.4.8: Proxy Authentication Required
2248           | "408"  ; Section 10.4.9: Request Time-out
2249           | "409"  ; Section 10.4.10: Conflict
2250           | "410"  ; Section 10.4.11: Gone
2251           | "411"  ; Section 10.4.12: Length Required
2252           | "412"  ; Section 10.4.13: Precondition Failed
2253           | "413"  ; Section 10.4.14: Request Entity Too Large
2254           | "414"  ; Section 10.4.15: Request-URI Too Large
2255           | "415"  ; Section 10.4.16: Unsupported Media Type
2256           | "416"  ; Section 10.4.17: Requested range not satisfiable
2257           | "417"  ; Section 10.4.18: Expectation Failed
2258           | "500"  ; Section 10.5.1: Internal Server Error
2259           | "501"  ; Section 10.5.2: Not Implemented
2260           | "502"  ; Section 10.5.3: Bad Gateway
2261           | "503"  ; Section 10.5.4: Service Unavailable
2262           | "504"  ; Section 10.5.5: Gateway Time-out
2263           | "505"  ; Section 10.5.6: HTTP Version not supported
2264           | extension-code
2265
2266       extension-code = 3DIGIT
2267       Reason-Phrase  = *<TEXT, excluding CR, LF>
2268
2269    HTTP status codes are extensible. HTTP applications are not required
2270    to understand the meaning of all registered status codes, though such
2271    understanding is obviously desirable. However, applications MUST
2272    understand the class of any status code, as indicated by the first
2273    digit, and treat any unrecognized response as being equivalent to the
2274    x00 status code of that class, with the exception that an
2275    unrecognized response MUST NOT be cached. For example, if an
2276    unrecognized status code of 431 is received by the client, it can
2277    safely assume that there was something wrong with its request and
2278    treat the response as if it had received a 400 status code. In such
2279    cases, user agents SHOULD present to the user the entity returned
2280    with the response, since that entity is likely to include human-
2281    readable information which will explain the unusual status.
2282
2283 6.2 Response Header Fields
2284
2285    The response-header fields allow the server to pass additional
2286    information about the response which cannot be placed in the Status-
2287    Line. These header fields give information about the server and about
2288    further access to the resource identified by the Request-URI.
2289
2290        response-header = Accept-Ranges           ; Section 14.5
2291                        | Age                     ; Section 14.6
2292                        | ETag                    ; Section 14.19
2293                        | Location                ; Section 14.30
2294                        | Proxy-Authenticate      ; Section 14.33
2295
2296
2297
2298 Fielding, et al.            Standards Track                    [Page 41]
2299 \f
2300 RFC 2616                        HTTP/1.1                       June 1999
2301
2302
2303                        | Retry-After             ; Section 14.37
2304                        | Server                  ; Section 14.38
2305                        | Vary                    ; Section 14.44
2306                        | WWW-Authenticate        ; Section 14.47
2307
2308    Response-header field names can be extended reliably only in
2309    combination with a change in the protocol version. However, new or
2310    experimental header fields MAY be given the semantics of response-
2311    header fields if all parties in the communication recognize them to
2312    be response-header fields. Unrecognized header fields are treated as
2313    entity-header fields.
2314
2315 7 Entity
2316
2317    Request and Response messages MAY transfer an entity if not otherwise
2318    restricted by the request method or response status code. An entity
2319    consists of entity-header fields and an entity-body, although some
2320    responses will only include the entity-headers.
2321
2322    In this section, both sender and recipient refer to either the client
2323    or the server, depending on who sends and who receives the entity.
2324
2325 7.1 Entity Header Fields
2326
2327    Entity-header fields define metainformation about the entity-body or,
2328    if no body is present, about the resource identified by the request.
2329    Some of this metainformation is OPTIONAL; some might be REQUIRED by
2330    portions of this specification.
2331
2332        entity-header  = Allow                    ; Section 14.7
2333                       | Content-Encoding         ; Section 14.11
2334                       | Content-Language         ; Section 14.12
2335                       | Content-Length           ; Section 14.13
2336                       | Content-Location         ; Section 14.14
2337                       | Content-MD5              ; Section 14.15
2338                       | Content-Range            ; Section 14.16
2339                       | Content-Type             ; Section 14.17
2340                       | Expires                  ; Section 14.21
2341                       | Last-Modified            ; Section 14.29
2342                       | extension-header
2343
2344        extension-header = message-header
2345
2346    The extension-header mechanism allows additional entity-header fields
2347    to be defined without changing the protocol, but these fields cannot
2348    be assumed to be recognizable by the recipient. Unrecognized header
2349    fields SHOULD be ignored by the recipient and MUST be forwarded by
2350    transparent proxies.
2351
2352
2353
2354 Fielding, et al.            Standards Track                    [Page 42]
2355 \f
2356 RFC 2616                        HTTP/1.1                       June 1999
2357
2358
2359 7.2 Entity Body
2360
2361    The entity-body (if any) sent with an HTTP request or response is in
2362    a format and encoding defined by the entity-header fields.
2363
2364        entity-body    = *OCTET
2365
2366    An entity-body is only present in a message when a message-body is
2367    present, as described in section 4.3. The entity-body is obtained
2368    from the message-body by decoding any Transfer-Encoding that might
2369    have been applied to ensure safe and proper transfer of the message.
2370
2371 7.2.1 Type
2372
2373    When an entity-body is included with a message, the data type of that
2374    body is determined via the header fields Content-Type and Content-
2375    Encoding. These define a two-layer, ordered encoding model:
2376
2377        entity-body := Content-Encoding( Content-Type( data ) )
2378
2379    Content-Type specifies the media type of the underlying data.
2380    Content-Encoding may be used to indicate any additional content
2381    codings applied to the data, usually for the purpose of data
2382    compression, that are a property of the requested resource. There is
2383    no default encoding.
2384
2385    Any HTTP/1.1 message containing an entity-body SHOULD include a
2386    Content-Type header field defining the media type of that body. If
2387    and only if the media type is not given by a Content-Type field, the
2388    recipient MAY attempt to guess the media type via inspection of its
2389    content and/or the name extension(s) of the URI used to identify the
2390    resource. If the media type remains unknown, the recipient SHOULD
2391    treat it as type "application/octet-stream".
2392
2393 7.2.2 Entity Length
2394
2395    The entity-length of a message is the length of the message-body
2396    before any transfer-codings have been applied. Section 4.4 defines
2397    how the transfer-length of a message-body is determined.
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410 Fielding, et al.            Standards Track                    [Page 43]
2411 \f
2412 RFC 2616                        HTTP/1.1                       June 1999
2413
2414
2415 8 Connections
2416
2417 8.1 Persistent Connections
2418
2419 8.1.1 Purpose
2420
2421    Prior to persistent connections, a separate TCP connection was
2422    established to fetch each URL, increasing the load on HTTP servers
2423    and causing congestion on the Internet. The use of inline images and
2424    other associated data often require a client to make multiple
2425    requests of the same server in a short amount of time. Analysis of
2426    these performance problems and results from a prototype
2427    implementation are available [26] [30]. Implementation experience and
2428    measurements of actual HTTP/1.1 (RFC 2068) implementations show good
2429    results [39]. Alternatives have also been explored, for example,
2430    T/TCP [27].
2431
2432    Persistent HTTP connections have a number of advantages:
2433
2434       - By opening and closing fewer TCP connections, CPU time is saved
2435         in routers and hosts (clients, servers, proxies, gateways,
2436         tunnels, or caches), and memory used for TCP protocol control
2437         blocks can be saved in hosts.
2438
2439       - HTTP requests and responses can be pipelined on a connection.
2440         Pipelining allows a client to make multiple requests without
2441         waiting for each response, allowing a single TCP connection to
2442         be used much more efficiently, with much lower elapsed time.
2443
2444       - Network congestion is reduced by reducing the number of packets
2445         caused by TCP opens, and by allowing TCP sufficient time to
2446         determine the congestion state of the network.
2447
2448       - Latency on subsequent requests is reduced since there is no time
2449         spent in TCP's connection opening handshake.
2450
2451       - HTTP can evolve more gracefully, since errors can be reported
2452         without the penalty of closing the TCP connection. Clients using
2453         future versions of HTTP might optimistically try a new feature,
2454         but if communicating with an older server, retry with old
2455         semantics after an error is reported.
2456
2457    HTTP implementations SHOULD implement persistent connections.
2458
2459
2460
2461
2462
2463
2464
2465
2466 Fielding, et al.            Standards Track                    [Page 44]
2467 \f
2468 RFC 2616                        HTTP/1.1                       June 1999
2469
2470
2471 8.1.2 Overall Operation
2472
2473    A significant difference between HTTP/1.1 and earlier versions of
2474    HTTP is that persistent connections are the default behavior of any
2475    HTTP connection. That is, unless otherwise indicated, the client
2476    SHOULD assume that the server will maintain a persistent connection,
2477    even after error responses from the server.
2478
2479    Persistent connections provide a mechanism by which a client and a
2480    server can signal the close of a TCP connection. This signaling takes
2481    place using the Connection header field (section 14.10). Once a close
2482    has been signaled, the client MUST NOT send any more requests on that
2483    connection.
2484
2485 8.1.2.1 Negotiation
2486
2487    An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
2488    maintain a persistent connection unless a Connection header including
2489    the connection-token "close" was sent in the request. If the server
2490    chooses to close the connection immediately after sending the
2491    response, it SHOULD send a Connection header including the
2492    connection-token close.
2493
2494    An HTTP/1.1 client MAY expect a connection to remain open, but would
2495    decide to keep it open based on whether the response from a server
2496    contains a Connection header with the connection-token close. In case
2497    the client does not want to maintain a connection for more than that
2498    request, it SHOULD send a Connection header including the
2499    connection-token close.
2500
2501    If either the client or the server sends the close token in the
2502    Connection header, that request becomes the last one for the
2503    connection.
2504
2505    Clients and servers SHOULD NOT assume that a persistent connection is
2506    maintained for HTTP versions less than 1.1 unless it is explicitly
2507    signaled. See section 19.6.2 for more information on backward
2508    compatibility with HTTP/1.0 clients.
2509
2510    In order to remain persistent, all messages on the connection MUST
2511    have a self-defined message length (i.e., one not defined by closure
2512    of the connection), as described in section 4.4.
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522 Fielding, et al.            Standards Track                    [Page 45]
2523 \f
2524 RFC 2616                        HTTP/1.1                       June 1999
2525
2526
2527 8.1.2.2 Pipelining
2528
2529    A client that supports persistent connections MAY "pipeline" its
2530    requests (i.e., send multiple requests without waiting for each
2531    response). A server MUST send its responses to those requests in the
2532    same order that the requests were received.
2533
2534    Clients which assume persistent connections and pipeline immediately
2535    after connection establishment SHOULD be prepared to retry their
2536    connection if the first pipelined attempt fails. If a client does
2537    such a retry, it MUST NOT pipeline before it knows the connection is
2538    persistent. Clients MUST also be prepared to resend their requests if
2539    the server closes the connection before sending all of the
2540    corresponding responses.
2541
2542    Clients SHOULD NOT pipeline requests using non-idempotent methods or
2543    non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
2544    premature termination of the transport connection could lead to
2545    indeterminate results. A client wishing to send a non-idempotent
2546    request SHOULD wait to send that request until it has received the
2547    response status for the previous request.
2548
2549 8.1.3 Proxy Servers
2550
2551    It is especially important that proxies correctly implement the
2552    properties of the Connection header field as specified in section
2553    14.10.
2554
2555    The proxy server MUST signal persistent connections separately with
2556    its clients and the origin servers (or other proxy servers) that it
2557    connects to. Each persistent connection applies to only one transport
2558    link.
2559
2560    A proxy server MUST NOT establish a HTTP/1.1 persistent connection
2561    with an HTTP/1.0 client (but see RFC 2068 [33] for information and
2562    discussion of the problems with the Keep-Alive header implemented by
2563    many HTTP/1.0 clients).
2564
2565 8.1.4 Practical Considerations
2566
2567    Servers will usually have some time-out value beyond which they will
2568    no longer maintain an inactive connection. Proxy servers might make
2569    this a higher value since it is likely that the client will be making
2570    more connections through the same server. The use of persistent
2571    connections places no requirements on the length (or existence) of
2572    this time-out for either the client or the server.
2573
2574
2575
2576
2577
2578 Fielding, et al.            Standards Track                    [Page 46]
2579 \f
2580 RFC 2616                        HTTP/1.1                       June 1999
2581
2582
2583    When a client or server wishes to time-out it SHOULD issue a graceful
2584    close on the transport connection. Clients and servers SHOULD both
2585    constantly watch for the other side of the transport close, and
2586    respond to it as appropriate. If a client or server does not detect
2587    the other side's close promptly it could cause unnecessary resource
2588    drain on the network.
2589
2590    A client, server, or proxy MAY close the transport connection at any
2591    time. For example, a client might have started to send a new request
2592    at the same time that the server has decided to close the "idle"
2593    connection. From the server's point of view, the connection is being
2594    closed while it was idle, but from the client's point of view, a
2595    request is in progress.
2596
2597    This means that clients, servers, and proxies MUST be able to recover
2598    from asynchronous close events. Client software SHOULD reopen the
2599    transport connection and retransmit the aborted sequence of requests
2600    without user interaction so long as the request sequence is
2601    idempotent (see section 9.1.2). Non-idempotent methods or sequences
2602    MUST NOT be automatically retried, although user agents MAY offer a
2603    human operator the choice of retrying the request(s). Confirmation by
2604    user-agent software with semantic understanding of the application
2605    MAY substitute for user confirmation. The automatic retry SHOULD NOT
2606    be repeated if the second sequence of requests fails.
2607
2608    Servers SHOULD always respond to at least one request per connection,
2609    if at all possible. Servers SHOULD NOT close a connection in the
2610    middle of transmitting a response, unless a network or client failure
2611    is suspected.
2612
2613    Clients that use persistent connections SHOULD limit the number of
2614    simultaneous connections that they maintain to a given server. A
2615    single-user client SHOULD NOT maintain more than 2 connections with
2616    any server or proxy. A proxy SHOULD use up to 2*N connections to
2617    another server or proxy, where N is the number of simultaneously
2618    active users. These guidelines are intended to improve HTTP response
2619    times and avoid congestion.
2620
2621 8.2 Message Transmission Requirements
2622
2623 8.2.1 Persistent Connections and Flow Control
2624
2625    HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
2626    flow control mechanisms to resolve temporary overloads, rather than
2627    terminating connections with the expectation that clients will retry.
2628    The latter technique can exacerbate network congestion.
2629
2630
2631
2632
2633
2634 Fielding, et al.            Standards Track                    [Page 47]
2635 \f
2636 RFC 2616                        HTTP/1.1                       June 1999
2637
2638
2639 8.2.2 Monitoring Connections for Error Status Messages
2640
2641    An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
2642    the network connection for an error status while it is transmitting
2643    the request. If the client sees an error status, it SHOULD
2644    immediately cease transmitting the body. If the body is being sent
2645    using a "chunked" encoding (section 3.6), a zero length chunk and
2646    empty trailer MAY be used to prematurely mark the end of the message.
2647    If the body was preceded by a Content-Length header, the client MUST
2648    close the connection.
2649
2650 8.2.3 Use of the 100 (Continue) Status
2651
2652    The purpose of the 100 (Continue) status (see section 10.1.1) is to
2653    allow a client that is sending a request message with a request body
2654    to determine if the origin server is willing to accept the request
2655    (based on the request headers) before the client sends the request
2656    body. In some cases, it might either be inappropriate or highly
2657    inefficient for the client to send the body if the server will reject
2658    the message without looking at the body.
2659
2660    Requirements for HTTP/1.1 clients:
2661
2662       - If a client will wait for a 100 (Continue) response before
2663         sending the request body, it MUST send an Expect request-header
2664         field (section 14.20) with the "100-continue" expectation.
2665
2666       - A client MUST NOT send an Expect request-header field (section
2667         14.20) with the "100-continue" expectation if it does not intend
2668         to send a request body.
2669
2670    Because of the presence of older implementations, the protocol allows
2671    ambiguous situations in which a client may send "Expect: 100-
2672    continue" without receiving either a 417 (Expectation Failed) status
2673    or a 100 (Continue) status. Therefore, when a client sends this
2674    header field to an origin server (possibly via a proxy) from which it
2675    has never seen a 100 (Continue) status, the client SHOULD NOT wait
2676    for an indefinite period before sending the request body.
2677
2678    Requirements for HTTP/1.1 origin servers:
2679
2680       - Upon receiving a request which includes an Expect request-header
2681         field with the "100-continue" expectation, an origin server MUST
2682         either respond with 100 (Continue) status and continue to read
2683         from the input stream, or respond with a final status code. The
2684         origin server MUST NOT wait for the request body before sending
2685         the 100 (Continue) response. If it responds with a final status
2686         code, it MAY close the transport connection or it MAY continue
2687
2688
2689
2690 Fielding, et al.            Standards Track                    [Page 48]
2691 \f
2692 RFC 2616                        HTTP/1.1                       June 1999
2693
2694
2695         to read and discard the rest of the request.  It MUST NOT
2696         perform the requested method if it returns a final status code.
2697
2698       - An origin server SHOULD NOT send a 100 (Continue) response if
2699         the request message does not include an Expect request-header
2700         field with the "100-continue" expectation, and MUST NOT send a
2701         100 (Continue) response if such a request comes from an HTTP/1.0
2702         (or earlier) client. There is an exception to this rule: for
2703         compatibility with RFC 2068, a server MAY send a 100 (Continue)
2704         status in response to an HTTP/1.1 PUT or POST request that does
2705         not include an Expect request-header field with the "100-
2706         continue" expectation. This exception, the purpose of which is
2707         to minimize any client processing delays associated with an
2708         undeclared wait for 100 (Continue) status, applies only to
2709         HTTP/1.1 requests, and not to requests with any other HTTP-
2710         version value.
2711
2712       - An origin server MAY omit a 100 (Continue) response if it has
2713         already received some or all of the request body for the
2714         corresponding request.
2715
2716       - An origin server that sends a 100 (Continue) response MUST
2717         ultimately send a final status code, once the request body is
2718         received and processed, unless it terminates the transport
2719         connection prematurely.
2720
2721       - If an origin server receives a request that does not include an
2722         Expect request-header field with the "100-continue" expectation,
2723         the request includes a request body, and the server responds
2724         with a final status code before reading the entire request body
2725         from the transport connection, then the server SHOULD NOT close
2726         the transport connection until it has read the entire request,
2727         or until the client closes the connection. Otherwise, the client
2728         might not reliably receive the response message. However, this
2729         requirement is not be construed as preventing a server from
2730         defending itself against denial-of-service attacks, or from
2731         badly broken client implementations.
2732
2733    Requirements for HTTP/1.1 proxies:
2734
2735       - If a proxy receives a request that includes an Expect request-
2736         header field with the "100-continue" expectation, and the proxy
2737         either knows that the next-hop server complies with HTTP/1.1 or
2738         higher, or does not know the HTTP version of the next-hop
2739         server, it MUST forward the request, including the Expect header
2740         field.
2741
2742
2743
2744
2745
2746 Fielding, et al.            Standards Track                    [Page 49]
2747 \f
2748 RFC 2616                        HTTP/1.1                       June 1999
2749
2750
2751       - If the proxy knows that the version of the next-hop server is
2752         HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2753         respond with a 417 (Expectation Failed) status.
2754
2755       - Proxies SHOULD maintain a cache recording the HTTP version
2756         numbers received from recently-referenced next-hop servers.
2757
2758       - A proxy MUST NOT forward a 100 (Continue) response if the
2759         request message was received from an HTTP/1.0 (or earlier)
2760         client and did not include an Expect request-header field with
2761         the "100-continue" expectation. This requirement overrides the
2762         general rule for forwarding of 1xx responses (see section 10.1).
2763
2764 8.2.4 Client Behavior if Server Prematurely Closes Connection
2765
2766    If an HTTP/1.1 client sends a request which includes a request body,
2767    but which does not include an Expect request-header field with the
2768    "100-continue" expectation, and if the client is not directly
2769    connected to an HTTP/1.1 origin server, and if the client sees the
2770    connection close before receiving any status from the server, the
2771    client SHOULD retry the request.  If the client does retry this
2772    request, it MAY use the following "binary exponential backoff"
2773    algorithm to be assured of obtaining a reliable response:
2774
2775       1. Initiate a new connection to the server
2776
2777       2. Transmit the request-headers
2778
2779       3. Initialize a variable R to the estimated round-trip time to the
2780          server (e.g., based on the time it took to establish the
2781          connection), or to a constant value of 5 seconds if the round-
2782          trip time is not available.
2783
2784       4. Compute T = R * (2**N), where N is the number of previous
2785          retries of this request.
2786
2787       5. Wait either for an error response from the server, or for T
2788          seconds (whichever comes first)
2789
2790       6. If no error response is received, after T seconds transmit the
2791          body of the request.
2792
2793       7. If client sees that the connection is closed prematurely,
2794          repeat from step 1 until the request is accepted, an error
2795          response is received, or the user becomes impatient and
2796          terminates the retry process.
2797
2798
2799
2800
2801
2802 Fielding, et al.            Standards Track                    [Page 50]
2803 \f
2804 RFC 2616                        HTTP/1.1                       June 1999
2805
2806
2807    If at any point an error status is received, the client
2808
2809       - SHOULD NOT continue and
2810
2811       - SHOULD close the connection if it has not completed sending the
2812         request message.
2813
2814 9 Method Definitions
2815
2816    The set of common methods for HTTP/1.1 is defined below. Although
2817    this set can be expanded, additional methods cannot be assumed to
2818    share the same semantics for separately extended clients and servers.
2819
2820    The Host request-header field (section 14.23) MUST accompany all
2821    HTTP/1.1 requests.
2822
2823 9.1 Safe and Idempotent Methods
2824
2825 9.1.1 Safe Methods
2826
2827    Implementors should be aware that the software represents the user in
2828    their interactions over the Internet, and should be careful to allow
2829    the user to be aware of any actions they might take which may have an
2830    unexpected significance to themselves or others.
2831
2832    In particular, the convention has been established that the GET and
2833    HEAD methods SHOULD NOT have the significance of taking an action
2834    other than retrieval. These methods ought to be considered "safe".
2835    This allows user agents to represent other methods, such as POST, PUT
2836    and DELETE, in a special way, so that the user is made aware of the
2837    fact that a possibly unsafe action is being requested.
2838
2839    Naturally, it is not possible to ensure that the server does not
2840    generate side-effects as a result of performing a GET request; in
2841    fact, some dynamic resources consider that a feature. The important
2842    distinction here is that the user did not request the side-effects,
2843    so therefore cannot be held accountable for them.
2844
2845 9.1.2 Idempotent Methods
2846
2847    Methods can also have the property of "idempotence" in that (aside
2848    from error or expiration issues) the side-effects of N > 0 identical
2849    requests is the same as for a single request. The methods GET, HEAD,
2850    PUT and DELETE share this property. Also, the methods OPTIONS and
2851    TRACE SHOULD NOT have side effects, and so are inherently idempotent.
2852
2853
2854
2855
2856
2857
2858 Fielding, et al.            Standards Track                    [Page 51]
2859 \f
2860 RFC 2616                        HTTP/1.1                       June 1999
2861
2862
2863    However, it is possible that a sequence of several requests is non-
2864    idempotent, even if all of the methods executed in that sequence are
2865    idempotent. (A sequence is idempotent if a single execution of the
2866    entire sequence always yields a result that is not changed by a
2867    reexecution of all, or part, of that sequence.) For example, a
2868    sequence is non-idempotent if its result depends on a value that is
2869    later modified in the same sequence.
2870
2871    A sequence that never has side effects is idempotent, by definition
2872    (provided that no concurrent operations are being executed on the
2873    same set of resources).
2874
2875 9.2 OPTIONS
2876
2877    The OPTIONS method represents a request for information about the
2878    communication options available on the request/response chain
2879    identified by the Request-URI. This method allows the client to
2880    determine the options and/or requirements associated with a resource,
2881    or the capabilities of a server, without implying a resource action
2882    or initiating a resource retrieval.
2883
2884    Responses to this method are not cacheable.
2885
2886    If the OPTIONS request includes an entity-body (as indicated by the
2887    presence of Content-Length or Transfer-Encoding), then the media type
2888    MUST be indicated by a Content-Type field. Although this
2889    specification does not define any use for such a body, future
2890    extensions to HTTP might use the OPTIONS body to make more detailed
2891    queries on the server. A server that does not support such an
2892    extension MAY discard the request body.
2893
2894    If the Request-URI is an asterisk ("*"), the OPTIONS request is
2895    intended to apply to the server in general rather than to a specific
2896    resource. Since a server's communication options typically depend on
2897    the resource, the "*" request is only useful as a "ping" or "no-op"
2898    type of method; it does nothing beyond allowing the client to test
2899    the capabilities of the server. For example, this can be used to test
2900    a proxy for HTTP/1.1 compliance (or lack thereof).
2901
2902    If the Request-URI is not an asterisk, the OPTIONS request applies
2903    only to the options that are available when communicating with that
2904    resource.
2905
2906    A 200 response SHOULD include any header fields that indicate
2907    optional features implemented by the server and applicable to that
2908    resource (e.g., Allow), possibly including extensions not defined by
2909    this specification. The response body, if any, SHOULD also include
2910    information about the communication options. The format for such a
2911
2912
2913
2914 Fielding, et al.            Standards Track                    [Page 52]
2915 \f
2916 RFC 2616                        HTTP/1.1                       June 1999
2917
2918
2919    body is not defined by this specification, but might be defined by
2920    future extensions to HTTP. Content negotiation MAY be used to select
2921    the appropriate response format. If no response body is included, the
2922    response MUST include a Content-Length field with a field-value of
2923    "0".
2924
2925    The Max-Forwards request-header field MAY be used to target a
2926    specific proxy in the request chain. When a proxy receives an OPTIONS
2927    request on an absoluteURI for which request forwarding is permitted,
2928    the proxy MUST check for a Max-Forwards field. If the Max-Forwards
2929    field-value is zero ("0"), the proxy MUST NOT forward the message;
2930    instead, the proxy SHOULD respond with its own communication options.
2931    If the Max-Forwards field-value is an integer greater than zero, the
2932    proxy MUST decrement the field-value when it forwards the request. If
2933    no Max-Forwards field is present in the request, then the forwarded
2934    request MUST NOT include a Max-Forwards field.
2935
2936 9.3 GET
2937
2938    The GET method means retrieve whatever information (in the form of an
2939    entity) is identified by the Request-URI. If the Request-URI refers
2940    to a data-producing process, it is the produced data which shall be
2941    returned as the entity in the response and not the source text of the
2942    process, unless that text happens to be the output of the process.
2943
2944    The semantics of the GET method change to a "conditional GET" if the
2945    request message includes an If-Modified-Since, If-Unmodified-Since,
2946    If-Match, If-None-Match, or If-Range header field. A conditional GET
2947    method requests that the entity be transferred only under the
2948    circumstances described by the conditional header field(s). The
2949    conditional GET method is intended to reduce unnecessary network
2950    usage by allowing cached entities to be refreshed without requiring
2951    multiple requests or transferring data already held by the client.
2952
2953    The semantics of the GET method change to a "partial GET" if the
2954    request message includes a Range header field. A partial GET requests
2955    that only part of the entity be transferred, as described in section
2956    14.35. The partial GET method is intended to reduce unnecessary
2957    network usage by allowing partially-retrieved entities to be
2958    completed without transferring data already held by the client.
2959
2960    The response to a GET request is cacheable if and only if it meets
2961    the requirements for HTTP caching described in section 13.
2962
2963    See section 15.1.3 for security considerations when used for forms.
2964
2965
2966
2967
2968
2969
2970 Fielding, et al.            Standards Track                    [Page 53]
2971 \f
2972 RFC 2616                        HTTP/1.1                       June 1999
2973
2974
2975 9.4 HEAD
2976
2977    The HEAD method is identical to GET except that the server MUST NOT
2978    return a message-body in the response. The metainformation contained
2979    in the HTTP headers in response to a HEAD request SHOULD be identical
2980    to the information sent in response to a GET request. This method can
2981    be used for obtaining metainformation about the entity implied by the
2982    request without transferring the entity-body itself. This method is
2983    often used for testing hypertext links for validity, accessibility,
2984    and recent modification.
2985
2986    The response to a HEAD request MAY be cacheable in the sense that the
2987    information contained in the response MAY be used to update a
2988    previously cached entity from that resource. If the new field values
2989    indicate that the cached entity differs from the current entity (as
2990    would be indicated by a change in Content-Length, Content-MD5, ETag
2991    or Last-Modified), then the cache MUST treat the cache entry as
2992    stale.
2993
2994 9.5 POST
2995
2996    The POST method is used to request that the origin server accept the
2997    entity enclosed in the request as a new subordinate of the resource
2998    identified by the Request-URI in the Request-Line. POST is designed
2999    to allow a uniform method to cover the following functions:
3000
3001       - Annotation of existing resources;
3002
3003       - Posting a message to a bulletin board, newsgroup, mailing list,
3004         or similar group of articles;
3005
3006       - Providing a block of data, such as the result of submitting a
3007         form, to a data-handling process;
3008
3009       - Extending a database through an append operation.
3010
3011    The actual function performed by the POST method is determined by the
3012    server and is usually dependent on the Request-URI. The posted entity
3013    is subordinate to that URI in the same way that a file is subordinate
3014    to a directory containing it, a news article is subordinate to a
3015    newsgroup to which it is posted, or a record is subordinate to a
3016    database.
3017
3018    The action performed by the POST method might not result in a
3019    resource that can be identified by a URI. In this case, either 200
3020    (OK) or 204 (No Content) is the appropriate response status,
3021    depending on whether or not the response includes an entity that
3022    describes the result.
3023
3024
3025
3026 Fielding, et al.            Standards Track                    [Page 54]
3027 \f
3028 RFC 2616                        HTTP/1.1                       June 1999
3029
3030
3031    If a resource has been created on the origin server, the response
3032    SHOULD be 201 (Created) and contain an entity which describes the
3033    status of the request and refers to the new resource, and a Location
3034    header (see section 14.30).
3035
3036    Responses to this method are not cacheable, unless the response
3037    includes appropriate Cache-Control or Expires header fields. However,
3038    the 303 (See Other) response can be used to direct the user agent to
3039    retrieve a cacheable resource.
3040
3041    POST requests MUST obey the message transmission requirements set out
3042    in section 8.2.
3043
3044    See section 15.1.3 for security considerations.
3045
3046 9.6 PUT
3047
3048    The PUT method requests that the enclosed entity be stored under the
3049    supplied Request-URI. If the Request-URI refers to an already
3050    existing resource, the enclosed entity SHOULD be considered as a
3051    modified version of the one residing on the origin server. If the
3052    Request-URI does not point to an existing resource, and that URI is
3053    capable of being defined as a new resource by the requesting user
3054    agent, the origin server can create the resource with that URI. If a
3055    new resource is created, the origin server MUST inform the user agent
3056    via the 201 (Created) response. If an existing resource is modified,
3057    either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
3058    to indicate successful completion of the request. If the resource
3059    could not be created or modified with the Request-URI, an appropriate
3060    error response SHOULD be given that reflects the nature of the
3061    problem. The recipient of the entity MUST NOT ignore any Content-*
3062    (e.g. Content-Range) headers that it does not understand or implement
3063    and MUST return a 501 (Not Implemented) response in such cases.
3064
3065    If the request passes through a cache and the Request-URI identifies
3066    one or more currently cached entities, those entries SHOULD be
3067    treated as stale. Responses to this method are not cacheable.
3068
3069    The fundamental difference between the POST and PUT requests is
3070    reflected in the different meaning of the Request-URI. The URI in a
3071    POST request identifies the resource that will handle the enclosed
3072    entity. That resource might be a data-accepting process, a gateway to
3073    some other protocol, or a separate entity that accepts annotations.
3074    In contrast, the URI in a PUT request identifies the entity enclosed
3075    with the request -- the user agent knows what URI is intended and the
3076    server MUST NOT attempt to apply the request to some other resource.
3077    If the server desires that the request be applied to a different URI,
3078
3079
3080
3081
3082 Fielding, et al.            Standards Track                    [Page 55]
3083 \f
3084 RFC 2616                        HTTP/1.1                       June 1999
3085
3086
3087    it MUST send a 301 (Moved Permanently) response; the user agent MAY
3088    then make its own decision regarding whether or not to redirect the
3089    request.
3090
3091    A single resource MAY be identified by many different URIs. For
3092    example, an article might have a URI for identifying "the current
3093    version" which is separate from the URI identifying each particular
3094    version. In this case, a PUT request on a general URI might result in
3095    several other URIs being defined by the origin server.
3096
3097    HTTP/1.1 does not define how a PUT method affects the state of an
3098    origin server.
3099
3100    PUT requests MUST obey the message transmission requirements set out
3101    in section 8.2.
3102
3103    Unless otherwise specified for a particular entity-header, the
3104    entity-headers in the PUT request SHOULD be applied to the resource
3105    created or modified by the PUT.
3106
3107 9.7 DELETE
3108
3109    The DELETE method requests that the origin server delete the resource
3110    identified by the Request-URI. This method MAY be overridden by human
3111    intervention (or other means) on the origin server. The client cannot
3112    be guaranteed that the operation has been carried out, even if the
3113    status code returned from the origin server indicates that the action
3114    has been completed successfully. However, the server SHOULD NOT
3115    indicate success unless, at the time the response is given, it
3116    intends to delete the resource or move it to an inaccessible
3117    location.
3118
3119    A successful response SHOULD be 200 (OK) if the response includes an
3120    entity describing the status, 202 (Accepted) if the action has not
3121    yet been enacted, or 204 (No Content) if the action has been enacted
3122    but the response does not include an entity.
3123
3124    If the request passes through a cache and the Request-URI identifies
3125    one or more currently cached entities, those entries SHOULD be
3126    treated as stale. Responses to this method are not cacheable.
3127
3128 9.8 TRACE
3129
3130    The TRACE method is used to invoke a remote, application-layer loop-
3131    back of the request message. The final recipient of the request
3132    SHOULD reflect the message received back to the client as the
3133    entity-body of a 200 (OK) response. The final recipient is either the
3134
3135
3136
3137
3138 Fielding, et al.            Standards Track                    [Page 56]
3139 \f
3140 RFC 2616                        HTTP/1.1                       June 1999
3141
3142
3143    origin server or the first proxy or gateway to receive a Max-Forwards
3144    value of zero (0) in the request (see section 14.31). A TRACE request
3145    MUST NOT include an entity.
3146
3147    TRACE allows the client to see what is being received at the other
3148    end of the request chain and use that data for testing or diagnostic
3149    information. The value of the Via header field (section 14.45) is of
3150    particular interest, since it acts as a trace of the request chain.
3151    Use of the Max-Forwards header field allows the client to limit the
3152    length of the request chain, which is useful for testing a chain of
3153    proxies forwarding messages in an infinite loop.
3154
3155    If the request is valid, the response SHOULD contain the entire
3156    request message in the entity-body, with a Content-Type of
3157    "message/http". Responses to this method MUST NOT be cached.
3158
3159 9.9 CONNECT
3160
3161    This specification reserves the method name CONNECT for use with a
3162    proxy that can dynamically switch to being a tunnel (e.g. SSL
3163    tunneling [44]).
3164
3165 10 Status Code Definitions
3166
3167    Each Status-Code is described below, including a description of which
3168    method(s) it can follow and any metainformation required in the
3169    response.
3170
3171 10.1 Informational 1xx
3172
3173    This class of status code indicates a provisional response,
3174    consisting only of the Status-Line and optional headers, and is
3175    terminated by an empty line. There are no required headers for this
3176    class of status code. Since HTTP/1.0 did not define any 1xx status
3177    codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
3178    except under experimental conditions.
3179
3180    A client MUST be prepared to accept one or more 1xx status responses
3181    prior to a regular response, even if the client does not expect a 100
3182    (Continue) status message. Unexpected 1xx status responses MAY be
3183    ignored by a user agent.
3184
3185    Proxies MUST forward 1xx responses, unless the connection between the
3186    proxy and its client has been closed, or unless the proxy itself
3187    requested the generation of the 1xx response. (For example, if a
3188
3189
3190
3191
3192
3193
3194 Fielding, et al.            Standards Track                    [Page 57]
3195 \f
3196 RFC 2616                        HTTP/1.1                       June 1999
3197
3198
3199    proxy adds a "Expect: 100-continue" field when it forwards a request,
3200    then it need not forward the corresponding 100 (Continue)
3201    response(s).)
3202
3203 10.1.1 100 Continue
3204
3205    The client SHOULD continue with its request. This interim response is
3206    used to inform the client that the initial part of the request has
3207    been received and has not yet been rejected by the server. The client
3208    SHOULD continue by sending the remainder of the request or, if the
3209    request has already been completed, ignore this response. The server
3210    MUST send a final response after the request has been completed. See
3211    section 8.2.3 for detailed discussion of the use and handling of this
3212    status code.
3213
3214 10.1.2 101 Switching Protocols
3215
3216    The server understands and is willing to comply with the client's
3217    request, via the Upgrade message header field (section 14.42), for a
3218    change in the application protocol being used on this connection. The
3219    server will switch protocols to those defined by the response's
3220    Upgrade header field immediately after the empty line which
3221    terminates the 101 response.
3222
3223    The protocol SHOULD be switched only when it is advantageous to do
3224    so. For example, switching to a newer version of HTTP is advantageous
3225    over older versions, and switching to a real-time, synchronous
3226    protocol might be advantageous when delivering resources that use
3227    such features.
3228
3229 10.2 Successful 2xx
3230
3231    This class of status code indicates that the client's request was
3232    successfully received, understood, and accepted.
3233
3234 10.2.1 200 OK
3235
3236    The request has succeeded. The information returned with the response
3237    is dependent on the method used in the request, for example:
3238
3239    GET    an entity corresponding to the requested resource is sent in
3240           the response;
3241
3242    HEAD   the entity-header fields corresponding to the requested
3243           resource are sent in the response without any message-body;
3244
3245    POST   an entity describing or containing the result of the action;
3246
3247
3248
3249
3250 Fielding, et al.            Standards Track                    [Page 58]
3251 \f
3252 RFC 2616                        HTTP/1.1                       June 1999
3253
3254
3255    TRACE  an entity containing the request message as received by the
3256           end server.
3257
3258 10.2.2 201 Created
3259
3260    The request has been fulfilled and resulted in a new resource being
3261    created. The newly created resource can be referenced by the URI(s)
3262    returned in the entity of the response, with the most specific URI
3263    for the resource given by a Location header field. The response
3264    SHOULD include an entity containing a list of resource
3265    characteristics and location(s) from which the user or user agent can
3266    choose the one most appropriate. The entity format is specified by
3267    the media type given in the Content-Type header field. The origin
3268    server MUST create the resource before returning the 201 status code.
3269    If the action cannot be carried out immediately, the server SHOULD
3270    respond with 202 (Accepted) response instead.
3271
3272    A 201 response MAY contain an ETag response header field indicating
3273    the current value of the entity tag for the requested variant just
3274    created, see section 14.19.
3275
3276 10.2.3 202 Accepted
3277
3278    The request has been accepted for processing, but the processing has
3279    not been completed.  The request might or might not eventually be
3280    acted upon, as it might be disallowed when processing actually takes
3281    place. There is no facility for re-sending a status code from an
3282    asynchronous operation such as this.
3283
3284    The 202 response is intentionally non-committal. Its purpose is to
3285    allow a server to accept a request for some other process (perhaps a
3286    batch-oriented process that is only run once per day) without
3287    requiring that the user agent's connection to the server persist
3288    until the process is completed. The entity returned with this
3289    response SHOULD include an indication of the request's current status
3290    and either a pointer to a status monitor or some estimate of when the
3291    user can expect the request to be fulfilled.
3292
3293 10.2.4 203 Non-Authoritative Information
3294
3295    The returned metainformation in the entity-header is not the
3296    definitive set as available from the origin server, but is gathered
3297    from a local or a third-party copy. The set presented MAY be a subset
3298    or superset of the original version. For example, including local
3299    annotation information about the resource might result in a superset
3300    of the metainformation known by the origin server. Use of this
3301    response code is not required and is only appropriate when the
3302    response would otherwise be 200 (OK).
3303
3304
3305
3306 Fielding, et al.            Standards Track                    [Page 59]
3307 \f
3308 RFC 2616                        HTTP/1.1                       June 1999
3309
3310
3311 10.2.5 204 No Content
3312
3313    The server has fulfilled the request but does not need to return an
3314    entity-body, and might want to return updated metainformation. The
3315    response MAY include new or updated metainformation in the form of
3316    entity-headers, which if present SHOULD be associated with the
3317    requested variant.
3318
3319    If the client is a user agent, it SHOULD NOT change its document view
3320    from that which caused the request to be sent. This response is
3321    primarily intended to allow input for actions to take place without
3322    causing a change to the user agent's active document view, although
3323    any new or updated metainformation SHOULD be applied to the document
3324    currently in the user agent's active view.
3325
3326    The 204 response MUST NOT include a message-body, and thus is always
3327    terminated by the f