element in HTML [5]. 4079 10.39 Transfer Encoding 4081 The Transfer-Encoding general-header field indicates what (if any) 4082 type of transformation has been applied to the message body in 4083 order to safely transfer it between the sender and the recipient. 4084 This differs from the Content-Encoding in that the transfer coding 4085 is a property of the message, not of the original resource. 4087 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 4089 Transfer codings are defined in Section 3.6. An example is: 4091 Transfer-Encoding: chunked 4093 Many older HTTP/1.0 applications do not understand the 4094 Transfer-Encoding header. 4096 10.40 Unless 4098 The Unless request-header field performs a similar function as 4099 If-Modified-Since, but the comparison is based on any Entity-Header 4100 field value of the resource and is not restricted to the GET method. 4102 Unless = "Unless" ":" 1#logic-bag 4104 For example, 4106 Unless: {or {ne {Content-MD5 "Q2hlY2sgSW50ZWdyaXR5IQ=="}} 4107 {ne {Content-Length 10036}} 4108 {ne {Content-Version "12.4.8"}} 4109 {gt {Last-Modified "Mon, 04 Dec 1995 01:23:45 GMT"}}} 4111 Multiple Unless headers, or multiple bags separated by commas, can 4112 be combined by OR'ing them together: 4114 Unless: {eq {A "a"}} 4115 Unless: {eq {B "b"}} 4117 is equivalent to 4119 Unless: {eq {A "a"}},{eq {B "b"}} 4121 which in turn is equivalent to 4123 Unless: {or {eq {A "a"}} {eq {B "b"}}} 4125 When a request containing an Unless header field is received, the 4126 server must evaluate the expression defined by the listed 4127 logic-bags (Section 3.11). If the expression evaluates to false, 4128 then no change is made to the semantics of the request. If it 4129 evaluates true and the request is not a conditional GET 4130 (If-Modified-Since, Section 10.23) or a partial GET (Range, 4131 Section 10.33), then the server must abort the request and respond 4132 with the 412 (unless true) status code. If the request is a 4133 conditional GET, then the server must disregard the 4134 If-Modified-Since value and respond as it would for a normal GET. 4135 Similarly, if the request is a partial GET, then the server must 4136 disregard the Range value and respond as it would for a normal GET. 4138 10.41 Upgrade 4140 The Upgrade general-header allows the client to specify what 4141 additional communication protocols it supports and would like to 4142 use if the server finds it appropriate to switch protocols. The 4143 server must use the Upgrade header field within a 101 (switching 4144 protocols) response to indicate which protocol(s) are being 4145 switched. 4147 Upgrade = "Upgrade" ":" 1#product 4149 For example, 4151 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 4153 The purpose of the Upgrade header is to allow easier migration 4154 across protocols in order to better match the application needs 4155 with protocol capabilities. 4157 10.42 URI 4159 The URI entity-header field is used to inform the recipient of 4160 other Uniform Resource Identifiers (Section 3.2) by which the 4161 resource can be identified, and of all negotiable variants 4162 corresponding to the Request-URI. 4164 URI-header = "URI" ":" 1#( uri-mirror | uri-name | uri-variant ) 4166 uri-mirror = "{" "mirror" <"> URI <"> "}" 4167 uri-name = "{" "name" <"> URI <"> "}" 4168 uri-variant = "{" "variant" <"> URI <"> qvalue 4169 [ "{" "type" <"> media-type <"> "}" ] 4170 [ "{" "language" <"> 1#language-tag <"> "}" ] 4171 [ "{" "encoding" <"> 1#content-coding <"> "}" ] 4172 [ "{" "length" 1*DIGIT "}" ] 4173 [ "{" "user-agent" "}" ] 4174 "}" 4176 Any URI specified in this field can be absolute or relative to the 4177 Request-URI. The "mirror" form of URI refers to a location which is 4178 a mirror copy of the Request-URI. The "name" form refers to a 4179 location-independent name corresponding to the Request-URI. The 4180 "variant" form refers to one of the set of negotiable variants that 4181 may be retrieved via a request on the Request-URI. 4183 If the Request-URI maps to a set of variants, then the dimensions 4184 of that variance must be given in any response containing one of 4185 those variants. If the Location header field is present in a 2xx 4186 response, its value identifies which one of the variants is 4187 included with the response. An example is: 4189 Location: http://www.w3.org/pub/WWW/TheProject.en.html 4191 URI: {variant "TheProject.fr.html" 1.0 4192 {type "text/html"} {language "fr"}}, 4193 {variant "TheProject.en.html" 1.0 4194 {type "text/html"} {language "en"}}, 4195 {variant "TheProject.fr.txt" 0.7 4196 {type "text/plain"} {language "fr"}}, 4197 {variant "TheProject.en.txt" 0.8 4198 {type "text/plain"} {language "en"}} 4200 which indicates that the negotiable Request-URI covers a group of 4201 four individual resources that vary in media type and natural 4202 language. The type, language, encoding, and length attributes refer 4203 to their Content-* counterparts for each resource. The user-agent 4204 attribute indicates that the associated URI is negotiable based on 4205 the User-Agent header field. 4207 User agents may use this information to notify the user of 4208 additional formats and to guide the process of reactive content 4209 negotiation (Section 12). 4211 10.43 User-Agent 4213 The User-Agent request-header field contains information about the 4214 user agent originating the request. This is for statistical 4215 purposes, the tracing of protocol violations, and automated 4216 recognition of user agents for the sake of tailoring responses to 4217 avoid particular user agent limitations. Although it is not 4218 required, user agents should include this field with requests. The 4219 field can contain multiple product tokens (Section 3.8) and 4220 comments identifying the agent and any subproducts which form a 4221 significant part of the user agent. By convention, the product 4222 tokens are listed in order of their significance for identifying 4223 the application. 4225 User-Agent = "User-Agent" ":" 1*( product | comment ) 4227 Example: 4229 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 4231 10.44 WWW-Authenticate 4233 The WWW-Authenticate response-header field must be included in 401 4234 (unauthorized) response messages. The field value consists of at 4235 least one challenge that indicates the authentication scheme(s) and 4236 parameters applicable to the Request-URI. 4238 WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 4240 The HTTP access authentication process is described in Section 11. 4241 User agents must take special care in parsing the WWW-Authenticate 4242 field value if it contains more than one challenge, or if more than 4243 one WWW-Authenticate header field is provided, since the contents 4244 of a challenge may itself contain a comma-separated list of 4245 authentication parameters. 4247 11. Access Authentication 4249 HTTP provides a simple challenge-response authentication mechanism 4250 which may be used by a server to challenge a client request and by 4251 a client to provide authentication information. It uses an 4252 extensible, case-insensitive token to identify the authentication 4253 scheme, followed by a comma-separated list of attribute-value pairs 4254 which carry the parameters necessary for achieving authentication 4255 via that scheme. 4257 auth-scheme = token 4259 auth-param = token "=" quoted-string 4261 The 401 (unauthorized) response message is used by an origin server 4262 to challenge the authorization of a user agent. This response must 4263 include a WWW-Authenticate header field containing at least one 4264 challenge applicable to the requested resource. 4266 challenge = auth-scheme 1*SP realm *( "," auth-param ) 4268 realm = "realm" "=" realm-value 4269 realm-value = quoted-string 4271 The realm attribute (case-insensitive) is required for all 4272 authentication schemes which issue a challenge. The realm value 4273 (case-sensitive), in combination with the canonical root URL of the 4274 server being accessed, defines the protection space. These realms 4275 allow the protected resources on a server to be partitioned into a 4276 set of protection spaces, each with its own authentication scheme 4277 and/or authorization database. The realm value is a string, 4278 generally assigned by the origin server, which may have additional 4279 semantics specific to the authentication scheme. 4281 A user agent that wishes to authenticate itself with a 4282 server--usually, but not necessarily, after receiving a 401 or 411 4283 response--may do so by including an Authorization header field with 4284 the request. The Authorization field value consists of credentials 4285 containing the authentication information of the user agent for the 4286 realm of the resource being requested. 4288 credentials = basic-credentials 4289 | auth-scheme *("," auth-param ) 4291 The domain over which credentials can be automatically applied by a 4292 user agent is determined by the protection space. If a prior 4293 request has been authorized, the same credentials may be reused for 4294 all other requests within that protection space for a period of 4295 time determined by the authentication scheme, parameters, and/or 4296 user preference. Unless otherwise defined by the authentication 4297 scheme, a single protection space cannot extend outside the scope 4298 of its server. 4300 If the server does not wish to accept the credentials sent with a 4301 request, it should return a 401 (unauthorized) response. The 4302 response must include a WWW-Authenticate header field containing 4303 the (possibly new) challenge applicable to the requested resource 4304 and an entity explaining the refusal. 4306 The HTTP protocol does not restrict applications to this simple 4307 challenge-response mechanism for access authentication. Additional 4308 mechanisms may be used, such as encryption at the transport level 4309 or via message encapsulation, and with additional header fields 4310 specifying authentication information. However, these additional 4311 mechanisms are not defined by this specification. 4313 Proxies must be completely transparent regarding user agent 4314 authentication. That is, they must forward the WWW-Authenticate and 4315 Authorization headers untouched, and must not cache the response to 4316 a request containing Authorization. 4318 HTTP/1.1 allows a client pass authentication information to and 4319 from a proxy via the Proxy-Authenticate and Proxy-Authorization 4320 headers. 4322 11.1 Basic Authentication Scheme 4324 The "basic" authentication scheme is based on the model that the 4325 user agent must authenticate itself with a user-ID and a password 4326 for each realm. The realm value should be considered an opaque 4327 string which can only be compared for equality with other realms on 4328 that server. The server will service the request only if it can 4329 validate the user-ID and password for the protection space of the 4330 Request-URI. There are no optional authentication parameters. 4332 Upon receipt of an unauthorized request for a URI within the 4333 protection space, the server should respond with a challenge like 4334 the following: 4336 WWW-Authenticate: Basic realm="WallyWorld" 4338 where "WallyWorld" is the string assigned by the server to identify 4339 the protection space of the Request-URI. 4341 To receive authorization, the client sends the user-ID and 4342 password, separated by a single colon (":") character, within a 4343 base64 [7] encoded string in the credentials. 4345 basic-credentials = " Basic" SP basic-cookie 4347 basic-cookie = <base64 [7] encoding of userid-password, 4348 except not limited to 76 char/line> 4350 userid-password = [ token ] ":" *TEXT 4352 If the user agent wishes to send the user-ID "Aladdin" and password 4353 "open sesame", it would use the following header field: 4355 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 4357 The basic authentication scheme is a non-secure method of filtering 4358 unauthorized access to resources on an HTTP server. It is based on 4359 the assumption that the connection between the client and the 4360 server can be regarded as a trusted carrier. As this is not 4361 generally true on an open network, the basic authentication scheme 4362 should be used accordingly. In spite of this, clients should 4363 implement the scheme in order to communicate with servers that use 4364 it. 4366 11.2 Digest Authentication Scheme 4368 The "digest" authentication scheme is [currently described in an 4369 expired Internet-Draft, and this description will have to be 4370 improved to reference a new draft or include the old one]. 4372 12. Content Negotiation 4374 Content negotiation is an optional feature of the HTTP protocol. It 4375 is designed to allow for selection of a preferred content 4376 representation based upon the attributes of the negotiable variants 4377 corresponding to the requested resource. HTTP/1.1 provides for two 4378 types of negotiation: preemptive and reactive. 4380 Servers that make use of content negotiated resources must include 4381 URI response headers which accurately describe the available 4382 variants, and include the relevant parameters necessary for the 4383 client (user agent or proxy) to evaluate those variants. 4385 12.1 Preemptive Negotiation 4387 Preemptive negotiation attempts to "negotiate" the variant 4388 parameters by including the user agent preferences within each 4389 request. In this way, the preferred representation of the resource 4390 may be negotiated and obtained within a single request-response 4391 round-trip, and without intervention from the user. However, this 4392 also means that the user agent preferences are all the time, even 4393 though relatively few resources are ever negotiable. Preemptive 4394 negotiation may not always be desirable for the user and is 4395 sometimes unnecessary for the content provider. Implementors should 4396 provide mechanisms whereby the amount of preemptive content 4397 negotiation, and the parameters of that negotiation, are 4398 configurable by the user and server maintainer. 4400 The first step in the negotiation algorithm is for the server to 4401 determine whether or not there are any content variants for the 4402 requested resource. Content variants may be in the form of multiple 4403 preexisting entities or a set of dynamic conversion filters. These 4404 variants make up the set of entities which may be sent in response 4405 to a request for the given Request-URI. In most cases, there will 4406 only be one available form of the resource, and thus a single 4407 "variant". 4409 For each variant form of the resource, the server identifies a set 4410 of quality values (Section 3.9) which act as weights for measuring 4411 the desirability of that resource as a response to the current 4412 request. The calculated weights are all real numbers in the range 0 4413 through 1, where 0 is the minimum and 1 the maximum value. The 4414 maximum acceptable bytes for each media range and the size of the 4415 resource variant are also factors in the equation. 4417 The following parameters are included in the calculation: 4419 qs Source quality is measured by the content provider as 4420 representing the amount of degradation from the original 4421 source. For example, a picture originally in JPEG form 4422 would have a lower qs when translated to the XBM format, 4423 and much lower qs when translated to an ASCII-art 4424 representation. Note, however, that this is a function of 4425 the source -- an original piece of ASCII-art may degrade in 4426 quality if it is captured in JPEG form. The qs value should 4427 be assigned to each variant by the content provider; if no 4428 qs value has been assigned, the default is generally 4429 "qs=1". A server may define its own default qs value based 4430 on the resource characteristics, but only if individual 4431 resources can override those defaults. 4433 qe Encoding quality is measured by comparing the variant's 4434 applied content-codings (Section 3.5) to those listed in 4435 the request message's Accept-Encoding field. If the variant 4436 has no assigned Content-Encoding, or if no Accept-Encoding 4437 field is present, the value assigned is "qe=1". If all of 4438 the variant's content encodings are listed in the 4439 Accept-Encoding field, then the value assigned is "qe=1". 4440 If any of the variant's content encodings are not listed in 4441 the provided Accept-Encoding field, then the value assigned 4442 is "qe=0". 4444 qc Charset quality is measured by comparing the variant 4445 media-type's charset parameter value (if any) to those 4446 character sets (Section 3.4) listed in the request 4447 message's Accept-Charset field. If the variant's media-type 4448 has no charset parameter, or the variant's charset is 4449 US-ASCII, or if no Accept-Charset field is present, then 4450 the value assigned is "qc=1". If the variant's charset is 4451 listed in the Accept-Charset field, then the value assigned 4452 is "qc=1". Otherwise, if the variant's charset is not 4453 listed in the provided Accept-Encoding field, then the 4454 value assigned is "qc=0". 4456 ql Language quality is measured by comparing the variant's 4457 assigned language tag(s) (Section 3.10) to those listed in 4458 the request message's Accept-Language field. If no variant 4459 has an assigned Content-Language, or if no Accept-Language 4460 field is present, the value assigned is "ql=1". If at least 4461 one variant has an assigned content language, but the one 4462 currently under consideration does not, then it should be 4463 assigned the value "ql=0.5". If any of the variant's 4464 content languages are listed in the Accept-Language field, 4465 then the value assigned is the maximum of the "q" parameter 4466 values for those language tags (Section 10.4); if there was 4467 no exact match and at least one of the Accept-Language 4468 field values is a complete subtag prefix of the content 4469 language tag(s), then the "q" parameter value of the 4470 largest matching prefix is used. If none of the variant's 4471 content language tags or tag prefixes are listed in the 4472 provided Accept-Language field, then the value assigned is 4473 "ql=0.001". 4475 q Media type quality is measured by comparing the variant's 4476 assigned media type (Section 3.7) to those listed in the 4477 request message's Accept field. If no Accept field is 4478 given, then the value assigned is "q=1". If at least one 4479 listed media range (Section 10.1) matches the variant's 4480 media type, then the "q" parameter value assigned to the 4481 most specific of those matched is used (e.g., 4482 "text/html;version=3.0" is more specific than "text/html", 4483 which is more specific than "text/*", which in turn is more 4484 specific than "*/*"). If no media range in the provided 4485 Accept field matches the variant's media type, then the 4486 value assigned is "q=0". 4488 mxb The maximum number of bytes in an Entity-Body that the 4489 client will accept is also obtained from the matching of 4490 the variant's assigned media type to those listed in the 4491 request message's Accept field. If no Accept field is 4492 given, or if no media range in the provided Accept field 4493 matches the variant's media type, then the value assigned 4494 is "mxb=undefined" (i.e., infinity). Otherwise, the value 4495 used is that given to the "mxb" parameter in the media 4496 range chosen above for the q value. 4498 bs The actual number of bytes in the Entity-Body for the 4499 variant when it is included in a response message. This 4500 should equal the value of Content-Length. 4502 The mapping function is defined as: 4504 Q(qs,qe,qc,ql, { if mxb=undefined, then (qs*qe*qc*ql*q) } 4505 q,mxb,bs) = { if mxb >= bs, then (qs*qe*qc*ql*q) } 4506 { if mxb < bs, then 0 } 4508 The variants with a maximal value for the Q function represent the 4509 preferred representation(s) of the entity; those with a Q values 4510 less than the maximal value are therefore excluded from further 4511 consideration. If multiple representations exist that only vary by 4512 Content-Encoding, then the smallest representation (lowest bs) is 4513 preferred. 4515 If no variants remain with a value of Q greater than zero (0), the 4516 server should respond with a 406 (none acceptable) response 4517 message. If multiple variants remain with an equally high Q value, 4518 the server may either choose one from those available and respond 4519 with 200 (ok) or respond with 300 (multiple choices) and include an 4520 entity describing the choices. In the latter case, the entity 4521 should either be of type "text/html', such that the user can choose 4522 from among the choices by following an exact link, or of some type 4523 that would allow the user agent to perform the selection 4524 automatically. 4526 The 300 (multiple choices) response can be given even if the server 4527 does not perform any winnowing of the representation choices via 4528 the content negotiation algorithm described above. Furthermore, it 4529 may include choices that were not considered as part of the 4530 negotiation algorithm and resources that may be located at other 4531 servers. 4533 The algorithm presented above assumes that the user agent has 4534 correctly implemented the protocol and is accurately communicating 4535 its intentions in the form of Accept-related header fields. The 4536 server may alter its response if it knows that the particular 4537 version of user agent software making the request has incorrectly 4538 or inadequately implemented these fields. 4540 13. Caching 4542 [This will be a summary of what is already defined in the Methods, 4543 Status Codes, Cache-Control, Unless, and If-Modified-Since 4544 sections.] 4546 14. Security Considerations 4548 This section is meant to inform application developers, information 4549 providers, and users of the security limitations in HTTP/1.1 as 4550 described by this document. The discussion does not include 4551 definitive solutions to the problems revealed, though it does make 4552 some suggestions for reducing security risks. 4554 14.1 Authentication of Clients 4556 As mentioned in Section 11.1, the Basic authentication scheme is 4557 not a secure method of user authentication, nor does it prevent the 4558 Entity-Body from being transmitted in clear text across the 4559 physical network used as the carrier. HTTP does not prevent 4560 additional authentication schemes and encryption mechanisms from 4561 being employed to increase security. 4563 14.2 Safe Methods 4565 The writers of client software should be aware that the software 4566 represents the user in their interactions over the Internet, and 4567 should be careful to allow the user to be aware of any actions they 4568 may take which may have an unexpected significance to themselves or 4569 others. 4571 In particular, the convention has been established that the GET and 4572 HEAD methods should never have the significance of taking an action 4573 other than retrieval. These methods should be considered "safe." 4574 This allows user agents to represent other methods, such as POST, 4575 PUT and DELETE, in a special way, so that the user is made aware of 4576 the fact that a possibly unsafe action is being requested. 4578 Naturally, it is not possible to ensure that the server does not 4579 generate side-effects as a result of performing a GET request; in 4580 fact, some dynamic resources consider that a feature. The important 4581 distinction here is that the user did not request the side-effects, 4582 so therefore cannot be held accountable for them. 4584 14.3 Abuse of Server Log Information 4586 A server is in the position to save personal data about a user's 4587 requests which may identify their reading patterns or subjects of 4588 interest. This information is clearly confidential in nature and 4589 its handling may be constrained by law in certain countries. People 4590 using the HTTP protocol to provide data are responsible for 4591 ensuring that such material is not distributed without the 4592 permission of any individuals that are identifiable by the 4593 published results. 4595 14.4 Transfer of Sensitive Information 4597 Like any generic data transfer protocol, HTTP cannot regulate the 4598 content of the data that is transferred, nor is there any a priori 4599 method of determining the sensitivity of any particular piece of 4600 information within the context of any given request. Therefore, 4601 applications should supply as much control over this information as 4602 possible to the provider of that information. Four header fields 4603 are worth special mention in this context: Server, Forwarded, 4604 Referer and From. 4606 Revealing the specific software version of the server may allow the 4607 server machine to become more vulnerable to attacks against 4608 software that is known to contain security holes. Implementors 4609 should make the Server header field a configurable option. 4611 Proxies which serve as a portal through a network firewall should 4612 take special precautions regarding the transfer of header 4613 information that identifies the hosts behind the firewall. In 4614 particular, they should remove, or replace with sanitized versions, 4615 any Forwarded fields generated behind the firewall. 4617 The Referer field allows reading patterns to be studied and reverse 4618 links drawn. Although it can be very useful, its power can be 4619 abused if user details are not separated from the information 4620 contained in the Referer. Even when the personal information has 4621 been removed, the Referer field may indicate a private document's 4622 URI whose publication would be inappropriate. 4624 The information sent in the From field might conflict with the 4625 user's privacy interests or their site's security policy, and hence 4626 it should not be transmitted without the user being able to 4627 disable, enable, and modify the contents of the field. The user 4628 must be able to set the contents of this field within a user 4629 preference or application defaults configuration. 4631 We suggest, though do not require, that a convenient toggle 4632 interface be provided for the user to enable or disable the sending 4633 of From and Referer information. 4635 15. Acknowledgments 4637 This specification makes heavy use of the augmented BNF and generic 4638 constructs defined by David H. Crocker for RFC 822 [9]. Similarly, 4639 it reuses many of the definitions provided by Nathaniel Borenstein 4640 and Ned Freed for MIME [7]. We hope that their inclusion in this 4641 specification will help reduce past confusion over the relationship 4642 between HTTP and Internet mail message formats. 4644 The HTTP protocol has evolved considerably over the past four 4645 years. It has benefited from a large and active developer 4646 community--the many people who have participated on the www-talk 4647 mailing list--and it is that community which has been most 4648 responsible for the success of HTTP and of the World-Wide Web in 4649 general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob 4650 Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, 4651 H&kon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, 4652 Tony Sanders, and Marc VanHeyningen deserve special recognition for 4653 their efforts in defining early aspects of the protocol. 4655 This document has benefited greatly from the comments of all those 4656 participating in the HTTP-WG. In addition to those already 4657 mentioned, the following individuals have contributed to this 4658 specification: 4660 Gary Adams Harald Tveit Alvestrand 4661 Keith Ball Brian Behlendorf 4662 Paul Burchard Maurizio Codogno 4663 Mike Cowlishaw Roman Czyborra 4664 Michael A. Dolan Jim Gettys 4665 Marc Hedlund Koen Holtman 4666 Alex Hopmann Bob Jernigan 4667 Shel Kaphan Rohit Khare 4668 Martijn Koster Alexei Kosut 4669 Dave Kristol Daniel LaLiberte 4670 Paul Leach Albert Lunde 4671 John C. Mallery Jean-Philippe Martin-Flatin 4672 Larry Masinter Mitra 4673 Jeffrey Mogul Gavin Nicol 4674 Bill Perry Jeffrey Perry 4675 Owen Rees Luigi Rizzo 4676 David Robinson Marc Salomon 4677 Rich Salz Jim Seidman 4678 Chuck Shotton Eric W. Sink 4679 Simon E. Spero Richard N. Taylor 4680 Robert S. Thau Franccedillaois Yergeau 4681 Mary Ellen Zurko 4683 16. References 4685 [1] H. Alvestrand. "Tags for the identification of languages." RFC 4686 1766, UNINETT, March 1995. 4688 [2] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, 4689 B. Alberti. "The Internet Gopher Protocol: A distributed 4690 document search and retrieval protocol." RFC 1436, University 4691 of Minnesota, March 1993. 4693 [3] T. Berners-Lee. "Universal Resource Identifiers in WWW: A 4694 Unifying Syntax for the Expression of Names and Addresses of 4695 Objects on the Network as used in the World-Wide Web." 4696 RFC 1630, CERN, June 1994. 4698 [4] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource 4699 Locators (URL)." RFC 1738, CERN, Xerox PARC, University of 4700 Minnesota, December 1994. 4702 [5] T. Berners-Lee, D. Connolly. "HyperText Markup Language 4703 Specification - 2.0." RFC 1866, MIT/LCS, November 1995. 4705 [6] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer 4706 Protocol - HTTP/1.0." Work in Progress 4707 (draft-ietf-http-v10-spec-04.txt), MIT/LCS, UC Irvine, 4708 September 1995. 4710 [7] N. Borenstein, N. Freed. "MIME (Multipurpose Internet Mail 4711 Extensions) Part One: Mechanisms for Specifying and Describing 4712 the Format of Internet Message Bodies." RFC 1521, Bellcore, 4713 Innosoft, September 1993. 4715 [8] R. Braden. "Requirements for Internet hosts - application and 4716 support." STD 3, RFC 1123, IETF, October 1989. 4718 [9] D. H. Crocker. "Standard for the Format of ARPA Internet Text 4719 Messages." STD 11, RFC 822, UDEL, August 1982. 4721 [10] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, 4722 J. Sui, M. Grinbaum. "WAIS Interface Protocol Prototype 4723 Functional Specification." (v1.5), Thinking Machines 4724 Corporation, April 1990. 4726 [11] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC 4727 Irvine, June 1995. 4729 [12] M. Horton, R. Adams. "Standard for interchange of USENET 4730 messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell 4731 Laboratories, Center for Seismic Studies, December 1987. 4733 [13] B. Kantor, P. Lapsley. "Network News Transfer Protocol: A 4734 Proposed Standard for the Stream-Based Transmission of News." 4735 RFC 977, UC San Diego, UC Berkeley, February 1986. 4737 [14] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part 4738 Two: Message Header Extensions for Non-ASCII Text." RFC 1522, 4739 University of Tennessee, September 1993. 4741 [15] E. Nebel, L. Masinter. "Form-based File Upload in HTML." 4742 RFC 1867, Xerox Corporation, November 1995. 4744 [16] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, 4745 USC/ISI, August 1982. 4747 [17] J. Postel. "Media Type Registration Procedure." RFC 1590, 4748 USC/ISI, March 1994. 4750 [18] J. Postel, J. K. Reynolds. "File Transfer Protocol (FTP)." STD 4751 9, RFC 959, USC/ISI, October 1985. 4753 [19] J. Reynolds, J. Postel. "Assigned Numbers." STD 2, RFC 1700, 4754 USC/ISI, October 1994. 4756 [20] K. Sollins, L. Masinter. "Functional Requirements for Uniform 4757 Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, December 4758 1994. 4760 [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code 4761 for Information Interchange. Standard ANSI X3.4-1986, ANSI, 4762 1986. 4764 [22] ISO-8859. International Standard -- Information Processing -- 4765 8-bit Single-Byte Coded Graphic Character Sets -- 4766 Part 1: Latin alphabet No. 1, ISO 8859-1:1987. 4767 Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. 4768 Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. 4769 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. 4770 Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. 4771 Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. 4772 Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. 4773 Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. 4774 Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. 4776 17. Authors' Addresses 4778 Roy T. Fielding 4779 Department of Information and Computer Science 4780 University of California 4781 Irvine, CA 92717-3425, U.S.A. 4782 Fax: +1 (714) 824-4056 4783 Email: fielding@ics.uci.edu 4785 Henrik Frystyk Nielsen 4786 W3 Consortium 4787 MIT Laboratory for Computer Science 4788 545 Technology Square 4789 Cambridge, MA 02139, U.S.A. 4790 Fax: +1 (617) 258 8682 4791 Email: frystyk@w3.org 4793 Tim Berners-Lee 4794 Director, W3 Consortium 4795 MIT Laboratory for Computer Science 4796 545 Technology Square 4797 Cambridge, MA 02139, U.S.A. 4798 Fax: +1 (617) 258 8682 4799 Email: timbl@w3.org 4801 Appendices 4803 These appendices are provided for informational reasons only -- they 4804 do not form a part of the HTTP/1.1 specification. 4806 A. Internet Media Type message/http 4808 In addition to defining the HTTP/1.1 protocol, this document serves 4809 as the specification for the Internet media type "message/http". 4810 The following is to be registered with IANA [17]. 4812 Media Type name: message 4814 Media subtype name: http 4816 Required parameters: none 4818 Optional parameters: version, msgtype 4820 version: The HTTP-Version number of the enclosed message 4821 (e.g., "1.1"). If not present, the version can be 4822 determined from the first line of the body. 4824 msgtype: The message type -- "request" or "response". If 4825 not present, the type can be determined from the 4826 first line of the body. 4828 Encoding considerations: only "7bit", "8bit", or "binary" are 4829 permitted 4831 Security considerations: none 4833 B. Tolerant Applications 4835 Although this document specifies the requirements for the 4836 generation of HTTP/1.1 messages, not all applications will be 4837 correct in their implementation. We therefore recommend that 4838 operational applications be tolerant of deviations whenever those 4839 deviations can be interpreted unambiguously. 4841 Clients should be tolerant in parsing the Status-Line and servers 4842 tolerant when parsing the Request-Line. In particular, they should 4843 accept any amount of SP or HT characters between fields, even 4844 though only a single SP is required. 4846 The line terminator for HTTP-header fields is the sequence CRLF. 4847 However, we recommend that applications, when parsing such headers, 4848 recognize a single LF as a line terminator and ignore the leading 4849 CR. 4851 C. Relationship to MIME 4853 HTTP/1.1 reuses many of the constructs defined for Internet Mail 4854 (RFC 822 [9]) and the Multipurpose Internet Mail Extensions 4855 (MIME [7]) to allow entities to be transmitted in an open variety 4856 of representations and with extensible mechanisms. However, HTTP is 4857 not a MIME-compliant application. HTTP's performance requirements 4858 differ substantially from those of Internet mail. Since it is not 4859 limited by the restrictions of existing mail protocols and SMTP 4860 gateways, HTTP does not obey some of the constraints imposed by 4861 RFC 822 and MIME for mail transport. 4863 This appendix describes specific areas where HTTP differs from 4864 MIME. Proxies/gateways to MIME-compliant protocols must be aware of 4865 these differences and provide the appropriate conversions where 4866 necessary. 4868 C.1 Conversion to Canonical Form 4870 MIME requires that an entity be converted to canonical form prior 4871 to being transferred, as described in Appendix G of RFC 1521 [7]. 4872 Although HTTP does require media types to be transferred in 4873 canonical form, it changes the definition of "canonical form" for 4874 text-based media types as described in Section 3.7.1. 4876 C.1.1 Representation of Line Breaks 4878 MIME requires that the canonical form of any text type represent 4879 line breaks as CRLF and forbids the use of CR or LF outside of line 4880 break sequences. Since HTTP allows CRLF, bare CR, and bare LF (or 4881 the octet sequence(s) to which they would be translated for the 4882 given character set) to indicate a line break within text content, 4883 recipients of an HTTP message cannot rely upon receiving 4884 MIME-canonical line breaks in text. 4886 Where it is possible, a proxy/gateway from HTTP to a MIME-compliant 4887 protocol should translate all line breaks within text/* media types 4888 to the MIME canonical form of CRLF. However, this may be 4889 complicated by the presence of a Content-Encoding and by the fact 4890 that HTTP allows the use of some character sets which do not use 4891 octets 13 and 10 to represent CR and LF, as is the case for some 4892 multi-byte character sets. If canonicalization is performed, the 4893 Content-Length header field value must be updated to reflect the 4894 new body length. 4896 C.1.2 Default Character Set 4898 MIME requires that all subtypes of the top-level Content-Type 4899 "text" have a default character set of US-ASCII [21]. In contrast, 4900 HTTP defines the default character set for "text" to be 4901 ISO-8859-1 [22] (a superset of US-ASCII). Therefore, if a text/* 4902 media type given in the Content-Type header field does not already 4903 include an explicit charset parameter, the parameter 4905 ;charset="iso-8859-1" 4907 should be added by the proxy/gateway if the entity contains any 4908 octets greater than 127. 4910 C.2 Conversion of Date Formats 4912 HTTP/1.1 uses a restricted subset of date formats to simplify the 4913 process of date comparison. Proxies/gateways from other protocols 4914 should ensure that any Date header field present in a message 4915 conforms to one of the HTTP/1.1 formats and rewrite the date if 4916 necessary. 4918 C.3 Introduction of Content-Encoding 4920 MIME does not include any concept equivalent to HTTP's 4921 Content-Encoding header field. Since this acts as a modifier on the 4922 media type, proxies/gateways to MIME-compliant protocols must 4923 either change the value of the Content-Type header field or decode 4924 the Entity-Body before forwarding the message. 4926 Note: Some experimental applications of Content-Type for 4927 Internet mail have used a media-type parameter of 4928 ";conversions=<content-coding>" to perform an equivalent 4929 function as Content-Encoding. However, this parameter is not 4930 part of the MIME specification at the time of this writing. 4932 C.4 No Content-Transfer-Encoding 4934 HTTP does not use the Content-Transfer-Encoding (CTE) field of 4935 MIME. Proxies/gateways from MIME-compliant protocols must remove 4936 any non-identity CTE ("quoted-printable" or "base64") encoding 4937 prior to delivering the response message to an HTTP client. 4938 Proxies/gateways to MIME-compliant protocols are responsible for 4939 ensuring that the message is in the correct format and encoding for 4940 safe transport on that protocol, where "safe transport" is defined 4941 by the limitations of the protocol being used. At a minimum, the 4942 CTE field of 4944 Content-Transfer-Encoding: binary 4946 should be added by the proxy/gateway if it is unwilling to apply a 4947 content transfer encoding. 4949 An HTTP client may include a Content-Transfer-Encoding as an 4950 extension Entity-Header in a POST request when it knows the 4951 destination of that request is a proxy/gateway to a MIME-compliant 4952 protocol. 4954 C.5 Introduction of Transfer-Encoding 4956 HTTP/1.1 introduces the Transfer-Encoding header field 4957 (Section 10.39). Proxies/gateways must remove any transfer coding 4958 prior to forwarding a message via a MIME-compliant protocol. The 4959 process for decoding the "chunked" transfer coding (Section 3.6) 4960 can be represented in pseudo-code as: 4962 length := 0 4963 read chunk-size and CRLF 4964 while (chunk-size > 0) { 4965 read chunk-data and CRLF 4966 append chunk-data to Entity-Body 4967 length := length + chunk-size 4968 read chunk-size and CRLF 4969 } 4970 read entity-header 4971 while (entity-header not empty) { 4972 append entity-header to existing header fields 4973 read entity-header 4974 } 4975 Content-Length := length 4976 Remove "chunked" from Transfer-Encoding 4978 D. Changes from HTTP/1.0 4980 This section will summarize the differences between versions 1.0 4981 and 1.1 of the Hypertext Transfer Protocol.

idnits 2.17.1 draft-ietf-http-v11-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 4987 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 1996) is 10323 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '

' and
     '' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: 'CRLF' on line 613

  ** Obsolete normative reference: RFC 1766 (ref. '1') (Obsoleted by RFC
     3066, RFC 3282)

  ** Downref: Normative reference to an Informational RFC: RFC 1436 (ref. '2')

  ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '3')

  ** Obsolete normative reference: RFC 1738 (ref. '4') (Obsoleted by RFC
     4248, RFC 4266)

  ** Obsolete normative reference: RFC 1866 (ref. '5') (Obsoleted by RFC 2854)

  ** Downref: Normative reference to an Informational draft:
     draft-ietf-http-v10-spec (ref. '6')

  ** Obsolete normative reference: RFC 1521 (ref. '7') (Obsoleted by RFC
     2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)

  ** Obsolete normative reference: RFC  822 (ref. '9') (Obsoleted by RFC 2822)

  -- Possible downref: Non-RFC (?) normative reference: ref. '10'

  ** Obsolete normative reference: RFC 1808 (ref. '11') (Obsoleted by RFC
     3986)

  ** Obsolete normative reference: RFC  850 (ref. '12') (Obsoleted by RFC
     1036)

  ** Obsolete normative reference: RFC  977 (ref. '13') (Obsoleted by RFC
     3977)

  ** Obsolete normative reference: RFC 1522 (ref. '14') (Obsoleted by RFC
     2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)

  ** Obsolete normative reference: RFC 1867 (ref. '15') (Obsoleted by RFC
     2854)

  ** Obsolete normative reference: RFC  821 (ref. '16') (Obsoleted by RFC
     2821)

  ** Obsolete normative reference: RFC 1590 (ref. '17') (Obsoleted by RFC
     2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049)

  ** Obsolete normative reference: RFC 1700 (ref. '19') (Obsoleted by RFC
     3232)

  ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref.
     '20')

  -- Possible downref: Non-RFC (?) normative reference: ref. '21'

  -- Possible downref: Non-RFC (?) normative reference: ref. '22'


     Summary: 24 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	HTTP Working Group                                R. Fielding, UC Irvine
2	INTERNET-DRAFT                                       H. Frystyk, MIT/LCS
3	                T. Berners-Lee, MIT/LCS
4	Expires in six months                                   January 19, 1996

6	               Hypertext Transfer Protocol -- HTTP/1.1

8	Status of this Memo

10	   This document is an Internet-Draft. Internet-Drafts are working
11	   documents of the Internet Engineering Task Force (IETF), its areas,
12	   and its working groups. Note that other groups may also distribute
13	   working documents as Internet-Drafts.

15	   Internet-Drafts are draft documents valid for a maximum of six
16	   months and may be updated, replaced, or obsoleted by other
17	   documents at any time. It is inappropriate to use Internet-Drafts
18	   as reference material or to cite them other than as "work in
19	   progress".

21	   To learn the current status of any Internet-Draft, please check the
22	   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
23	   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
24	   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
25	   ftp.isi.edu (US West Coast).

27	   Distribution of this document is unlimited. Please send comments to
28	   the HTTP working group at . Discussions
29	   of the working group are archived at
30	   . General discussions
31	   about HTTP and the applications which use HTTP should take place on
32	   the  mailing list.

34	   ================================================================
35	   NOTE: This specification is for discussion purposes only. It is not
36	   claimed to represent the consensus of the HTTP working group, and
37	   contains a number of proposals that either have not been discussed or
38	   are controversial.  The working group is discussing significant
39	   changes in many areas, including logic bags, support for caching,
40	   range retrieval, content negotiation, MIME compatibility,
41	   authentication, timing of the PUT operation.
42	   ================================================================

44	Abstract

46	   The Hypertext Transfer Protocol (HTTP) is an application-level
47	   protocol for distributed, collaborative, hypermedia information
48	   systems. It is a generic, stateless, object-oriented protocol which
49	   can be used for many tasks, such as name servers and distributed
50	   object management systems, through extension of its request methods
51	   (commands). A feature of HTTP is the typing and negotiation of data
52	   representation, allowing systems to be built independently of the
53	   data being transferred.

55	   HTTP has been in use by the World-Wide Web global information
56	   initiative since 1990. This specification defines the protocol
57	   referred to as "HTTP/1.1".

59	Table of Contents

61	   1.  Introduction
62	       1.1  Purpose
63	       1.2  Requirements
64	       1.3  Terminology
65	       1.4  Overall Operation

67	   2.  Notational Conventions and Generic Grammar
68	       2.1  Augmented BNF
69	       2.2  Basic Rules

71	   3.  Protocol Parameters
72	       3.1  HTTP Version
73	       3.2  Uniform Resource Identifiers
74	            3.2.1  General Syntax
75	            3.2.2  http URL
76	       3.3  Date/Time Formats
77	            3.3.1  Full Date
78	            3.3.2  Delta Seconds
79	       3.4  Character Sets
80	       3.5  Content Codings
81	       3.6  Transfer Codings
82	       3.7  Media Types
83	            3.7.1  Canonicalization and Text Defaults
84	            3.7.2  Multipart Types
85	       3.8  Product Tokens
86	       3.9  Quality Values
87	       3.10 Language Tags
88	       3.11 Logic Bags

90	   4.  HTTP Message
91	       4.1  Message Types
92	       4.2  Message Headers
93	       4.3  General Header Fields

95	   5.  Request
96	       5.1  Request-Line
97	            5.1.1  Method
98	            5.1.2  Request-URI
99	       5.2  Request Header Fields

101	   6.  Response
102	       6.1  Status-Line
103	            6.1.1  Status Code and Reason Phrase
104	       6.2  Response Header Fields

106	   7.  Entity
107	       7.1  Entity Header Fields
108	       7.2  Entity Body
109	            7.2.1  Type
110	            7.2.2  Length

112	   8.  Method Definitions
113	       8.1  OPTIONS
114	       8.2  GET
115	       8.3  HEAD
116	       8.4  POST
117	       8.5  PUT
118	       8.6  PATCH
119	       8.7  COPY
120	       8.8  MOVE
121	       8.9  DELETE
122	       8.10 LINK
123	       8.11 UNLINK
124	       8.12 TRACE
125	       8.13 WRAPPED

127	   9.  Status Code Definitions
128	       9.1  Informational 1xx
129	       9.2  Successful 2xx
130	       9.3  Redirection 3xx
131	       9.4  Client Error 4xx
132	       9.5  Server Error 5xx

134	   10. Header Field Definitions
135	       10.1  Accept
136	       10.2  Accept-Charset
137	       10.3  Accept-Encoding
138	       10.4  Accept-Language
139	       10.5  Allow
140	       10.6  Authorization
141	       10.7  Base
142	       10.8  Cache-Control
143	       10.9  Connection
144	             10.9.1 Persistent Connections
145	       10.10 Content-Encoding
146	       10.11 Content-Language
147	       10.12 Content-Length
148	       10.13 Content-MD5
149	       10.14 Content-Range
150	       10.15 Content-Type
151	       10.16 Content-Version
152	       10.17 Date
153	       10.18 Derived-From
154	       10.19 Expires
155	       10.20 Forwarded
156	       10.21 From
157	       10.22 Host
158	       10.23 If-Modified-Since
159	       10.24 Keep-Alive
160	       10.25 Last-Modified
161	       10.26 Link
162	       10.27 Location
163	       10.28 MIME-Version
164	       10.29 Pragma
165	       10.30 Proxy-Authenticate
166	       10.31 Proxy-Authorization
167	       10.32 Public
168	       10.33 Range
169	       10.34 Referer
170	       10.35 Refresh
171	       10.36 Retry-After
172	       10.37 Server
173	       10.38 Title
174	       10.39 Transfer Encoding
175	       10.40 Unless
176	       10.41 Upgrade
177	       10.42 URI
178	       10.43 User-Agent
179	       10.44 WWW-Authenticate

181	   11. Access Authentication
182	       11.1 Basic Authentication Scheme
183	       11.2 Digest Authentication Scheme

185	   12. Content Negotiation
186	       12.1 Preemptive Negotiation

188	   13. Caching

190	   14. Security Considerations
191	       14.1 Authentication of Clients
192	       14.2 Safe Methods
193	       14.3 Abuse of Server Log Information
194	       14.4 Transfer of Sensitive Information

196	   15. Acknowledgments

198	   16. References

200	   17. Authors' Addresses

202	   Appendix A.   Internet Media Type message/http
203	   Appendix B.   Tolerant Applications
204	   Appendix C.   Relationship to MIME
205	       C.1  Conversion to Canonical Form
206	            C.1.1  Representation of Line Breaks
207	            C.1.2  Default Character Set
208	       C.2  Conversion of Date Formats
209	       C.3  Introduction of Content-Encoding
210	       C.4  No Content-Transfer-Encoding
211	       C.5  Introduction of Transfer-Encoding
212	   Appendix D.   Changes from HTTP/1.0

214	1.  Introduction

216	1.1  Purpose

218	   The Hypertext Transfer Protocol (HTTP) is an application-level
219	   protocol for distributed, collaborative, hypermedia information
220	   systems. HTTP has been in use by the World-Wide Web global
221	   information initiative since 1990. The first version of HTTP,
222	   referred to as HTTP/0.9, was a simple protocol for raw data
223	   transfer across the Internet. HTTP/1.0, as defined by RFC xxxx [6],
224	   improved the protocol by allowing messages to be in the format of
225	   MIME-like entities, containing metainformation about the data
226	   transferred and modifiers on the request/response semantics.
227	   However, HTTP/1.0 does not sufficiently take into consideration the
228	   effect of hierarchical proxies and caching, the desire for
229	   persistent connections and virtual hosts, and a number of other
230	   details that slipped through the cracks of existing
231	   implementations. In addition, the proliferation of incompletely-
232	   implemented applications calling themselves "HTTP/1.0" has
233	   necessitated a protocol version change in order for two
234	   communicating applications to determine each other's true
235	   capabilities.

237	   This specification defines the protocol referred to as "HTTP/1.1".
238	   This protocol is backwards-compatible with HTTP/1.0, but includes
239	   more stringent requirements in order to ensure reliable
240	   implementation of its features.

242	   Practical information systems require more functionality than
243	   simple retrieval, including search, front-end update, and
244	   annotation. HTTP allows an open-ended set of methods to be used to
245	   indicate the purpose of a request. It builds on the discipline of
246	   reference provided by the Uniform Resource Identifier (URI) [3], as
247	   a location (URL) [4] or name (URN) [20], for indicating the
248	   resource on which a method is to be applied. Messages are passed in
249	   a format similar to that used by Internet Mail [9] and the
250	   Multipurpose Internet Mail Extensions (MIME) [7].

252	   HTTP is also used as a generic protocol for communication between
253	   user agents and proxies/gateways to other Internet protocols, such
254	   as SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10],
255	   allowing basic hypermedia access to resources available from
256	   diverse applications and simplifying the implementation of user
257	   agents.

259	1.2  Requirements

261	   This specification uses the same words as RFC 1123 [8] for defining
262	   the significance of each particular requirement. These words are:

264	   must

266	       This word or the adjective "required" means that the item is an
267	       absolute requirement of the specification.

269	   should

271	       This word or the adjective "recommended" means that there may
272	       exist valid reasons in particular circumstances to ignore this
273	       item, but the full implications should be understood and the
274	       case carefully weighed before choosing a different course.

276	   may

278	       This word or the adjective "optional" means that this item is
279	       truly optional. One vendor may choose to include the item
280	       because a particular marketplace requires it or because it
281	       enhances the product, for example; another vendor may omit the
282	       same item.

284	   An implementation is not compliant if it fails to satisfy one or
285	   more of the must requirements for the protocols it implements. An
286	   implementation that satisfies all the must and all the should
287	   requirements for its protocols is said to be "unconditionally
288	   compliant"; one that satisfies all the must requirements but not
289	   all the should requirements for its protocols is said to be
290	   "conditionally compliant".

292	1.3  Terminology

294	   This specification uses a number of terms to refer to the roles
295	   played by participants in, and objects of, the HTTP communication.

297	   connection

299	       A transport layer virtual circuit established between two
300	       application programs for the purpose of communication.

302	   message

304	       The basic unit of HTTP communication, consisting of a structured
305	       sequence of octets matching the syntax defined in Section 4 and
306	       transmitted via the connection.

308	   request

310	       An HTTP request message (as defined in Section 5).

312	   response

314	       An HTTP response message (as defined in Section 6).

316	   resource

318	       A network data object or service which can be identified by a
319	       URI (Section 3.2).

321	   entity

323	       A particular representation or rendition of a data resource, or
324	       reply from a service resource, that may be enclosed within a
325	       request or response message. An entity consists of
326	       metainformation in the form of entity headers and content in the
327	       form of an entity body.

329	   client

331	       An application program that establishes connections for the
332	       purpose of sending requests.

334	   user agent

336	       The client which initiates a request. These are often browsers,
337	       editors, spiders (web-traversing robots), or other end user
338	       tools.

340	   server

342	       An application program that accepts connections in order to
343	       service requests by sending back responses.

345	   origin server

347	       The server on which a given resource resides or is to be created.

349	   proxy

351	       An intermediary program which acts as both a server and a client
352	       for the purpose of making requests on behalf of other clients.
353	       Requests are serviced internally or by passing them, with
354	       possible translation, on to other servers. A proxy must
355	       interpret and, if necessary, rewrite a request message before
356	       forwarding it. Proxies are often used as client-side portals
357	       through network firewalls and as helper applications for
358	       handling requests via protocols not implemented by the user
359	       agent.

361	   gateway

363	       A server which acts as an intermediary for some other server.
364	       Unlike a proxy, a gateway receives requests as if it were the
365	       origin server for the requested resource; the requesting client
366	       may not be aware that it is communicating with a gateway.
367	       Gateways are often used as server-side portals through network
368	       firewalls and as protocol translators for access to resources
369	       stored on non-HTTP systems.

371	   tunnel

373	       A tunnel is an intermediary program which is acting as a blind
374	       relay between two connections. Once active, a tunnel is not
375	       considered a party to the HTTP communication, though the tunnel
376	       may have been initiated by an HTTP request. The tunnel ceases to
377	       exist when both ends of the relayed connections are closed.
378	       Tunnels are used when a portal is necessary and the intermediary
379	       cannot, or should not, interpret the relayed communication.

381	   cache

383	       A program's local store of response messages and the subsystem
384	       that controls its message storage, retrieval, and deletion. A
385	       cache stores cachable responses in order to reduce the response
386	       time and network bandwidth consumption on future, equivalent
387	       requests. Any client or server may include a cache, though a
388	       cache cannot be used by a server while it is acting as a tunnel.

390	   Any given program may be capable of being both a client and a
391	   server; our use of these terms refers only to the role being
392	   performed by the program for a particular connection, rather than
393	   to the program's capabilities in general. Likewise, any server may
394	   act as an origin server, proxy, gateway, or tunnel, switching
395	   behavior based on the nature of each request.

397	1.4  Overall Operation

399	   The HTTP protocol is based on a request/response paradigm. A client
400	   establishes a connection with a server and sends a request to the
401	   server in the form of a request method, URI, and protocol version,
402	   followed by a MIME-like message containing request modifiers,
403	   client information, and possible body content. The server responds
404	   with a status line, including the message's protocol version and a
405	   success or error code, followed by a MIME-like message containing
406	   server information, entity metainformation, and possible body
407	   content.

409	   Most HTTP communication is initiated by a user agent and consists
410	   of a request to be applied to a resource on some origin server. In
411	   the simplest case, this may be accomplished via a single connection
412	   (v) between the user agent (UA) and the origin server (O).

414	          request chain ------------------------>
415	       UA -------------------v------------------- O
416	          <----------------------- response chain

418	   A more complicated situation occurs when one or more intermediaries
419	   are present in the request/response chain. There are three common
420	   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
421	   forwarding agent, receiving requests for a URI in its absolute
422	   form, rewriting all or parts of the message, and forwarding the
423	   reformatted request toward the server identified by the URI. A
424	   gateway is a receiving agent, acting as a layer above some other
425	   server(s) and, if necessary, translating the requests to the
426	   underlying server's protocol. A tunnel acts as a relay point
427	   between two connections without changing the messages; tunnels are
428	   used when the communication needs to pass through an intermediary
429	   (such as a firewall) even when the intermediary cannot understand
430	   the contents of the messages.

432	          request chain -------------------------------------->
433	       UA -----v----- A -----v----- B -----v----- C -----v----- O
434	          <------------------------------------- response chain

436	   The figure above shows three intermediaries (A, B, and C) between
437	   the user agent and origin server. A request or response message
438	   that travels the whole chain must pass through four separate
439	   connections. This distinction is important because some HTTP
440	   communication options may apply only to the connection with the
441	   nearest, non-tunnel neighbor, only to the end-points of the chain,
442	   or to all connections along the chain. Although the diagram is
443	   linear, each participant may be engaged in multiple, simultaneous
444	   communications. For example, B may be receiving requests from many
445	   clients other than A, and/or forwarding requests to servers other
446	   than C, at the same time that it is handling A's request.

448	   Any party to the communication which is not acting as a tunnel may
449	   employ an internal cache for handling requests. The effect of a
450	   cache is that the request/response chain is shortened if one of the
451	   participants along the chain has a cached response applicable to
452	   that request. The following illustrates the resulting chain if B
453	   has a cached copy of an earlier response from O (via C) for a
454	   request which has not been cached by UA or A.

456	          request chain ---------->
457	       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
458	          <--------- response chain

460	   Not all responses are cachable, and some requests may contain
461	   modifiers which place special requirements on cache behavior. HTTP
462	   requirements for cache behavior and cachable responses are defined
463	   in Section 13.

465	   On the Internet, HTTP communication generally takes place over
466	   TCP/IP connections. The default port is TCP 80 [19], but other
467	   ports can be used. This does not preclude HTTP from being
468	   implemented on top of any other protocol on the Internet, or on
469	   other networks. HTTP only presumes a reliable transport; any
470	   protocol that provides such guarantees can be used, and the mapping
471	   of the HTTP/1.1 request and response structures onto the transport
472	   data units of the protocol in question is outside the scope of this
473	   specification.

475	   For most implementations, each connection is established by the
476	   client prior to the request and closed by the server after sending
477	   the response. However, this is not a feature of the protocol and is
478	   not required by this specification. Both clients and servers must
479	   be capable of handling cases where either party closes the
480	   connection prematurely, due to user action, automated time-out, or
481	   program failure. In any case, the closing of the connection by
482	   either or both parties always terminates the current request,
483	   regardless of its status.

485	2.  Notational Conventions and Generic Grammar

487	2.1  Augmented BNF

489	   All of the mechanisms specified in this document are described in
490	   both prose and an augmented Backus-Naur Form (BNF) similar to that
491	   used by RFC 822 [9]. Implementors will need to be familiar with the
492	   notation in order to understand this specification. The augmented
493	   BNF includes the following constructs:

495	   name = definition

497	       The name of a rule is simply the name itself (without any
498	       enclosing "<" and ">") and is separated from its definition by
499	       the equal character "=". Whitespace is only significant in that
500	       indentation of continuation lines is used to indicate a rule
501	       definition that spans more than one line. Certain basic rules
502	       are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
503	       Angle brackets are used within definitions whenever their
504	       presence will facilitate discerning the use of rule names.

506	   "literal"

508	       Quotation marks surround literal text. Unless stated otherwise,
509	       the text is case-insensitive.

511	   rule1 | rule2

513	       Elements separated by a bar ("I") are alternatives, e.g.,
514	       "yes | no" will accept yes or no.

516	   (rule1 rule2)

518	       Elements enclosed in parentheses are treated as a single
519	       element. Thus, "(elem (foo | bar) elem)" allows the token
520	       sequences "elem foo elem" and "elem bar elem".

522	   *rule

524	       The character "*" preceding an element indicates repetition. The
525	       full form is "*element" indicating at least  and at
526	       most  occurrences of element. Default values are 0 and
527	       infinity so that "*(element)" allows any number, including zero;
528	       "1*element" requires at least one; and "1*2element" allows one
529	       or two.

531	   [rule]

533	       Square brackets enclose optional elements; "[foo bar]" is
534	       equivalent to "*1(foo bar)".

536	   N rule

538	       Specific repetition: "(element)" is equivalent to
539	       "*(element)"; that is, exactly  occurrences of
540	       (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a
541	       string of three alphabetic characters.

543	   #rule

545	       A construct "#" is defined, similar to "*", for defining lists
546	       of elements. The full form is "#element" indicating at
547	       least  and at most  elements, each separated by one or
548	       more commas (",") and optional linear whitespace (LWS). This
549	       makes the usual form of lists very easy; a rule such as
550	       "( *LWS element *( *LWS "," *LWS element ))" can be shown as
551	       "1#element". Wherever this construct is used, null elements are
552	       allowed, but do not contribute to the count of elements present.
553	       That is, "(element), , (element)" is permitted, but counts as
554	       only two elements. Therefore, where at least one element is
555	       required, at least one non-null element must be present. Default
556	       values are 0 and infinity so that "#(element)" allows any
557	       number, including zero; "1#element" requires at least one; and
558	       "1#2element" allows one or two.

560	   ; comment

562	       A semi-colon, set off some distance to the right of rule text,
563	       starts a comment that continues to the end of line. This is a
564	       simple way of including useful notes in parallel with the
565	       specifications.

567	   implied *LWS

569	       The grammar described by this specification is word-based.
570	       Except where noted otherwise, linear whitespace (LWS) can be
571	       included between any two adjacent words (token or
572	       quoted-string), and between adjacent tokens and delimiters
573	       (tspecials), without changing the interpretation of a field. At
574	       least one delimiter (tspecials) must exist between any two
575	       tokens, since they would otherwise be interpreted as a single
576	       token. However, applications should attempt to follow "common
577	       form" when generating HTTP constructs, since there exist some
578	       implementations that fail to accept anything beyond the common
579	       forms.

581	2.2  Basic Rules

583	   The following rules are used throughout this specification to
584	   describe basic parsing constructs. The US-ASCII coded character set
585	   is defined by [21].

587	       OCTET          = 
588	       CHAR           = 
589	       UPALPHA        = 
590	       LOALPHA        = 
591	       ALPHA          = UPALPHA | LOALPHA
592	       DIGIT          = 
593	       CTL            = 
595	       CR             = 
596	       LF             = 
597	       SP             = 
598	       HT             = 
599	       <">            = 

601	   HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker
602	   for all protocol elements except the Entity-Body (see Appendix B
603	   for tolerant applications). The end-of-line marker within an
604	   Entity-Body is defined by its associated media type, as described
605	   in Section 3.7.

607	       CRLF           = CR LF

609	   HTTP/1.1 headers can be folded onto multiple lines if the
610	   continuation line begins with a space or horizontal tab. All linear
611	   whitespace, including folding, has the same semantics as SP.

613	       LWS            = [CRLF] 1*( SP | HT )

615	   The TEXT rule is only used for descriptive field contents and
616	   values that are not intended to be interpreted by the message
617	   parser. Words of *TEXT may contain octets from character sets other
618	   than US-ASCII only when encoded according to the rules of
619	   RFC 1522 [14].

621	       TEXT           = 

624	   Recipients of header field TEXT containing octets outside the
625	   US-ASCII character set range may assume that they represent
626	   ISO-8859-1 characters if there is no other encoding indicated by an
627	   RFC 1522 mechanism.

629	   Hexadecimal numeric characters are used in several protocol
630	   elements.

632	       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
633	                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

635	   Many HTTP/1.1 header field values consist of words separated by LWS
636	   or special characters. These special characters must be in a quoted
637	   string to be used within a parameter value.

639	       word           = token | quoted-string

641	       token          = 1*

643	       tspecials      = "(" | ")" | "<" | ">" | "@"
644	                      | "," | ";" | ":" | "\" | <">
645	                      | "/" | "[" | "]" | "?" | "="
646	                      | "{" | "}" | SP | HT

648	   Comments can be included in some HTTP header fields by surrounding
649	   the comment text with parentheses. Comments are only allowed in
650	   fields containing "comment" as part of their field value
651	   definition. In all other fields, parentheses are considered part of
652	   the field value.

654	       comment        = "(" *( ctext | comment ) ")"
655	       ctext          = 

657	   A string of text is parsed as a single word if it is quoted using
658	   double-quote marks.

660	       quoted-string  = ( <"> *(qdtext) <"> )

662	       qdtext         =  and CTLs,
663	                        but including LWS>

665	   The backslash character ("\") may be used as a single-character
666	   quoting mechanism only within quoted-string and comment constructs.

668	       quoted-pair    = "\" CHAR

670	   Braces are used to delimit an attribute-value bag, which may
671	   consist of a set, list, or recursively defined tokens and quoted
672	   strings. The bag semantics are defined by its context and the bag
673	   name, which may be a Uniform Resource Identifier (Section 3.2) in
674	   some fields.

676	       bag            = "{" bagname 1*LWS *bagitem "}"
677	       bagname        = token | URI
678	       bagitem        = bag | token | quoted-string

680	3.  Protocol Parameters

682	3.1  HTTP Version

684	   HTTP uses a "." numbering scheme to indicate versions
685	   of the protocol. The protocol versioning policy is intended to
686	   allow the sender to indicate the format of a message and its
687	   capacity for understanding further HTTP communication, rather than
688	   the features obtained via that communication. No change is made to
689	   the version number for the addition of message components which do
690	   not affect communication behavior or which only add to extensible
691	   field values. The  number is incremented when the changes
692	   made to the protocol add features which do not change the general
693	   message parsing algorithm, but which may add to the message
694	   semantics and imply additional capabilities of the sender. The
695	    number is incremented when the format of a message within
696	   the protocol is changed.

698	   The version of an HTTP message is indicated by an HTTP-Version
699	   field in the first line of the message. If the protocol version is
700	   not specified, the recipient must assume that the message is in the
701	   simple HTTP/0.9 format [6].

703	       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

705	   Note that the major and minor numbers should be treated as separate
706	   integers and that each may be incremented higher than a single
707	   digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in
708	   turn is lower than HTTP/12.3. Leading zeros should be ignored by
709	   recipients and never generated by senders.

711	   Applications sending Full-Request or Full-Response messages, as
712	   defined by this specification, must include an HTTP-Version of
713	   "HTTP/1.1". Use of this version number indicates that the sending
714	   application is at least conditionally compliant with this
715	   specification.

717	   HTTP/1.1 servers must:

719	      o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
720	        1.1 requests;

722	      o understand any valid request in the format of HTTP/0.9, 1.0, or
723	        1.1;

725	      o respond appropriately with a message in the same major version
726	        used by the client.

728	   HTTP/1.1 clients must:

730	      o recognize the format of the Status-Line for HTTP/1.0 and 1.1
731	        responses;

733	      o understand any valid response in the format of HTTP/0.9, 1.0,
734	        or 1.1.

736	   Proxy and gateway applications must be careful in forwarding
737	   requests that are received in a format different than that of the
738	   application's native HTTP version. Since the protocol version
739	   indicates the protocol capability of the sender, a proxy/gateway
740	   must never send a message with a version indicator which is greater
741	   than its native version; if a higher version request is received,
742	   the proxy/gateway must either downgrade the request version,
743	   respond with an error, or switch to tunnel behavior. Requests with
744	   a version lower than that of the application's native format may be
745	   upgraded before being forwarded; the proxy/gateway's response to
746	   that request must follow the server requirements listed above.

748	3.2  Uniform Resource Identifiers

750	   URIs have been known by many names: WWW addresses, Universal
751	   Document Identifiers, Universal Resource Identifiers [3], and
752	   finally the combination of Uniform Resource Locators (URL) [4] and
753	   Names (URN) [20]. As far as HTTP is concerned, Uniform Resource
754	   Identifiers are simply formatted strings which identify--via name,
755	   location, or any other characteristic--a network resource.

757	3.2.1 General Syntax

759	   URIs in HTTP can be represented in absolute form or relative to
760	   some known base URI [11], depending upon the context of their use.
761	   The two forms are differentiated by the fact that absolute URIs
762	   always begin with a scheme name followed by a colon.

764	       URI            = ( absoluteURI | relativeURI ) [ "#" fragment ]

766	       absoluteURI    = scheme ":" *( uchar | reserved )

768	       relativeURI    = net_path | abs_path | rel_path

770	       net_path       = "//" net_loc [ abs_path ]
771	       abs_path       = "/" rel_path
772	       rel_path       = [ path ] [ ";" params ] [ "?" query ]

774	       path           = fsegment *( "/" segment )
775	       fsegment       = 1*pchar
776	       segment        = *pchar

778	       params         = param *( ";" param )
779	       param          = *( pchar | "/" )

781	       scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
782	       net_loc        = *( pchar | ";" | "?" )
783	       query          = *( uchar | reserved )
784	       fragment       = *( uchar | reserved )

786	       pchar          = uchar | ":" | "@" | "&" | "="
787	       uchar          = unreserved | escape
788	       unreserved     = ALPHA | DIGIT | safe | extra | national

790	       escape         = "%" HEX HEX
791	       reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
792	       extra          = "!" | "*" | "'" | "(" | ")" | ","
793	       safe           = "$" | "-" | "_" | "." | "+"
794	       unsafe         = CTL | SP | <"> | "#" | "%" | "<" | ">"
795	       national       = 

798	   For definitive information on URL syntax and semantics, see RFC
799	   1738 [4] and RFC 1808 [11]. The BNF above includes national
800	   characters not allowed in valid URLs as specified by RFC 1738,
801	   since HTTP servers are not restricted in the set of unreserved
802	   characters allowed to represent the rel_path part of addresses, and
803	   HTTP proxies may receive requests for URIs not defined by RFC 1738.

805	3.2.2 http URL

807	   The "http" scheme is used to locate network resources via the HTTP
808	   protocol. This section defines the scheme-specific syntax and
809	   semantics for http URLs.

811	       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

813	       host           = 

817	       port           = *DIGIT

819	   If the port is empty or not given, port 80 is assumed. The
820	   semantics are that the identified resource is located at the server
821	   listening for TCP connections on that port of that host, and the
822	   Request-URI for the resource is abs_path. If the abs_path is not
823	   present in the URL, it must be given as "/" when used as a
824	   Request-URI for a resource (Section 5.1.2).

826	       Note: Although the HTTP protocol is independent of the
827	       transport layer protocol, the http URL only identifies
828	       resources by their TCP location, and thus non-TCP resources
829	       must be identified by some other URI scheme.

831	   The canonical form for "http" URLs is obtained by converting any
832	   UPALPHA characters in host to their LOALPHA equivalent (hostnames
833	   are case-insensitive), eliding the [ ":" port ] if the port is 80,
834	   and replacing an empty abs_path with "/".

836	3.3  Date/Time Formats

838	3.3.1 Full Date

840	   HTTP applications have historically allowed three different formats
841	   for the representation of date/time stamps:

843	       Sun, 06 Nov 1994 08:49:37 GMT    ; RFC 822, updated by RFC 1123
844	       Sunday, 06-Nov-94 08:49:37 GMT   ; RFC 850, obsoleted by RFC 1036
845	       Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

847	   The first format is preferred as an Internet standard and
848	   represents a fixed-length subset of that defined by RFC 1123 [8]
849	   (an update to RFC 822 [9]). The second format is in common use, but
850	   is based on the obsolete RFC 850 [12] date format and lacks a
851	   four-digit year. HTTP/1.1 clients and servers that parse the date
852	   value must accept all three formats, though they must only generate
853	   the RFC 1123 format for representing date/time stamps in HTTP
854	   message fields.

856	       Note: Recipients of date values are encouraged to be robust
857	       in accepting date values that may have been generated by
858	       non-HTTP applications, as is sometimes the case when
859	       retrieving or posting messages via proxies/gateways to SMTP
860	       or NNTP.

862	   All HTTP date/time stamps must be represented in Universal Time
863	   (UT), also known as Greenwich Mean Time (GMT), without exception.
864	   This is indicated in the first two formats by the inclusion of
865	   "GMT" as the three-letter abbreviation for time zone, and should be
866	   assumed when reading the asctime format.

868	       HTTP-date      = rfc1123-date | rfc850-date | asctime-date

870	       rfc1123-date   = wkday "," SP date1 SP time SP "GMT"
871	       rfc850-date    = weekday "," SP date2 SP time SP "GMT"
872	       asctime-date   = wkday SP date3 SP time SP 4DIGIT

874	       date1          = 2DIGIT SP month SP 4DIGIT
875	                        ; day month year (e.g., 02 Jun 1982)
876	       date2          = 2DIGIT "-" month "-" 2DIGIT
877	                        ; day-month-year (e.g., 02-Jun-82)
878	       date3          = month SP ( 2DIGIT | ( SP 1DIGIT ))
879	                        ; month day (e.g., Jun  2)

881	       time           = 2DIGIT ":" 2DIGIT ":" 2DIGIT
882	                        ; 00:00:00 - 23:59:59

884	       wkday          = "Mon" | "Tue" | "Wed"
885	                      | "Thu" | "Fri" | "Sat" | "Sun"

887	       weekday        = "Monday" | "Tuesday" | "Wednesday"
888	                      | "Thursday" | "Friday" | "Saturday" | "Sunday"

890	       month          = "Jan" | "Feb" | "Mar" | "Apr"
891	                      | "May" | "Jun" | "Jul" | "Aug"
892	                      | "Sep" | "Oct" | "Nov" | "Dec"

894	       Note: HTTP requirements for the date/time stamp format apply
895	       only to their usage within the protocol stream. Clients and
896	       servers are not required to use these formats for user
897	       presentation, request logging, etc.

899	3.3.2 Delta Seconds

901	   Some HTTP header fields allow a time value to be specified as an
902	   integer number of seconds, represented in decimal, after the time
903	   that the message was received. This format should only be used to
904	   represent short time periods or periods that cannot start until
905	   receipt of the message.

907	       delta-seconds  = 1*DIGIT

909	3.4  Character Sets

911	   HTTP uses the same definition of the term "character set" as that
912	   described for MIME:

914	        The term "character set" is used in this document to
915	        refer to a method used with one or more tables to convert
916	        a sequence of octets into a sequence of characters. Note
917	        that unconditional conversion in the other direction is
918	        not required, in that not all characters may be available
919	        in a given character set and a character set may provide
920	        more than one sequence of octets to represent a
921	        particular character. This definition is intended to
922	        allow various kinds of character encodings, from simple
923	        single-table mappings such as US-ASCII to complex table
924	        switching methods such as those that use ISO 2022's
925	        techniques. However, the definition associated with a
926	        MIME character set name must fully specify the mapping to
927	        be performed from octets to characters. In particular,
928	        use of external profiling information to determine the
929	        exact mapping is not permitted.

931	   HTTP character sets are identified by case-insensitive tokens. The
932	   complete set of tokens are defined by the IANA Character Set
933	   registry [19]. However, because that registry does not define a
934	   single, consistent token for each character set, we define here the
935	   preferred names for those character sets most likely to be used
936	   with HTTP entities. These character sets include those registered
937	   by RFC 1521 [7] -- the US-ASCII [21] and ISO-8859 [22] character
938	   sets -- and other names specifically recommended for use within MIME
939	   charset parameters.

941	     charset = "US-ASCII"
942	             | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
943	             | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
944	             | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
945	             | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
946	             | "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
947	             | token

949	   Although HTTP allows an arbitrary token to be used as a charset
950	   value, any token that has a predefined value within the IANA
951	   Character Set registry [19] must represent the character set
952	   defined by that registry. Applications should limit their use of
953	   character sets to those defined by the IANA registry.

955	       Note: This use of the term "character set" is more commonly
956	       referred to as a "character encoding." However, since HTTP
957	       and MIME share the same registry, it is important that the
958	       terminology also be shared.

960	3.5  Content Codings

962	   Content coding values are used to indicate an encoding
963	   transformation that has been or can be applied to a resource.
964	   Content codings are primarily used to allow a document to be
965	   compressed or encrypted without losing the identity of its
966	   underlying media type. Typically, the resource is stored in this
967	   encoding and only decoded before rendering or analogous usage.

969	       content-coding          = "gzip" | "compress" | token

971	       Note: For historical reasons, HTTP applications should
972	       consider "x-gzip" and "x-compress" to be equivalent to "gzip"
973	       and "compress", respectively.

975	   All content-coding values are case-insensitive. HTTP/1.1 uses
976	   content-coding values in the Accept-Encoding (Section 10.3) and
977	   Content-Encoding (Section 10.10) header fields. Although the value
978	   describes the content-coding, what is more important is that it
979	   indicates what decoding mechanism will be required to remove the
980	   encoding. Note that a single program may be capable of decoding
981	   multiple content-coding formats. Two values are defined by this
982	   specification:

984	   gzip
985	       An encoding format produced by the file compression program
986	       "gzip" (GNU zip) developed by Jean-loup Gailly. This format is
987	       typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. Gzip is
988	       available from the GNU project at
989	       .

991	   compress
992	       The encoding format produced by the file compression program
993	       "compress". This format is an adaptive Lempel-Ziv-Welch coding
994	       (LZW).

996	       Note: Use of program names for the identification of
997	       encoding formats is not desirable and should be discouraged
998	       for future encodings. Their use here is representative of
999	       historical practice, not good design.

1001	3.6  Transfer Codings

1003	   Transfer coding values are used to indicate an encoding
1004	   transformation that has been, can be, or may need to be applied to
1005	   an Entity-Body in order to ensure safe transport through the
1006	   network. This differs from a content coding in that the transfer
1007	   coding is a property of the message, not of the original resource.

1009	       transfer-coding         = "chunked" | token

1011	   All transfer-coding values are case-insensitive. HTTP/1.1 uses
1012	   transfer coding values in the Transfer-Encoding header field
1013	   (Section 10.39).

1015	   Transfer codings are analogous to the Content-Transfer-Encoding
1016	   values of MIME [7], which were designed to enable safe transport of
1017	   binary data over a 7-bit transport service. However, "safe
1018	   transport" has a different focus for an 8bit-clean transfer
1019	   protocol. In HTTP, the only unsafe characteristic of message bodies
1020	   is the difficulty in determining the exact body length
1021	   (Section 7.2.2), or the desire to encrypt data over a shared
1022	   transport.

1024	   All HTTP/1.1 applications must be able to receive and decode the
1025	   "chunked" transfer coding. The chunked encoding modifies the body
1026	   of a message in order to transfer it as a series of chunks, each
1027	   with its own size indicator, followed by an optional footer
1028	   containing entity-header fields. This allows dynamically-produced
1029	   content to be transferred along with the information necessary for
1030	   the recipient to verify that it has received the full message.

1032	       Chunked-Body   = *chunk
1033	                        "0" CRLF
1034	                        footer
1035	                        CRLF

1037	       chunk          = chunk-size CRLF
1038	                        chunk-data CRLF

1040	       chunk-size     = hex-no-zero *HEX
1041	       chunk-data     = chunk-size(OCTET)

1043	       footer         = *

1046	       hex-no-zero    = 

1048	   Note that the chunks are ended by a zero-sized chunk, followed by
1049	   the footer and terminated by an empty line. An example process for
1050	   decoding a Chunked-Body is presented in Appendix C.5.

1052	3.7  Media Types

1054	   HTTP uses Internet Media Types [17] in the Content-Type
1055	   (Section 10.15) and Accept (Section 10.1) header fields in order to
1056	   provide open and extensible data typing and type negotiation. For
1057	   mail applications, where there is no type negotiation between
1058	   sender and recipient, it is reasonable to put strict limits on the
1059	   set of allowed media types. With HTTP, where the sender and
1060	   recipient can communicate directly, applications are allowed more
1061	   freedom in the use of non-registered types. The following grammar
1062	   for media types is a superset of that for MIME because it does not
1063	   restrict itself to the official IANA and x-token types.

1065	       media-type     = type "/" subtype *( ";" parameter )
1066	       type           = token
1067	       subtype        = token

1069	    Parameters may follow the type/subtype in the form of
1070	   attribute/value pairs.

1072	       parameter      = attribute "=" value
1073	       attribute      = token
1074	       value          = token | quoted-string

1076	   The type, subtype, and parameter attribute names are
1077	   case-insensitive. Parameter values may or may not be
1078	   case-sensitive, depending on the semantics of the parameter name.
1079	   LWS should not be generated between the type and subtype, nor
1080	   between an attribute and its value.

1082	   If a given media-type value has been registered by the IANA, any
1083	   use of that value must be indicative of the registered data format.
1084	   Although HTTP allows the use of non-registered media types, such
1085	   usage must not conflict with the IANA registry. Data providers are
1086	   strongly encouraged to register their media types with IANA via the
1087	   procedures outlined in RFC 1590 [17].

1089	   All media-type's registered by IANA must be preferred over
1090	   extension tokens. However, HTTP does not limit applications to the
1091	   use of officially registered media types, nor does it encourage the
1092	   use of an "x-" prefix for unofficial types outside of explicitly
1093	   short experimental use between consenting applications.

1095	3.7.1 Canonicalization and Text Defaults

1097	   Media types are registered in a canonical form. In general, entity
1098	   bodies transferred via HTTP must be represented in the appropriate
1099	   canonical form prior to transmission. If the body has been encoded
1100	   via a Content-Encoding and/or Transfer-Encoding, the data must be
1101	   in canonical form prior to that encoding. However, HTTP modifies
1102	   the canonical form requirements for media of primary type "text"
1103	   and for "application" types consisting of text-like records.

1105	   HTTP redefines the canonical form of text media to allow multiple
1106	   octet sequences to indicate a text line break. In addition to the
1107	   preferred form of CRLF, HTTP applications must accept a bare CR or
1108	   LF alone as representing a single line break in text media.
1109	   Furthermore, if the text media is represented in a character set
1110	   which does not use octets 13 and 10 for CR and LF respectively, as
1111	   is the case for some multi-byte character sets, HTTP allows the use
1112	   of whatever octet sequence(s) is defined by that character set to
1113	   represent the equivalent of CRLF, bare CR, and bare LF. It is
1114	   assumed that any recipient capable of using such a character set
1115	   will know the appropriate octet sequence for representing line
1116	   breaks within that character set.

1118	       Note: This interpretation of line breaks applies only to the
1119	       contents of an Entity-Body and only after any
1120	       Transfer-Encoding and/or Content-Encoding has been removed.
1121	       All other HTTP constructs use CRLF exclusively to indicate a
1122	       line break. Content and transfer codings define their own
1123	       line break requirements.

1125	   A recipient of an HTTP text entity should translate the received
1126	   entity line breaks to the local line break conventions before
1127	   saving the entity external to the application and its cache;
1128	   whether this translation takes place immediately upon receipt of
1129	   the entity, or only when prompted by the user, is entirely up to
1130	   the individual application.

1132	   HTTP also redefines the default character set for text media in an
1133	   entity body. If a textual media type defines a charset parameter
1134	   with a registered default value of "US-ASCII", HTTP changes the
1135	   default to be "ISO-8859-1". Since the ISO-8859-1 [22] character set
1136	   is a superset of US-ASCII [21], this does not affect the
1137	   interpretation of entity bodies which only contain octets within
1138	   the US-ASCII character set (0 - 127). The presence of a charset
1139	   parameter value in a Content-Type header field overrides the
1140	   default.

1142	   It is recommended that the character set of an entity body be
1143	   labelled as the lowest common denominator of the character codes
1144	   used within a document, with the exception that no label is
1145	   preferred over the labels US-ASCII or ISO-8859-1.

1147	3.7.2 Multipart Types

1149	   MIME provides for a number of "multipart" types -- encapsulations of
1150	   one or more entities within a single message's Entity-Body. All
1151	   multipart types share a common syntax, as defined in Section 7.2.1
1152	   of RFC 1521 [7], and must include a boundary parameter as part of
1153	   the media type value. The message body is itself a protocol element
1154	   and must therefore use only CRLF to represent line breaks between
1155	   body-parts. Unlike in MIME, the epilogue of any multipart message
1156	   must be empty; HTTP applications must not transmit the epilogue
1157	   even if the original resource contains an epilogue.

1159	   In HTTP, multipart body-parts may contain header fields which are
1160	   significant to the meaning of that part. A URI entity-header field
1161	   (Section 10.42) should be included in the body-part for each
1162	   enclosed entity that can be identified by a URI.

1164	   In general, an HTTP user agent should follow the same or similar
1165	   behavior as a MIME user agent would upon receipt of a multipart
1166	   type. The following subtypes have been defined:

1168	   multipart/mixed

1170	       The mixed subtype is used when there are no additional semantics
1171	       implied beyond the fact that one or more entities are
1172	       encaspsulated. HTTP servers should not use this type to send
1173	       groups of entities if it is possible for those entities to be
1174	       individually retrieved and cached.

1176	   multipart/alternative

1178	       The alternative subtype implies that each of the parts is an
1179	       alternative format for the same information; the user agent
1180	       should present only the part most preferred by the user. HTTP
1181	       servers should use some form of content negotiation (Section 12)
1182	       instead of this type.

1184	   multipart/digest

1186	       The digest subtype implies that each of the parts is a message
1187	       (normally of type "message/rfc822") and thus the whole entity is
1188	       a collected sequence of message traffic. This type does not have
1189	       any special significance for HTTP.

1191	   multipart/form-data

1193	       The form-data subtype is defined by RFC 1867 [15] for use in
1194	       submitting the data that comes about from filling-in a form.

1196	   multipart/parallel

1198	       The parallel subtype implies that the parts should be presented
1199	       simultaneously by the user agent. This media type would be
1200	       appropriate for situations where simultaneous presentation is an
1201	       important aspect of the information, such as for audio-annotated
1202	       slides.

1204	       Note: This document does not define what is meant by
1205	       "simultaneous presentation". That is, HTTP does not provide
1206	       any means of synchronization between the parts in messages
1207	       of type "multipart/parallel".

1209	   Other multipart subtypes may be registered by IANA [19] according
1210	   to the procedures defined in RFC 1590 [17]. If an application
1211	   receives an unrecognized multipart subtype, the application must
1212	   treat it as being equivalent to "multipart/mixed".

1214	3.8  Product Tokens

1216	   Product tokens are used to allow communicating applications to
1217	   identify themselves via a simple product token, with an optional
1218	   slash and version designator. Most fields using product tokens also
1219	   allow subproducts which form a significant part of the application
1220	   to be listed, separated by whitespace. By convention, the products
1221	   are listed in order of their significance for identifying the
1222	   application.

1224	       product         = token ["/" product-version]
1225	       product-version = token

1227	   Examples:

1229	       User-Agent: CERN-LineMode/2.15 libwww/2.17b3

1231	       Server: Apache/0.8.4

1233	   Product tokens should be short and to the point -- use of them for
1234	   advertizing or other non-essential information is explicitly
1235	   forbidden. Although any token character may appear in a
1236	   product-version, this token should only be used for a version
1237	   identifier (i.e., successive versions of the same product should
1238	   only differ in the product-version portion of the product value).

1240	3.9  Quality Values

1242	   HTTP content negotiation (Section 12) uses short "floating point"
1243	   numbers to indicate the relative importance ("weight") of various
1244	   negotiable parameters. The weights are normalized to a real number
1245	   in the range 0 through 1, where 0 is the minimum and 1 the maximum
1246	   value. In order to discourage misuse of this feature, HTTP/1.1
1247	   applications must not generate more than three digits after the
1248	   decimal point. User configuration of these values should also be
1249	   limited in this fashion.

1251	       qvalue         = ( "0" [ "." 0*3DIGIT ] )
1252	                      | ( "." 0*3DIGIT )
1253	                      | ( "1" [ "." 0*3("0") ] )

1255	   "Quality values" is a slight misnomer, since these values actually
1256	   measure relative degradation in perceived quality. Thus, a value of
1257	   "0.8" represents a 20% degradation from the optimum rather than a
1258	   statement of 80% quality.

1260	3.10  Language Tags

1262	   A language tag identifies a natural language spoken, written, or
1263	   otherwise conveyed by human beings for communication of information
1264	   to other human beings. Computer languages are explicitly excluded.
1265	   HTTP uses language tags within the Accept-Language,
1266	   Content-Language, and URI-header fields.

1268	   The syntax and registry of HTTP language tags is the same as that
1269	   defined by RFC 1766 [1]. In summary, a language tag is composed of
1270	   1 or more parts: A primary language tag and a possibly empty series
1271	   of subtags:

1273	        language-tag  = primary-tag *( "-" subtag )

1275	        primary-tag   = 1*8ALPHA
1276	        subtag        = 1*8ALPHA

1278	   Whitespace is not allowed within the tag and all tags are
1279	   case-insensitive. The namespace of language tags is administered by
1280	   the IANA. Example tags include:

1282	       en, en-US, en-cockney, i-cherokee, x-pig-latin

1284	   where any two-letter primary-tag is an ISO 639 language
1285	   abbreviation and any two-letter initial subtag is an ISO 3166
1286	   country code.

1288	   In the context of the Accept-Language header (Section 10.4), a
1289	   language tag is not to be interpreted as a single token, as per RFC
1290	   1766, but as a hierarchy. A server should consider that it has a
1291	   match when a language tag received in an Accept-Language header
1292	   matches the initial portion of the language tag of a document. An
1293	   exact match should be preferred. This interpretation allows a
1294	   browser to send, for example:

1296	       Accept-Language: en-US, en; ql=0.95

1298	   when the intent is to access, in order of preference, documents in
1299	   US-English ("en-US"), 'plain' or 'international' English ("en"),
1300	   and any other variant of English (initial "en-").

1302	       Note: Using the language tag as a hierarchy does not imply
1303	       that all languages with a common prefix will be understood
1304	       by those fluent in one or more of those languages; it simply
1305	       allows the user to request this commonality when it is true
1306	       for that user.

1308	3.11  Logic Bags

1310	   A logic bag is a binary logic expression tree represented in prefix
1311	   notation using the generic bag syntax. Logic bags are used by HTTP
1312	   in the Unless (Section 10.40) header field as expressions to be
1313	   tested against the requested resource's header field
1314	   metainformation.

1316	       logic-bag   = "{" expression "}"

1318	       expression  = ( log-op 1*logic-bag )
1319	                   | ( rel-op 1*field-tuple )
1320	                   | ( "def" 1*field-name )

1322	       log-op      = "and" | "or" | "xor" | "not"
1323	       rel-op      = "eq" | "ne" | "lt" | "le" | "ge" | "gt" | "in"

1325	       field-tuple = "{" field-name ( bag | token | quoted-string ) "}"

1327	   The recursive structure of a logic bag allows a complex expression
1328	   tree to be formed by joining together subexpressions with logical
1329	   operators. Expressions with relational operators are used to
1330	   compare the requested resource's corresponding metainformation
1331	   (header field values) to those inside the expression field-tuples.
1332	   For example,

1334	       {or {ne {Content-MD5 "Q2hlY2sgSW50ZWdyaXR5IQ=="}}
1335	           {ne {Content-Length 10036}}
1336	           {ne {Content-Version "12.4.8"}}
1337	           {gt {Last-Modified "Mon, 04 Dec 1995 01:23:45 GMT"}}}

1339	   The expression is evaluated recursively by depth-first traversal
1340	   and bottom-up evaluation of the subexpressions until a true or
1341	   false value can be determined. Multiple operands to an operator
1342	   imply a conjunctive ("and") expression; e.g.,

1344	       {eq {A "a"} {B "b"} {C "c"}}

1346	   is equivalent to

1348	       {and {eq {A "a"}} {eq {B "b"}} {eq {C "c"}}}

1350	   Each expression is evaluated as defined by the operator:

1352	   and   True if all of the operands evaluate true.

1354	   or    True if any of the operands evaluate true.

1356	   xor   True if one and only one operand evaluates true.

1358	   not   True if all of the operands evaluate false.

1360	   eq    True if all field-tuple values exactly match the resource's
1361	         corresponding field values.

1363	   ne    True if all field-tuple values do not match the resource's
1364	         corresponding field values.

1366	   lt    True if, for each field-tuple, the resource's corresponding
1367	         field value is less than the one given in the expression.

1369	   le    True if, for each field-tuple, the resource's corresponding
1370	         field value is less than or equal to the one given in the
1371	         expression.

1373	   ge    True if, for each field-tuple, the resource's corresponding
1374	         field value is greater than or equal to the one given in the
1375	         expression.

1377	   gt    True if, for each field-tuple, the resource's corresponding
1378	         field value is greater than the one given in the expression.

1380	   in    True if, for each field-tuple, the resource's corresponding
1381	         field value contains the component value given in the
1382	         expression.

1384	   def   True if, for each field-name operand, the resource defines a
1385	         value for that field.

1387	   A field-tuple consists of a field-name (assumed to be an HTTP
1388	   header field name, though not constrained to those defined by this
1389	   specification) and the field-value component which is to be
1390	   compared against the resource's field value. The actual method of
1391	   comparison (e.g., byte equivalence, substring matching, numeric
1392	   order, substructure containment, etc.) is defined by the logical
1393	   definition of the operator and the type of field-value allowed for
1394	   that field-name. Server implementors must use an appropriate
1395	   comparison function for each type of field-value given in this
1396	   specification. The default functions for unrecognized fields are
1397	   numeric comparison (for values consisting of 1*DIGIT) and lexical
1398	   comparison (for all others).

1400	   Except for "ne", any comparison to a field not defined by the
1401	   resource evaluates to false.

1403	4.  HTTP Message

1405	4.1  Message Types

1407	   HTTP messages consist of requests from client to server and
1408	   responses from server to client.

1410	       HTTP-message   = Simple-Request            ; HTTP/0.9 messages
1411	                      | Simple-Response
1412	                      | Full-Request              ; HTTP/1.1 messages
1413	                      | Full-Response

1415	   Full-Request and Full-Response use the generic message format of
1416	   RFC 822 [9] for transferring entities. Both messages may include
1417	   optional header fields (also known as "headers") and an entity
1418	   body. The entity body is separated from the headers by a null line
1419	   (i.e., a line with nothing preceding the CRLF).

1421	       Full-Request   = Request-Line              ; Section 5.1
1422	                        *( General-Header         ; Section 4.3
1423	                        |  Request-Header         ; Section 5.2
1424	                        |  Entity-Header )        ; Section 7.1
1425	                        CRLF
1426	                        [ Entity-Body ]           ; Section 7.2

1428	       Full-Response  = Status-Line               ; Section 6.1
1429	                        *( General-Header         ; Section 4.3
1430	                        |  Response-Header        ; Section 6.2
1431	                        |  Entity-Header )        ; Section 7.1
1432	                        CRLF
1433	                        [ Entity-Body ]           ; Section 7.2

1435	   Simple-Request and Simple-Response do not allow the use of any
1436	   header information and are limited to a single request method (GET).

1438	       Simple-Request  = "GET" SP Request-URI CRLF

1440	       Simple-Response = [ Entity-Body ]

1442	   Use of the Simple-Request format is discouraged because it prevents
1443	   the client from using content negotiation and the server from
1444	   identifying the media type of the returned entity.

1446	4.2  Message Headers

1448	   HTTP header fields, which include General-Header (Section 4.3),
1449	   Request-Header (Section 5.2), Response-Header (Section 6.2), and
1450	   Entity-Header (Section 7.1) fields, follow the same generic format
1451	   as that given in Section 3.1 of RFC 822 [9]. Each header field
1452	   consists of a name followed by a colon (":") and the field value.
1453	   Field names are case-insensitive. The field value may be preceded
1454	   by any amount of LWS, though a single SP is preferred. Header
1455	   fields can be extended over multiple lines by preceding each extra
1456	   line with at least one SP or HT.

1458	       HTTP-header    = field-name ":" [ field-value ] CRLF

1460	       field-name     = token
1461	       field-value    = *( field-content | LWS )

1463	       field-content  = 

1467	   The order in which header fields are received is not significant.
1468	   However, it is "good practice" to send General-Header fields first,
1469	   followed by Request-Header or Response-Header fields prior to the
1470	   Entity-Header fields.

1472	   Multiple HTTP-header fields with the same field-name may be present
1473	   in a message if and only if the entire field-value for that header
1474	   field is defined as a comma-separated list [i.e., #(values)]. It
1475	   must be possible to combine the multiple header fields into one
1476	   "field-name: field-value" pair, without changing the semantics of
1477	   the message, by appending each subsequent field-value to the first,
1478	   each separated by a comma.

1480	4.3  General Header Fields

1482	   There are a few header fields which have general applicability for
1483	   both request and response messages, but which do not apply to the
1484	   entity being transferred. These headers apply only to the message
1485	   being transmitted.

1487	       General-Header = Cache-Control            ; Section 10.8
1488	                      | Connection               ; Section 10.9
1489	                      | Date                     ; Section 10.17
1490	                      | Forwarded                ; Section 10.20
1491	                      | Keep-Alive               ; Section 10.24
1492	                      | MIME-Version             ; Section 10.28
1493	                      | Pragma                   ; Section 10.29
1494	                      | Upgrade                  ; Section 10.41

1496	   General header field names can be extended reliably only in
1497	   combination with a change in the protocol version. However, new or
1498	   experimental header fields may be given the semantics of general
1499	   header fields if all parties in the communication recognize them to
1500	   be general header fields. Unrecognized header fields are treated as
1501	   Entity-Header fields.

1503	5. Request

1505	   A request message from a client to a server includes, within the
1506	   first line of that message, the method to be applied to the
1507	   resource, the identifier of the resource, and the protocol version
1508	   in use. For backwards compatibility with the more limited HTTP/0.9
1509	   protocol, there are two valid formats for an HTTP request:

1511	       Request        = Simple-Request | Full-Request

1513	       Simple-Request = "GET" SP Request-URI CRLF

1515	       Full-Request   = Request-Line              ; Section 5.1
1516	                        *( General-Header         ; Section 4.3
1517	                        |  Request-Header         ; Section 5.2
1518	                        |  Entity-Header )        ; Section 7.1
1519	                        CRLF
1520	                        [ Entity-Body ]           ; Section 7.2

1522	   If an HTTP/1.1 server receives a Simple-Request, it must respond
1523	   with an HTTP/0.9 Simple-Response. An HTTP/1.1 client must never
1524	   generate a Simple-Request.

1526	5.1  Request-Line

1528	   The Request-Line begins with a method token, followed by the
1529	   Request-URI and the protocol version, and ending with CRLF. The
1530	   elements are separated by SP characters. No CR or LF are allowed
1531	   except in the final CRLF sequence.

1533	       Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

1535	   Note that the difference between a Simple-Request and the
1536	   Request-Line of a Full-Request is the presence of the HTTP-Version
1537	   field and the availability of methods other than GET.

1539	5.1.1 Method

1541	   The Method token indicates the method to be performed on the
1542	   resource identified by the Request-URI. The method is
1543	   case-sensitive.

1545	       Method         = "OPTIONS"                ; Section 8.1
1546	                      | "GET"                    ; Section 8.2
1547	                      | "HEAD"                   ; Section 8.3
1548	                      | "POST"                   ; Section 8.4
1549	                      | "PUT"                    ; Section 8.5
1550	                      | "PATCH"                  ; Section 8.6
1551	                      | "COPY"                   ; Section 8.7
1552	                      | "MOVE"                   ; Section 8.8
1553	                      | "DELETE"                 ; Section 8.9
1554	                      | "LINK"                   ; Section 8.10
1555	                      | "UNLINK"                 ; Section 8.11
1556	                      | "TRACE"                  ; Section 8.12
1557	                      | "WRAPPED"                ; Section 8.13
1558	                      | extension-method

1560	       extension-method = token

1562	   The list of methods acceptable by a specific resource can be
1563	   specified in an Allow header field (Section 10.5). However, the
1564	   client is always notified through the return code of the response
1565	   whether a method is currently allowed on a specific resource, as
1566	   this can change dynamically. Servers should return the status code
1567	   405 (method not allowed) if the method is known by the server but
1568	   not allowed for the requested resource, and 501 (not implemented)
1569	   if the method is unrecognized or not implemented by the server. The
1570	   list of methods known by a server can be listed in a Public
1571	   response header field (Section 10.32).

1573	   The methods GET and HEAD must be supported by all general-purpose
1574	   servers. Servers which provide Last-Modified dates for resources
1575	   must also support the conditional GET method. All other methods are
1576	   optional; however, if the above methods are implemented, they must
1577	   be implemented with the same semantics as those specified in
1578	   Section 8.

1580	5.1.2 Request-URI

1582	   The Request-URI is a Uniform Resource Identifier (Section 3.2) and
1583	   identifies the resource upon which to apply the request.

1585	       Request-URI    = "*" | absoluteURI | abs_path

1587	   The three options for Request-URI are dependent on the nature of
1588	   the request. The asterisk "*" means that the request does not apply
1589	   to a particular resource, but to the server itself, and is only
1590	   allowed when the Method used does not necessarily apply to a
1591	   resource. One example would be

1593	       OPTIONS * HTTP/1.1

1595	   The absoluteURI form is only allowed when the request is being made
1596	   to a proxy. The proxy is requested to forward the request and
1597	   return the response. If the request is GET or HEAD and a prior
1598	   response is cached, the proxy may use the cached message if it
1599	   passes any restrictions in the Cache-Control and Expires header
1600	   fields. Note that the proxy may forward the request on to another
1601	   proxy or directly to the server specified by the absoluteURI. In
1602	   order to avoid request loops, a proxy must be able to recognize all
1603	   of its server names, including any aliases, local variations, and
1604	   the numeric IP address. An example Request-Line would be:

1606	       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

1608	   The most common form of Request-URI is that used to identify a
1609	   resource on an origin server or gateway. In this case, only the
1610	   absolute path of the URI is transmitted (see Section 3.2.1,
1611	   abs_path). For example, a client wishing to retrieve the resource
1612	   above directly from the origin server would create a TCP connection
1613	   to port 80 of the host "www.w3.org" and send the line:

1615	       GET /pub/WWW/TheProject.html HTTP/1.1

1617	   followed by the remainder of the Full-Request. Note that the
1618	   absolute path cannot be empty; if none is present in the original
1619	   URI, it must be given as "/" (the server root).

1621	   If a proxy receives a request without any path in the Request-URI
1622	   and the method used is capable of supporting the asterisk form of
1623	   request, then the last proxy on the request chain must forward the
1624	   request with "*" as the final Request-URI. For example, the request

1626	       OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

1628	   would be forwarded by the proxy as

1630	       OPTIONS * HTTP/1.1

1632	   after connecting to port 8001 of host "www.ics.uci.edu".

1634	   The Request-URI is transmitted as an encoded string, where some
1635	   characters may be escaped using the "% hex hex" encoding defined by
1636	   RFC 1738 [4]. The origin server must decode the Request-URI in
1637	   order to properly interpret the request.

1639	5.2  Request Header Fields

1641	   The request header fields allow the client to pass additional
1642	   information about the request, and about the client itself, to the
1643	   server. These fields act as request modifiers, with semantics
1644	   equivalent to the parameters on a programming language method
1645	   (procedure) invocation.

1647	       Request-Header = Accept                   ; Section 10.1
1648	                      | Accept-Charset           ; Section 10.2
1649	                      | Accept-Encoding          ; Section 10.3
1650	                      | Accept-Language          ; Section 10.4
1651	                      | Authorization            ; Section 10.6
1652	                      | From                     ; Section 10.21
1653	                      | Host                     ; Section 10.22
1654	                      | If-Modified-Since        ; Section 10.23
1655	                      | Proxy-Authorization      ; Section 10.31
1656	                      | Range                    ; Section 10.33
1657	                      | Referer                  ; Section 10.34
1658	                      | Unless                   ; Section 10.40
1659	                      | User-Agent               ; Section 10.43

1661	   Request-Header field names can be extended reliably only in
1662	   combination with a change in the protocol version. However, new or
1663	   experimental header fields may be given the semantics of request
1664	   header fields if all parties in the communication recognize them to
1665	   be request header fields. Unrecognized header fields are treated as
1666	   Entity-Header fields.

1668	6.  Response

1670	   After receiving and interpreting a request message, a server
1671	   responds in the form of an HTTP response message.

1673	       Response        = Simple-Response | Full-Response

1675	       Simple-Response = [ Entity-Body ]

1677	       Full-Response   = Status-Line               ; Section 6.1
1678	                         *( General-Header         ; Section 4.3
1679	                         |  Response-Header        ; Section 6.2
1680	                         |  Entity-Header )        ; Section 7.1
1681	                         CRLF
1682	                         [ Entity-Body ]           ; Section 7.2

1684	   A Simple-Response should only be sent in response to an HTTP/0.9
1685	   Simple-Request or if the server only supports the more limited
1686	   HTTP/0.9 protocol. If a client sends an HTTP/1.1 Full-Request and
1687	   receives a response that does not begin with a Status-Line, it
1688	   should assume that the response is a Simple-Response and parse it
1689	   accordingly. Note that the Simple-Response consists only of the
1690	   entity body and is terminated by the server closing the connection.

1692	6.1  Status-Line

1694	   The first line of a Full-Response message is the Status-Line,
1695	   consisting of the protocol version followed by a numeric status
1696	   code and its associated textual phrase, with each element separated
1697	   by SP characters. No CR or LF is allowed except in the final CRLF
1698	   sequence.

1700	       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

1702	   Since a status line always begins with the protocol version and
1703	   status code

1705	       "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

1707	   (e.g., "HTTP/1.1 200 "), the presence of that expression is
1708	   sufficient to differentiate a Full-Response from a Simple-Response.
1709	   Although the Simple-Response format may allow such an expression to
1710	   occur at the beginning of an entity body, and thus cause a
1711	   misinterpretation of the message if it was given in response to a
1712	   Full-Request, most HTTP/0.9 servers are limited to responses of
1713	   type "text/html" and therefore would never generate such a response.

1715	6.1.1 Status Code and Reason Phrase

1717	   The Status-Code element is a 3-digit integer result code of the
1718	   attempt to understand and satisfy the request. The Reason-Phrase is
1719	   intended to give a short textual description of the Status-Code.
1720	   The Status-Code is intended for use by automata and the
1721	   Reason-Phrase is intended for the human user. The client is not
1722	   required to examine or display the Reason-Phrase.

1724	   The first digit of the Status-Code defines the class of response.
1725	   The last two digits do not have any categorization role. There are
1726	   5 values for the first digit:

1728	      o 1xx: Informational - Request received, continuing process

1730	      o 2xx: Success - The action was successfully received,
1731	             understood, and accepted

1733	      o 3xx: Redirection - Further action must be taken in order to
1734	             complete the request

1736	      o 4xx: Client Error - The request contains bad syntax or cannot
1737	             be fulfilled

1739	      o 5xx: Server Error - The server failed to fulfill an apparently
1740	             valid request

1742	   The individual values of the numeric status codes defined for
1743	   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
1744	   presented below. The reason phrases listed here are only
1745	   recommended -- they may be replaced by local equivalents without
1746	   affecting the protocol. These codes are fully defined in Section 9.

1748	       Status-Code    = "100"   ; Continue
1749	                      | "101"   ; Switching Protocols
1750	                      | "200"   ; OK
1751	                      | "201"   ; Created
1752	                      | "202"   ; Accepted
1753	                      | "203"   ; Non-Authoritative Information
1754	                      | "204"   ; No Content
1755	                      | "205"   ; Reset Content
1756	                      | "206"   ; Partial Content
1757	                      | "300"   ; Multiple Choices
1758	                      | "301"   ; Moved Permanently
1759	                      | "302"   ; Moved Temporarily
1760	                      | "303"   ; See Other
1761	                      | "304"   ; Not Modified
1762	                      | "305"   ; Use Proxy
1763	                      | "400"   ; Bad Request
1764	                      | "401"   ; Unauthorized
1765	                      | "402"   ; Payment Required
1766	                      | "403"   ; Forbidden
1767	                      | "404"   ; Not Found
1768	                      | "405"   ; Method Not Allowed
1769	                      | "406"   ; None Acceptable
1770	                      | "407"   ; Proxy Authentication Required
1771	                      | "408"   ; Request Timeout
1772	                      | "409"   ; Conflict
1773	                      | "410"   ; Gone
1774	                      | "411"   ; Length Required
1775	                      | "412"   ; Unless True
1776	                      | "500"   ; Internal Server Error
1777	                      | "501"   ; Not Implemented
1778	                      | "502"   ; Bad Gateway
1779	                      | "503"   ; Service Unavailable
1780	                      | "504"   ; Gateway Timeout
1781	                      | extension-code

1783	       extension-code = 3DIGIT

1785	       Reason-Phrase  = *

1787	   HTTP status codes are extensible. HTTP applications are not
1788	   required to understand the meaning of all registered status codes,
1789	   though such understanding is obviously desirable. However,
1790	   applications must understand the class of any status code, as
1791	   indicated by the first digit, and treat any unrecognized response
1792	   as being equivalent to the x00 status code of that class, with the
1793	   exception that an unrecognized response must not be cached. For
1794	   example, if an unrecognized status code of 431 is received by the
1795	   client, it can safely assume that there was something wrong with
1796	   its request and treat the response as if it had received a 400
1797	   status code. In such cases, user agents should present to the user
1798	   the entity returned with the response, since that entity is likely
1799	   to include human-readable information which will explain the
1800	   unusual status.

1802	6.2  Response Header Fields

1804	   The response header fields allow the server to pass additional
1805	   information about the response which cannot be placed in the
1806	   Status-Line. These header fields are not intended to give
1807	   information about an Entity-Body returned in the response, but
1808	   about access to the resource or the server itself.

1810	       Response-Header= Location                 ; Section 10.27
1811	                      | Proxy-Authenticate       ; Section 10.30
1812	                      | Public                   ; Section 10.32
1813	                      | Retry-After              ; Section 10.36
1814	                      | Server                   ; Section 10.37
1815	                      | WWW-Authenticate         ; Section 10.44

1817	   Response-Header field names can be extended reliably only in
1818	   combination with a change in the protocol version. However, new or
1819	   experimental header fields may be given the semantics of response
1820	   header fields if all parties in the communication recognize them to
1821	   be response header fields. Unrecognized header fields are treated
1822	   as Entity-Header fields.

1824	7.  Entity

1826	   Full-Request and Full-Response messages may transfer an entity
1827	   within some requests and responses. An entity consists of
1828	   Entity-Header fields and (usually) an Entity-Body. In this section,
1829	   both sender and recipient refer to either the client or the server,
1830	   depending on who sends and who receives the entity.

1832	7.1  Entity Header Fields

1834	   Entity-Header fields define optional metainformation about the
1835	   Entity-Body or, if no body is present, about the resource
1836	   identified by the request.

1838	       Entity-Header  = Allow                    ; Section 10.5
1839	                      | Content-Encoding         ; Section 10.10
1840	                      | Content-Language         ; Section 10.11
1841	                      | Content-Length           ; Section 10.12
1842	                      | Content-MD5              ; Section 10.13
1843	                      | Content-Range            ; Section 10.14
1844	                      | Content-Type             ; Section 10.15
1845	                      | Content-Version          ; Section 10.16
1846	                      | Derived-From             ; Section 10.18
1847	                      | Expires                  ; Section 10.19
1848	                      | Last-Modified            ; Section 10.25
1849	                      | Link                     ; Section 10.26
1850	                      | Title                    ; Section 10.38
1851	                      | Transfer-Encoding        ; Section 10.39
1852	                      | URI-header               ; Section 10.42
1853	                      | extension-header

1855	       extension-header=HTTP-header

1857	   The extension-header mechanism allows additional Entity-Header
1858	   fields to be defined without changing the protocol, but these
1859	   fields cannot be assumed to be recognizable by the recipient.
1860	   Unrecognized header fields should be ignored by the recipient and
1861	   forwarded by proxies.

1863	7.2  Entity Body

1865	   The entity body (if any) sent with an HTTP request or response is
1866	   in a format and encoding defined by the Entity-Header fields.

1868	       Entity-Body    = *OCTET

1870	   An entity body is included with a request message only when the
1871	   request method calls for one. The presence of an entity body in a
1872	   request is signaled by the inclusion of a Content-Length and/or
1873	   Content-Type header field in the request message headers.

1875	   For response messages, whether or not an entity body is included
1876	   with a message is dependent on both the request method and the
1877	   response code. All responses to the HEAD request method must not
1878	   include a body, even though the presence of entity header fields
1879	   may lead one to believe they do. All 1xx (informational), 204 (no
1880	   content), and 304 (not modified) responses must not include a body.
1881	   All other responses must include an entity body or a Content-Length
1882	   header field defined with a value of zero (0).

1884	7.2.1 Type

1886	   When an entity body is included with a message, the data type of
1887	   that body is determined via the header fields Content-Type,
1888	   Content-Encoding, and Transfer-Encoding. These define a
1889	   three-layer, ordered encoding model:

1891	       entity-body :=
1892	          Transfer-Encoding( Content-Encoding( Content-Type( data ) ) )

1894	   The default for both encodings is none (i.e., the identity
1895	   function). Content-Type specifies the media type of the underlying
1896	   data. Content-Encoding may be used to indicate any additional
1897	   content codings applied to the type, usually for the purpose of
1898	   data compression, that are a property of the resource requested.
1899	   Transfer-Encoding may be used to indicate any additional transfer
1900	   codings applied by an application to ensure safe and proper
1901	   transfer of the message. Note that Transfer-Encoding is a property
1902	   of the message, not of the resource.

1904	   Any HTTP/1.1 message containing an entity body should include a
1905	   Content-Type header field defining the media type of that body. If
1906	   and only if the media type is not given by a Content-Type header,
1907	   as is the case for Simple-Response messages, the recipient may
1908	   attempt to guess the media type via inspection of its content
1909	   and/or the name extension(s) of the URL used to identify the
1910	   resource. If the media type remains unknown, the recipient should
1911	   treat it as type "application/octet-stream".

1913	7.2.2 Length

1915	   When an entity body is included with a message, the length of that
1916	   body may be determined in one of several ways. If a Content-Length
1917	   header field is present, its value in bytes represents the length
1918	   of the entity body. Otherwise, the body length is determined by the
1919	   Transfer-Encoding (if the "chunked" transfer coding has been
1920	   applied), by the Content-Type (for multipart types with an explicit
1921	   end-of-body delimiter), or by the server closing the connection.

1923	       Note: Any response message which must not include an entity
1924	       body (such as the 1xx, 204, and 304 responses and any
1925	       response to a HEAD request) is always terminated by the
1926	       first empty line after the header fields, regardless of the
1927	       entity header fields present in the message.

1929	   Closing the connection cannot be used to indicate the end of a
1930	   request body, since it leaves no possibility for the server to send
1931	   back a response. For compatibility with HTTP/1.0 applications,
1932	   HTTP/1.1 requests containing an entity body must include a valid
1933	   Content-Length header field unless the server is known to be
1934	   HTTP/1.1 compliant. HTTP/1.1 servers must accept the "chunked"
1935	   transfer coding (Section 3.6) and multipart media types
1936	   (Section 3.7.2), thus allowing either mechanism to be used for a
1937	   request when Content-Length is unknown.

1939	   If a request contains an entity body and Content-Length is not
1940	   specified, the server should respond with 400 (bad request) if it
1941	   cannot determine the length of the request message's content, or
1942	   with 411 (length required) if it wishes to insist on receiving a
1943	   valid Content-Length.

1945	   Messages must not include both a Content-Length header field and
1946	   the "chunked" transfer coding. If both are received, the
1947	   Content-Length must be ignored.

1949	   When a Content-Length is given in a message where an entity body is
1950	   allowed, its field value must exactly match the number of OCTETs in
1951	   the entity body. HTTP/1.1 user agents must notify the user when an
1952	   invalid length is received and detected.

1954	8.  Method Definitions

1956	   The set of common methods for HTTP/1.1 is defined below. Although
1957	   this set can be expanded, additional methods cannot be assumed to
1958	   share the same semantics for separately extended clients and
1959	   servers.

1961	   The semantics of all methods may be affected by the presence of an
1962	   Unless request header field, as described in Section 10.40.

1964	8.1  OPTIONS

1966	   The OPTIONS method represents a request for information about the
1967	   communication options available on the request/response chain
1968	   identified by the Request-URI. This method allows the client to
1969	   determine the options and/or requirements associated with a
1970	   resource, or the capabilities of a server, without implying a
1971	   resource action or initiating a resource retrieval.

1973	   Unless the server's response is an error, the response must not
1974	   include entity information other than what can be considered as
1975	   communication options (e.g., Allow is appropriate, but Content-Type
1976	   is not) and must include a Content-Length with a value of zero (0).
1977	   Responses to this method are not cachable.

1979	   If the Request-URI is an asterisk ("*"), the OPTIONS request is
1980	   intended to apply to the server as a whole. A 200 response should
1981	   include any header fields which indicate optional features
1982	   implemented by the server (e.g., Public), including any extensions
1983	   not defined by this specification, in addition to any applicable
1984	   general or response header fields. As described in Section 5.1.2,
1985	   an "OPTIONS *" request can be applied through a proxy by specifying
1986	   the destination server in the Request-URI without any path
1987	   information.

1989	   If the Request-URI is not an asterisk, the OPTIONS request applies
1990	   only to the options that are available when communicating with that
1991	   resource. A 200 response should include any header fields which
1992	   indicate optional features implemented by the server and applicable
1993	   to that resource (e.g., Allow), including any extensions not
1994	   defined by this specification, in addition to any applicable
1995	   general or response header fields. If the OPTIONS request passes
1996	   through a proxy, the proxy must edit the response to exclude those
1997	   options known to be unavailable through that proxy.

1999	8.2  GET

2001	   The GET method means retrieve whatever information (in the form of
2002	   an entity) is identified by the Request-URI. If the Request-URI
2003	   refers to a data-producing process, it is the produced data which
2004	   shall be returned as the entity in the response and not the source
2005	   text of the process, unless that text happens to be the output of
2006	   the process.

2008	   The semantics of the GET method change to a "conditional GET" if
2009	   the request message includes an If-Modified-Since header field. A
2010	   conditional GET method requests that the identified resource be
2011	   transferred only if it has been modified since the date given by
2012	   the If-Modified-Since header, as described in Section 10.23. The
2013	   conditional GET method is intended to reduce unnecessary network
2014	   usage by allowing cached entities to be refreshed without requiring
2015	   multiple requests or transferring data already held by the client.

2017	   The semantics of the GET method change to a "partial GET" if the
2018	   request message includes a Range header field. A partial GET
2019	   requests that only part of the identified resource be transferred,
2020	   as described in Section 10.33. The partial GET method is intended
2021	   to reduce unnecessary network usage by allowing partially-retrieved
2022	   entities to be completed without transferring data already held by
2023	   the client.

2025	   The response to a GET request may be cachable if and only if it
2026	   meets the requirements for HTTP caching described in Section 13.

2028	8.3  HEAD

2030	   The HEAD method is identical to GET except that the server must not
2031	   return any Entity-Body in the response. The metainformation
2032	   contained in the HTTP headers in response to a HEAD request should
2033	   be identical to the information sent in response to a GET request.
2034	   This method can be used for obtaining metainformation about the
2035	   resource identified by the Request-URI without transferring the
2036	   Entity-Body itself. This method is often used for testing hypertext
2037	   links for validity, accessibility, and recent modification.

2039	   The response to a HEAD request may be cachable in the sense that
2040	   the information contained in the response may be used to update a
2041	   previously cached entity from that resource. If the new field
2042	   values indicate that the cached entity differs from the current
2043	   resource (as would be indicated by a change in Content-Length,
2044	   Content-MD5, or Content-Version), then the cache must discard the
2045	   cached entity.

2047	   There is no "conditional HEAD" or "partial HEAD" request analogous
2048	   to those associated with the GET method. If an If-Modified-Since
2049	   and/or Range header field is included with a HEAD request, they
2050	   should be ignored.

2052	8.4  POST

2054	   The POST method is used to request that the destination server
2055	   accept the entity enclosed in the request as a new subordinate of
2056	   the resource identified by the Request-URI in the Request-Line.
2057	   POST is designed to allow a uniform method to cover the following
2058	   functions:

2060	      o Annotation of existing resources;

2062	      o Posting a message to a bulletin board, newsgroup, mailing list,
2063	        or similar group of articles;

2065	      o Providing a block of data, such as the result of submitting a
2066	        form [5], to a data-handling process;

2068	      o Extending a database through an append operation.

2070	   The actual function performed by the POST method is determined by
2071	   the server and is usually dependent on the Request-URI. The posted
2072	   entity is subordinate to that URI in the same way that a file is
2073	   subordinate to a directory containing it, a news article is
2074	   subordinate to a newsgroup to which it is posted, or a record is
2075	   subordinate to a database.

2077	   HTTP/1.1 allows for a two-phase process to occur in accepting and
2078	   processing a POST request. If the media type of the posted entity
2079	   is not "application/x-www-form-urlencoded" [5], an HTTP/1.1 client
2080	   must pause between sending the message header fields (including the
2081	   empty line signifying the end of the headers) and sending the
2082	   message body; the duration of the pause is five (5) seconds or
2083	   until a response is received from the server, whichever is shorter.
2084	   If no response is received during the pause period, or if the
2085	   initial response is 100 (continue), the client may continue sending
2086	   the POST request. If the response indicates an error, the client
2087	   must discontinue the request and close the connection with the
2088	   server after reading the response.

2090	   Upon receipt of a POST request, the server must examine the header
2091	   fields and determine whether or not the client should continue its
2092	   request. If any of the header fields indicate the request is
2093	   insufficient or unacceptable to the server (i.e., will result in a
2094	   4xx or 5xx response), or if the server can determine the response
2095	   without reading the entity body (e.g., a 301 or 302 response due to
2096	   an old Request-URI), the server must send that response immediately
2097	   upon its determination. If, on the other hand, the request appears
2098	   (at least initially) to be acceptable and the client has indicated
2099	   HTTP/1.1 compliance, the server must transmit an interim 100
2100	   response message after receiving the empty line terminating the
2101	   request headers and continue processing the request. After
2102	   processing has finished, a final response message must be sent to
2103	   indicate the actual result of the request. A 100 response should
2104	   not be sent in response to an HTTP/1.0 request except under
2105	   experimental conditions, since an HTTP/1.0 client may mistake the
2106	   100 response for the final response.

2108	   For compatibility with HTTP/1.0 applications, all POST requests
2109	   must include a valid Content-Length header field unless the server
2110	   is known to be HTTP/1.1 compliant. When sending a POST request to
2111	   an HTTP/1.1 server, a client must use at least one of: a valid
2112	   Content-Length, a multipart Content-Type, or the "chunked"
2113	   Transfer-Encoding. The server should respond with a 400 (bad
2114	   request) message if it cannot determine the length of the request
2115	   message's content, or with 411 (length required) if it wishes to
2116	   insist on receiving a valid Content-Length.

2118	   The client can suggest one or more URIs for the new resource by
2119	   including a URI header field in the request. However, the server
2120	   should treat those URIs as advisory and may store the entity under
2121	   a different URI, additional URIs, or without any URI.

2123	   The client may apply relationships between the new resource and
2124	   other existing resources by including Link header fields, as
2125	   described in Section 10.26. The server may use the Link information
2126	   to perform other operations as a result of the new resource being
2127	   added. For example, lists and indexes might be updated. However, no
2128	   mandatory operation is imposed on the origin server. The origin
2129	   server may also generate its own or additional links to other
2130	   resources.

2132	   A successful POST does not require that the entity be created as a
2133	   resource on the origin server or made accessible for future
2134	   reference. That is, the action performed by the POST method might
2135	   not result in a resource that can be identified by a URI. In this
2136	   case, either 200 (ok) or 204 (no content) is the appropriate
2137	   response status, depending on whether or not the response includes
2138	   an entity that describes the result.

2140	   If a resource has been created on the origin server, the response
2141	   should be 201 (created) and contain an entity (preferably of type
2142	   "text/html") which describes the status of the request and refers
2143	   to the new resource.

2145	   Responses to this method are not cachable. However, the 303 (see
2146	   other) response can be used to direct the user agent to retrieve a
2147	   cachable resource.

2149	8.5  PUT

2151	   The PUT method requests that the enclosed entity be stored under
2152	   the supplied Request-URI. If the Request-URI refers to an already
2153	   existing resource, the enclosed entity should be considered as a
2154	   modified version of the one residing on the origin server. If the
2155	   Request-URI does not point to an existing resource, and that URI is
2156	   capable of being defined as a new resource by the requesting user
2157	   agent, the origin server can create the resource with that URI. If
2158	   a new resource is created, the origin server must inform the user
2159	   agent via the 201 (created) response. If an existing resource is
2160	   modified, either the 200 (ok) or 204 (no content) response codes
2161	   should be sent to indicate successful completion of the request. If
2162	   the resource could not be created or modified with the Request-URI,
2163	   an appropriate error response should be given that reflects the
2164	   nature of the problem.

2166	   If the request passes through a cache and the Request-URI
2167	   identifies a currently cached entity, that entity must be removed
2168	   from the cache. Responses to this method are not cachable.

2170	   The fundamental difference between the POST and PUT requests is
2171	   reflected in the different meaning of the Request-URI. The URI in a
2172	   POST request identifies the resource that will handle the enclosed
2173	   entity as an appendage. That resource may be a data-accepting
2174	   process, a gateway to some other protocol, or a separate entity
2175	   that accepts annotations. In contrast, the URI in a PUT request
2176	   identifies the entity enclosed with the request -- the user agent
2177	   knows what URI is intended and the server must not attempt to apply
2178	   the request to some other resource. If the server desires that the
2179	   request be applied to a different URI, it must send a 301 (moved
2180	   permanently) response; the user agent may then make its own
2181	   decision regarding whether or not to redirect the request.

2183	   A single resource may be identified by many different URIs. For
2184	   example, an article may have a URI for identifying "the current
2185	   version" which is separate from the URI identifying each particular
2186	   version. In this case, a PUT request on a general URI may result in
2187	   several other URIs being defined by the origin server. The user
2188	   agent should be informed of these URIs via one or more URI header
2189	   fields in the response.

2191	   HTTP/1.1 allows for a two-phase process to occur in accepting and
2192	   processing a PUT request. An HTTP/1.1 client must pause between
2193	   sending the message header fields (including the empty line
2194	   signifying the end of the headers) and sending the message body;
2195	   the duration of the pause is five (5) seconds or until a response
2196	   is received from the server, whichever is shorter. If no response
2197	   is received during the pause period, or if the initial response is
2198	   100 (continue), the client may continue sending the PUT request. If
2199	   the response indicates an error, the client must discontinue the
2200	   request and close the connection with the server after reading the
2201	   response.

2203	   Upon receipt of a PUT request, the server must examine the header
2204	   fields and determine whether or not the client should continue its
2205	   request. If any of the header fields indicate the request is
2206	   insufficient or unacceptable to the server (i.e., will result in a
2207	   4xx or 5xx response), or if the server can determine the response
2208	   without reading the entity body (e.g., a 301 or 302 response due to
2209	   an old Request-URI), the server must send that response immediately
2210	   upon its determination. If, on the other hand, the request appears
2211	   (at least initially) to be acceptable and the client has indicated
2212	   HTTP/1.1 compliance, the server must transmit an interim 100
2213	   response message after receiving the empty line terminating the
2214	   request headers and continue processing the request. After
2215	   processing has finished, a final response message must be sent to
2216	   indicate the actual result of the request. A 100 response should
2217	   not be sent in response to an HTTP/1.0 request except under
2218	   experimental conditions, since an HTTP/1.0 client may mistake the
2219	   100 response for the final response.

2221	   For compatibility with HTTP/1.0 applications, all PUT requests must
2222	   include a valid Content-Length header field unless the server is
2223	   known to be HTTP/1.1 compliant. When sending a PUT request to an
2224	   HTTP/1.1 server, a client must use at least one of: a valid
2225	   Content-Length, a multipart Content-Type, or the "chunked"
2226	   Transfer-Encoding. The server should respond with a 400 (bad
2227	   request) message if it cannot determine the length of the request
2228	   message's content, or with 411 (length required) if it wishes to
2229	   insist on receiving a valid Content-Length.

2231	   The client can create or modify relationships between the enclosed
2232	   entity and other existing resources by including Link header
2233	   fields, as described in Section 10.26. As with POST, the server may
2234	   use the Link information to perform other operations as a result of
2235	   the request. However, no mandatory operation is imposed on the
2236	   origin server. The origin server may generate its own or additional
2237	   links to other resources.

2239	   The actual method for determining how the resource is placed, and
2240	   what happens to its predecessor, is defined entirely by the origin
2241	   server. If version control is implemented by the origin server,
2242	   then Link relationships should be defined by the server to help
2243	   identify and control revisions to a resource. If the entity being
2244	   PUT was derived from an existing resource which included a
2245	   Content-Version header field, the new entity must include a
2246	   Derived-From header field corresponding to the value of the
2247	   original Content-Version header field. Multiple Derived-From values
2248	   may be included if the entity was derived from multiple resources
2249	   with Content-Version information. Applications are encouraged to
2250	   use these fields for constructing versioning relationships and
2251	   resolving version conflicts.

2253	8.6  PATCH

2255	   The PATCH method is similar to PUT except that the entity contains
2256	   a list of differences between the original version of the resource
2257	   identified by the Request-URI and the desired content of the
2258	   resource after the PATCH action has been applied. The list of
2259	   differences is in a format defined by the media type of the entity
2260	   (e.g., "application/diff") and must include sufficient information
2261	   to allow the server to recreate the changes necessary to convert
2262	   the original version of the resource to the desired version.

2264	   If the request passes through a cache and the Request-URI
2265	   identifies a currently cached entity, that entity must be removed
2266	   from the cache. Responses to this method are not cachable.

2268	   HTTP/1.1 allows for a two-phase process to occur in accepting and
2269	   processing a PATCH request. An HTTP/1.1 client must pause between
2270	   sending the message header fields (including the empty line
2271	   signifying the end of the headers) and sending the message body;
2272	   the duration of the pause is five (5) seconds or until a response
2273	   is received from the server, whichever is shorter. If no response
2274	   is received during the pause period, or if the initial response is
2275	   100 (continue), the client may continue sending the PATCH request.
2276	   If the response indicates an error, the client must discontinue the
2277	   request and close the connection with the server after reading the
2278	   response.

2280	   Upon receipt of a PATCH request, the server must examine the header
2281	   fields and determine whether or not the client should continue its
2282	   request. If any of the header fields indicate the request is
2283	   insufficient or unacceptable to the server (i.e., will result in a
2284	   4xx or 5xx response), or if the server can determine the response
2285	   without reading the entity body (e.g., a 301 or 302 response due to
2286	   an old Request-URI), the server must send that response immediately
2287	   upon its determination. If, on the other hand, the request appears
2288	   (at least initially) to be acceptable and the client has indicated
2289	   HTTP/1.1 compliance, the server must transmit an interim 100
2290	   response message after receiving the empty line terminating the
2291	   request headers and continue processing the request. After
2292	   processing has finished, a final response message must be sent to
2293	   indicate the actual result of the request. A 100 response should
2294	   not be sent in response to an HTTP/1.0 request except under
2295	   experimental conditions, since an HTTP/1.0 client may mistake the
2296	   100 response for the final response.

2298	   For compatibility with HTTP/1.0 applications, all PATCH requests
2299	   must include a valid Content-Length header field unless the server
2300	   is known to be HTTP/1.1 compliant. When sending a PATCH request to
2301	   an HTTP/1.1 server, a client must use at least one of: a valid
2302	   Content-Length, a multipart Content-Type, or the "chunked"
2303	   Transfer-Encoding. The server should respond with a 400 (bad
2304	   request) message if it cannot determine the length of the request
2305	   message's content, or with 411 (length required) if it wishes to
2306	   insist on receiving a valid Content-Length.

2308	   The client can create or modify relationships between the new
2309	   resource and other existing resources by including Link header
2310	   fields, as described in Section 10.26. As with POST, the server may
2311	   use the Link information to perform other operations as a result of
2312	   the request. However, no mandatory operation is imposed on the
2313	   origin server. The origin server may generate its own or additional
2314	   links to other resources.

2316	   The actual method for determining how the patched resource is
2317	   placed, and what happens to its predecessor, is defined entirely by
2318	   the origin server. If version control is implemented by the origin
2319	   server, then Link relationships should be defined by the server to
2320	   help identify and control revisions to a resource. If the original
2321	   version of the resource being patched included a Content-Version
2322	   header field, the request entity must include a Derived-From header
2323	   field corresponding to the value of the original Content-Version
2324	   header field. Applications are encouraged to use these fields for
2325	   constructing versioning relationships and resolving version
2326	   conflicts.

2328	8.7  COPY

2330	   The COPY method requests that the resource identified by the
2331	   Request-URI be copied to the location(s) given in the URI header
2332	   field of the request. Responses to this method are not cachable.

2334	8.8  MOVE

2336	   The MOVE method requests that the resource identified by the
2337	   Request-URI be moved to the location(s) given in the URI header
2338	   field of the request. This method is equivalent to a COPY
2339	   immediately followed by a DELETE, but enables both to occur within
2340	   a single transaction.

2342	   If the request passes through a cache and the Request-URI
2343	   identifies a currently cached entity, that entity must be removed
2344	   from the cache. Responses to this method are not cachable.

2346	8.9  DELETE

2348	   The DELETE method requests that the origin server delete the
2349	   resource identified by the Request-URI. This method may be
2350	   overridden by human intervention (or other means) on the origin
2351	   server. The client cannot be guaranteed that the operation has been
2352	   carried out, even if the status code returned from the origin
2353	   server indicates that the action has been completed successfully.
2354	   However, the server should not indicate success unless, at the time
2355	   the response is given, it intends to delete the resource or move it
2356	   to an inaccessible location.

2358	   A successful response should be 200 (ok) if the response includes
2359	   an entity describing the status, 202 (accepted) if the action has
2360	   not yet been enacted, or 204 (no content) if the response is OK but
2361	   does not include an entity.

2363	   If the request passes through a cache and the Request-URI
2364	   identifies a currently cached entity, that entity must be removed
2365	   from the cache. Responses to this method are not cachable.

2367	8.10  LINK

2369	   The LINK method establishes one or more Link relationships between
2370	   the existing resource identified by the Request-URI and other
2371	   existing resources. The difference between LINK and other methods
2372	   allowing links to be established between resources is that the LINK
2373	   method does not allow any Entity-Body to be sent in the request and
2374	   does not directly result in the creation of new resources.

2376	   If the request passes through a cache and the Request-URI
2377	   identifies a currently cached entity, that entity must be removed
2378	   from the cache. Responses to this method are not cachable.

2380	8.11  UNLINK

2382	   The UNLINK method removes one or more Link relationships from the
2383	   existing resource identified by the Request-URI. These
2384	   relationships may have been established using the LINK method or by
2385	   any other method supporting the Link header. The removal of a link
2386	   to a resource does not imply that the resource ceases to exist or
2387	   becomes inaccessible for future references.

2389	   If the request passes through a cache and the Request-URI
2390	   identifies a currently cached entity, that entity must be removed
2391	   from the cache. Responses to this method are not cachable.

2393	8.12  TRACE

2395	   The TRACE method requests that the server identified by the
2396	   Request-URI reflect whatever is received back to the client as the
2397	   entity body of the response. In this way, the client can see what
2398	   is being received at the other end of the request chain, and may
2399	   use this data for testing or diagnostic information.

2401	   If successful, the response should contain the entire, unedited
2402	   request message in the entity body, with a Content-Type of
2403	   "message/http", "application/http", or "text/plain". Responses to
2404	   this method are not cachable.

2406	8.13  WRAPPED

2408	   The WRAPPED method allows a client to send one or more encapsulated
2409	   requests to the server identified by the Request-URI. This method
2410	   is intended to allow the request(s) to be wrapped together,
2411	   possibly encrypted in order to improve the security and/or privacy
2412	   of the request, and delivered for unwrapping by the destination
2413	   server. Upon receipt of the WRAPPED request, the destination server
2414	   must unwrap the message and feed it to the appropriate protocol
2415	   handler as if it were an incoming request stream.

2417	   Responses to this method are not cachable. Applications should not
2418	   use this method for making requests that would normally be public
2419	   and cachable.

2421	   The request entity must include at least one encapsulated message,
2422	   with the media type identifying the protocol of that message. For
2423	   example, if the wrapped request is another HTTP request message,
2424	   then the media type must be either "message/http" (for a single
2425	   message) or "application/http" (for a request stream containing one
2426	   or more requests), with any codings identied by the
2427	   Content-Encoding and Transfer-Encoding header fields.

2429	   HTTP/1.1 allows for a two-phase process to occur in accepting and
2430	   processing a WRAPPED request. An HTTP/1.1 client must pause between
2431	   sending the message header fields (including the empty line
2432	   signifying the end of the headers) and sending the message body;
2433	   the duration of the pause is five (5) seconds or until a response
2434	   is received from the server, whichever is shorter. If no response
2435	   is received during the pause period, or if the initial response is
2436	   100 (continue), the client may continue sending the WRAPPED
2437	   request. If the response indicates an error, the client must
2438	   discontinue the request and close the connection with the server
2439	   after reading the response.

2441	   Upon receipt of a WRAPPED request, the server must examine the
2442	   header fields and determine whether or not the client should
2443	   continue its request. If any of the header fields indicate the
2444	   request is insufficient or unacceptable to the server (i.e., will
2445	   result in a 4xx or 5xx response), or if the server can determine
2446	   the response without reading the entity body (e.g., a 301 or 302
2447	   response due to an old Request-URI), the server must send that
2448	   response immediately upon its determination. If, on the other hand,
2449	   the request appears (at least initially) to be acceptable and the
2450	   client has indicated HTTP/1.1 compliance, the server must transmit
2451	   an interim 100 response message after receiving the empty line
2452	   terminating the request headers and continue processing the
2453	   request. After processing has finished, a final response message
2454	   must be sent to indicate the actual result of the request. A 100
2455	   response should not be sent in response to an HTTP/1.0 request
2456	   except under experimental conditions, since an HTTP/1.0 client may
2457	   mistake the 100 response for the final response.

2459	   For compatibility with HTTP/1.0 applications, all WRAPPED requests
2460	   must include a valid Content-Length header field unless the server
2461	   is known to be HTTP/1.1 compliant. When sending a WRAPPED request
2462	   to an HTTP/1.1 server, a client must use at least one of: a valid
2463	   Content-Length, a multipart Content-Type, or the "chunked"
2464	   Transfer-Encoding. The server should respond with a 400 (bad
2465	   request) message if it cannot determine the length of the request
2466	   message's content, or with 411 (length required) if it wishes to
2467	   insist on receiving a valid Content-Length.

2469	9.  Status Code Definitions

2471	   Each Status-Code is described below, including a description of
2472	   which method(s) it can follow and any metainformation required in
2473	   the response.

2475	9.1  Informational 1xx

2477	   This class of status code indicates a provisional response,
2478	   consisting only of the Status-Line and optional headers, and is
2479	   terminated by an empty line. Since HTTP/1.0 did not define any 1xx
2480	   status codes, servers should not send a 1xx response to an HTTP/1.0
2481	   client except under experimental conditions.

2483	   100 Continue

2485	   The client may continue with its request. This interim response is
2486	   used to inform the client that the initial part of the request has
2487	   been received and has not yet been rejected by the server. The
2488	   client should continue by sending the remainder of the request or,
2489	   if the request has already been completed, ignore this response.
2490	   The server must send a final response after the request has been
2491	   completed.

2493	   101 Switching Protocols

2495	   The server understands and is willing to comply with the client's
2496	   request, via the Upgrade message header field (Section 10.41), for
2497	   a change in the application protocol being used on this connection.
2498	   The server will switch protocols to those defined by the response's
2499	   Upgrade header field immediately after the empty line which
2500	   terminates the 101 response.

2502	   The protocol should only be switched when it is advantageous to do
2503	   so. For example, switching to a newer version of HTTP is
2504	   advantageous over older versions, and switching to a real-time,
2505	   synchronous protocol may be advantageous when delivering resources
2506	   that use such features.

2508	9.2  Successful 2xx

2510	   This class of status code indicates that the client's request was
2511	   successfully received, understood, and accepted.

2513	   200 OK

2515	   The request has succeeded. The information returned with the
2516	   response is dependent on the method used in the request, as follows:

2518	   GET    an entity corresponding to the requested resource is sent
2519	          in the response;

2521	   HEAD   the response must only contain the header information and
2522	          no Entity-Body;

2524	   POST   an entity describing or containing the result of the action;

2526	   TRACE  an entity containing the request message as received by the
2527	          end server;

2529	   otherwise, an entity describing the result of the action;

2531	   If the entity corresponds to a resource, the response may include a
2532	   Location header field giving the actual location of that specific
2533	   resource for later reference.

2535	   201 Created

2537	   The request has been fulfilled and resulted in a new resource being
2538	   created. The newly created resource can be referenced by the URI(s)
2539	   returned in the URI-header field and/or the entity of the response,
2540	   with the most specific URL for the resource given by a Location
2541	   header field. The origin server should create the resource before
2542	   using this Status-Code. If the action cannot be carried out
2543	   immediately, the server must include in the response body a
2544	   description of when the resource will be available; otherwise, the
2545	   server should respond with 202 (accepted).

2547	   202 Accepted

2549	   The request has been accepted for processing, but the processing
2550	   has not been completed. The request may or may not eventually be
2551	   acted upon, as it may be disallowed when processing actually takes
2552	   place. There is no facility for re-sending a status code from an
2553	   asynchronous operation such as this.

2555	   The 202 response is intentionally non-committal. Its purpose is to
2556	   allow a server to accept a request for some other process (perhaps
2557	   a batch-oriented process that is only run once per day) without
2558	   requiring that the user agent's connection to the server persist
2559	   until the process is completed. The entity returned with this
2560	   response should include an indication of the request's current
2561	   status and either a pointer to a status monitor or some estimate of
2562	   when the user can expect the request to be fulfilled.

2564	   203 Non-Authoritative Information

2566	   The returned metainformation in the Entity-Header is not the
2567	   definitive set as available from the origin server, but is gathered
2568	   from a local or a third-party copy. The set presented may be a
2569	   subset or superset of the original version. For example, including
2570	   local annotation information about the resource may result in a
2571	   superset of the metainformation known by the origin server. Use of
2572	   this response code is not required and is only appropriate when the
2573	   response would otherwise be 200 (ok).

2575	   204 No Content

2577	   The server has fulfilled the request but there is no new
2578	   information to send back. If the client is a user agent, it should
2579	   not change its document view from that which caused the request to
2580	   be generated. This response is primarily intended to allow input
2581	   for actions to take place without causing a change to the user
2582	   agent's active document view. The response may include new
2583	   metainformation in the form of entity headers, which should apply
2584	   to the document currently in the user agent's active view.

2586	   The 204 response must not include an entity body, and thus is
2587	   always ternminated by the first empty line after the header fields.

2589	   205 Reset Content

2591	   The server has fulfilled the request and the user agent should
2592	   reset the document view which caused the request to be generated.
2593	   This response is primarily intended to allow input for actions to
2594	   take place via user input, followed by a clearing of the form in
2595	   which the input is given so that the user can easily initiate
2596	   another input action. The response must include a Content-Length
2597	   with a value of zero (0) and no entity body.

2599	   206 Partial Content

2601	   The server has fulfilled the partial GET request for the resource.
2602	   The request must have included a Range header field (Section 10.33)
2603	   indicating the desired range. The response must include a
2604	   Content-Range header field (Section 10.14) indicating the range
2605	   included with this response. All entity header fields in the
2606	   response must describe the actual entity transmitted rather than
2607	   what would have been transmitted in a full response. In particular,
2608	   the Content-Length header field in the response must match the
2609	   actual number of OCTETs transmitted in the entity body. It is
2610	   assumed that the client already has the complete entity's header
2611	   field data.

2613	9.3  Redirection 3xx

2615	   This class of status code indicates that further action needs to be
2616	   taken by the user agent in order to fulfill the request. The action
2617	   required may be carried out by the user agent without interaction
2618	   with the user if and only if the method used in the second request
2619	   is GET or HEAD. A user agent should never automatically redirect a
2620	   request more than 5 times, since such redirections usually indicate
2621	   an infinite loop.

2623	   300 Multiple Choices

2625	   The requested resource is available at one or more locations and a
2626	   preferred location could not be determined via preemptive content
2627	   negotiation (Section 12). Unless it was a HEAD request, the
2628	   response should include an entity containing a list of resource
2629	   characteristics and locations from which the user or user agent can
2630	   choose the one most appropriate. The entity format is specified by
2631	   the media type given in the Content-Type header field. Depending
2632	   upon the format and the capabilities of the user agent, selection
2633	   of the most appropriate choice may be performed automatically. If
2634	   the server has a preferred choice, it should include the URL in a
2635	   Location field; user agents not capable of complex selection may
2636	   use this field value for automatic redirection. This response is
2637	   cachable unless indicated otherwise.

2639	   301 Moved Permanently

2641	   The requested resource has been assigned a new permanent URI and
2642	   any future references to this resource should be done using one of
2643	   the returned URIs. Clients with link editing capabilities should
2644	   automatically relink references to the Request-URI to one or more
2645	   of the new references returned by the server, where possible. This
2646	   response is cachable unless indicated otherwise.

2648	   If the new URI is a single location, its URL must be given by the
2649	   Location field in the response. If more than one URI exists for the
2650	   resource, the primary URL should be given in the Location field and
2651	   the other URIs given in one or more URI-header fields. Unless it
2652	   was a HEAD request, the Entity-Body of the response should contain
2653	   a short hypertext note with a hyperlink to the new URI(s).

2655	   If the 301 status code is received in response to a request other
2656	   than GET or HEAD, the user agent must not automatically redirect
2657	   the request unless it can be confirmed by the user, since this
2658	   might change the conditions under which the request was issued.

2660	   302 Moved Temporarily

2662	   The requested resource resides temporarily under a different URI.
2663	   Since the redirection may be altered on occasion, the client should
2664	   continue to use the Request-URI for future requests. This response
2665	   is only cachable if indicated by a Cache-Control or Expires header
2666	   field.

2668	   If the new URI is a single location, its URL must be given by the
2669	   Location field in the response. If more than one URI exists for the
2670	   resource, the primary URL should be given in the Location field and
2671	   the other URIs given in one or more URI-header fields. Unless it
2672	   was a HEAD request, the Entity-Body of the response should contain
2673	   a short hypertext note with a hyperlink to the new URI(s).

2675	   If the 302 status code is received in response to a request other
2676	   than GET or HEAD, the user agent must not automatically redirect
2677	   the request unless it can be confirmed by the user, since this
2678	   might change the conditions under which the request was issued.

2680	   303 See Other

2682	   The response to the request can be found under a different URI and
2683	   should be retrieved using a GET method on that resource. This
2684	   method exists primarily to allow the output of a POST-activated
2685	   script to redirect the user agent to a selected resource. The new
2686	   resource is not a replacement reference for the original
2687	   Request-URI. The 303 response is not cachable, but the response to
2688	   the second request may be cachable.

2690	   If the new URI is a single location, its URL must be given by the
2691	   Location field in the response. If more than one URI exists for the
2692	   resource, the primary URL should be given in the Location field and
2693	   the other URIs given in one or more URI-header fields. Unless it
2694	   was a HEAD request, the Entity-Body of the response should contain
2695	   a short hypertext note with a hyperlink to the new URI(s).

2697	   304 Not Modified

2699	   If the client has performed a conditional GET request and access is
2700	   allowed, but the document has not been modified since the date and
2701	   time specified in the If-Modified-Since field, the server must
2702	   respond with this status code and not send an Entity-Body to the
2703	   client. Header fields contained in the response should only include
2704	   information which is relevant to cache managers or which may have
2705	   changed independently of the entity's Last-Modified date. Examples
2706	   of relevant header fields include: Date, Server, Content-Length,
2707	   Content-MD5, Content-Version, Cache-Control and Expires.

2709	   A cache should update its cached entity to reflect any new field
2710	   values given in the 304 response. If the new field values indicate
2711	   that the cached entity differs from the current resource (as would
2712	   be indicated by a change in Content-Length, Content-MD5, or
2713	   Content-Version), then the cache must disregard the 304 response
2714	   and repeat the request without an If-Modified-Since field.

2716	   The 304 response must not include an entity body, and thus is
2717	   always ternminated by the first empty line after the header fields.

2719	   305 Use Proxy

2721	   The requested resource must be accessed through the proxy given by
2722	   the Location field in the response. In other words, this is a proxy
2723	   redirect.

2725	9.4  Client Error 4xx

2727	   The 4xx class of status code is intended for cases in which the
2728	   client seems to have erred. If the client has not completed the
2729	   request when a 4xx code is received, it should immediately cease
2730	   sending data to the server. Except when responding to a HEAD
2731	   request, the server should include an entity containing an
2732	   explanation of the error situation, and whether it is a temporary
2733	   or permanent condition. These status codes are applicable to any
2734	   request method.

2736	       Note: If the client is sending data, server implementations
2737	       on TCP should be careful to ensure that the client
2738	       acknowledges receipt of the packet(s) containing the
2739	       response prior to closing the input connection. If the
2740	       client continues sending data to the server after the close,
2741	       the server's controller will send a reset packet to the
2742	       client, which may erase the client's unacknowledged input
2743	       buffers before they can be read and interpreted by the HTTP
2744	       application.

2746	   400 Bad Request

2748	   The request could not be understood by the server due to malformed
2749	   syntax. The client should not repeat the request without
2750	   modifications.

2752	   401 Unauthorized

2754	   The request requires user authentication. The response must include
2755	   a WWW-Authenticate header field (Section 10.44) containing a
2756	   challenge applicable to the requested resource. The client may
2757	   repeat the request with a suitable Authorization header field
2758	   (Section 10.6). If the request already included Authorization
2759	   credentials, then the 401 response indicates that authorization has
2760	   been refused for those credentials. If the 401 response contains
2761	   the same challenge as the prior response, and the user agent has
2762	   already attempted authentication at least once, then the user
2763	   should be presented the entity that was given in the response,
2764	   since that entity may include relevant diagnostic information. HTTP
2765	   access authentication is explained in Section 11.

2767	   402 Payment Required

2769	   This code is reserved for future use.

2771	   403 Forbidden

2773	   The server understood the request, but is refusing to fulfill it.
2774	   Authorization will not help and the request should not be repeated.
2775	   If the request method was not HEAD and the server wishes to make
2776	   public why the request has not been fulfilled, it should describe
2777	   the reason for the refusal in the entity body. This status code is
2778	   commonly used when the server does not wish to reveal exactly why
2779	   the request has been refused, or when no other response is
2780	   applicable.

2782	   404 Not Found

2784	   The server has not found anything matching the Request-URI. No
2785	   indication is given of whether the condition is temporary or
2786	   permanent. If the server does not wish to make this information
2787	   available to the client, the status code 403 (forbidden) can be
2788	   used instead. The 410 (gone) status code should be used if the
2789	   server knows, through some internally configurable mechanism, that
2790	   an old resource is permanently unavailable and has no forwarding
2791	   address.

2793	   405 Method Not Allowed

2795	   The method specified in the Request-Line is not allowed for the
2796	   resource identified by the Request-URI. The response must include
2797	   an Allow header containing a list of valid methods for the
2798	   requested resource.

2800	   406 None Acceptable

2802	   The server has found a resource matching the Request-URI, but not
2803	   one that satisfies the conditions identified by the Accept and
2804	   Accept-Encoding request headers. Unless it was a HEAD request, the
2805	   response should include an entity containing a list of resource
2806	   characteristics and locations from which the user or user agent can
2807	   choose the one most appropriate. The entity format is specified by
2808	   the media type given in the Content-Type header field. Depending
2809	   upon the format and the capabilities of the user agent, selection
2810	   of the most appropriate choice may be performed automatically.

2812	   407 Proxy Authentication Required

2814	   This code is similar to 401 (unauthorized), but indicates that the
2815	   client must first authenticate itself with the proxy. The proxy
2816	   must return a Proxy-Authenticate header field (Section 10.30)
2817	   containing a challenge applicable to the proxy for the requested
2818	   resource. The client may repeat the request with a suitable
2819	   Proxy-Authorization header field (Section 10.31). HTTP access
2820	   authentication is explained in Section 11.

2822	   408 Request Timeout

2824	   The client did not produce a request within the time that the
2825	   server was prepared to wait. The client may repeat the request
2826	   without modifications at any later time.

2828	   409 Conflict

2830	   The request could not be completed due to a conflict with the
2831	   current state of the resource. This code is only allowed in
2832	   situations where it is expected that the user may be able to
2833	   resolve the conflict and resubmit the request. The response body
2834	   should include enough information for the user to recognize the
2835	   source of the conflict. Ideally, the response entity would include
2836	   enough information for the user or user-agent to fix the problem;
2837	   however, that may not be possible and is not required.

2839	   Conflicts are most likely to occur in response to a PUT or PATCH
2840	   request. If versioning is being used and the entity being PUT or
2841	   PATCHed includes changes to a resource which conflict with those
2842	   made by an earlier (third-party) request, the server may use the
2843	   409 response to indicate that it can't complete the request. In
2844	   this case, the response entity should contain a list of the
2845	   differences between the two versions in a format defined by the
2846	   response Content-Type.

2848	   410 Gone

2850	   The requested resource is no longer available at the server and no
2851	   forwarding address is known. This condition should be considered
2852	   permanent. Clients with link editing capabilities should delete
2853	   references to the Request-URI after user approval. If the server
2854	   does not know, or has no facility to determine, whether or not the
2855	   condition is permanent, the status code 404 (not found) should be
2856	   used instead. This response is cachable unless indicated otherwise.

2858	   The 410 response is primarily intended to assist the task of web
2859	   maintenance by notifying the recipient that the resource is
2860	   intentionally unavailable and that the server owners desire that
2861	   remote links to that resource be removed. Such an event is common
2862	   for limited-time, promotional services and for resources belonging
2863	   to individuals no longer working at the server's site. It is not
2864	   necessary to mark all permanently unavailable resources as "gone"
2865	   or to keep the mark for any length of time -- that is left to the
2866	   discretion of the server owner.

2868	   411 Length Required

2870	   The server refuses to accept the request without a defined
2871	   Content-Length. The client may repeat the request if it adds a
2872	   valid Content-Length header field containing the length of the
2873	   entity body in the request message.

2875	   412 Unless True

2877	   The condition given in the Unless request-header field
2878	   (Section 10.40) evaluated to true when it was tested on the server
2879	   and the request did not include a Range header field (which would
2880	   indicate a partial GET) or an If-Modified-Since header field (which
2881	   would indicate a conditional GET). This response code allows the
2882	   client to place arbitrary preconditions on the current resource
2883	   metainformation (header field data) and thus prevent the requested
2884	   method from being applied to a resource other than the one intended.

2886	9.5  Server Error 5xx

2888	   Response status codes beginning with the digit "5" indicate cases
2889	   in which the server is aware that it has erred or is incapable of
2890	   performing the request. If the client has not completed the request
2891	   when a 5xx code is received, it should immediately cease sending
2892	   data to the server. Except when responding to a HEAD request, the
2893	   server should include an entity containing an explanation of the
2894	   error situation, and whether it is a temporary or permanent
2895	   condition. These response codes are applicable to any request
2896	   method and there are no required header fields.

2898	   500 Internal Server Error

2900	   The server encountered an unexpected condition which prevented it
2901	   from fulfilling the request.

2903	   501 Not Implemented

2905	   The server does not support the functionality required to fulfill
2906	   the request. This is the appropriate response when the server does
2907	   not recognize the request method and is not capable of supporting
2908	   it for any resource.

2910	   502 Bad Gateway

2912	   The server, while acting as a gateway or proxy, received an invalid
2913	   response from the upstream server it accessed in attempting to
2914	   fulfill the request.

2916	   503 Service Unavailable

2918	   The server is currently unable to handle the request due to a
2919	   temporary overloading or maintenance of the server. The implication
2920	   is that this is a temporary condition which will be alleviated
2921	   after some delay. If known, the length of the delay may be
2922	   indicated in a Retry-After header. If no Retry-After is given, the
2923	   client should handle the response as it would for a 500 response.

2925	       Note: The existence of the 503 status code does not imply
2926	       that a server must use it when becoming overloaded. Some
2927	       servers may wish to simply refuse the connection.

2929	   504 Gateway Timeout

2931	   The server, while acting as a gateway or proxy, did not receive a
2932	   timely response from the upstream server it accessed in attempting
2933	   to complete the request.

2935	10.  Header Field Definitions

2937	   This section defines the syntax and semantics of all standard
2938	   HTTP/1.1 header fields. For Entity-Header fields, both sender and
2939	   recipient refer to either the client or the server, depending on
2940	   who sends and who receives the entity.

2942	10.1  Accept

2944	   The Accept response-header field can be used to indicate a list of
2945	   media ranges which are acceptable as a response to the request. The
2946	   asterisk "*" character is used to group media types into ranges,
2947	   with "*/*" indicating all media types and "type/*" indicating all
2948	   subtypes of that type. The set of ranges given by the client should
2949	   represent what types are acceptable given the context of the
2950	   request. The Accept field should only be used when the request is
2951	   specifically limited to a set of desired types, as in the case of a
2952	   request for an in-line image, or to indicate qualitative
2953	   preferences for specific media types.

2955	   The field may be folded onto several lines and more than one
2956	   occurrence of the field is allowed, with the semantics being the
2957	   same as if all the entries had been in one field value.

2959	       Accept         = "Accept" ":" #(
2960	                        media-range
2961	                        [ ";" "q" "=" qvalue ]
2962	                        [ ";" "mxb" "=" 1*DIGIT ] )

2964	       media-range    = ( "*/*"
2965	                      |   ( type "/" "*" )
2966	                      |   ( type "/" subtype )
2967	                        ) *( ";" parameter )

2969	   The parameter q is used to indicate the quality factor, which
2970	   represents the user's preference for that range of media types. The
2971	   parameter mxb gives the maximum acceptable size of the Entity-Body,
2972	   in decimal number of octets, for that range of media types.
2973	   Section 12 describes the content negotiation algorithm which makes
2974	   use of these values. The default values are: q=1 and mxb=undefined
2975	   (i.e., infinity).

2977	   The example

2979	       Accept: audio/*; q=0.2, audio/basic

2981	   should be interpreted as "I prefer audio/basic, but send me any
2982	   audio type if it is the best available after an 80% mark-down in
2983	   quality."

2985	   If no Accept header is present, then it is assumed that the client
2986	   accepts all media types with quality factor 1. This is equivalent
2987	   to the client sending the following accept header field:

2989	       Accept: */*; q=1

2991	   or

2993	       Accept: */*

2995	   If a single Accept header is provided and it contains no field
2996	   value, then the server must interpret it as a request to not
2997	   perform any preemptive content negotiation (Section 12) and instead
2998	   return a 406 (none acceptable) response if there are variants
2999	   available for the Request-URI.

3001	   A more elaborate example is

3003	       Accept: text/plain; q=0.5, text/html,
3004	               text/x-dvi; q=0.8; mxb=100000, text/x-c

3006	   Verbally, this would be interpreted as "text/html and text/x-c are
3007	   the preferred media types, but if they do not exist, then send the
3008	   text/x-dvi entity if it is less than 100000 bytes, otherwise send
3009	   the text/plain entity."

3011	   Media ranges can be overridden by more specific media ranges or
3012	   specific media types. If more than one media range applies to a
3013	   given type, the most specific reference has precedence. For example,

3015	       Accept: text/*, text/html, text/html;version=2.0, */*

3017	   have the following precedence:

3019	       1) text/html;version=2.0
3020	       2) text/html
3021	       3) text/*
3022	       4) */*

3024	   The quality value associated with a given type is determined by
3025	   finding the media range with the highest precedence which matches
3026	   that type. For example,

3028	       Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0,
3029	               */*;q=0.5

3031	   would cause the following values to be associated:

3033	       text/html;version=2.0                      = 1
3034	       text/html                                  = 0.7
3035	       text/plain                                 = 0.3
3036	       image/jpeg                                 = 0.5
3037	       text/html;level=3                          = 0.7

3039	   It must be emphasized that the Accept field should only be used
3040	   when it is necessary to restrict the response media types to a
3041	   subset of those possible or when the user has been permitted to
3042	   specify qualitative values for ranges of media types. If no quality
3043	   factors have been set by the user, and the context of the request
3044	   is such that the user agent is capable of saving the entity to a
3045	   file if the received media type is unknown, then the only
3046	   appropriate value for Accept is "*/*", or an empty value if the
3047	   user desires reactive negotiation.

3049	       Note: A user agent may be provided with a default set of
3050	       quality values for certain media ranges. However, unless the
3051	       user agent is a closed system which cannot interact with
3052	       other rendering agents, this default set should be
3053	       configurable by the user.

3055	10.2  Accept-Charset

3057	   The Accept-Charset request-header field can be used to indicate
3058	   what character sets are acceptable for the response. This field
3059	   allows clients capable of understanding more comprehensive or
3060	   special-purpose character sets to signal that capability to a
3061	   server which is capable of representing documents in those
3062	   character sets. The US-ASCII character set can be assumed to be
3063	   acceptable to all user agents.

3065	       Accept-Charset = "Accept-Charset" ":" 1#charset

3067	   Character set values are described in Section 3.4. An example is

3069	       Accept-Charset: iso-8859-1, unicode-1-1

3071	   If no Accept-Charset field is given, the default is that any
3072	   character set is acceptable. If the Accept-Charset field is given
3073	   and the requested resource is not available in one of the listed
3074	   character sets, then the server should respond with the 406 (none
3075	   acceptable) status code.

3077	10.3  Accept-Encoding

3079	   The Accept-Encoding request-header field is similar to Accept, but
3080	   restricts the content-coding values (Section 3.5) which are
3081	   acceptable in the response.

3083	       Accept-Encoding         = "Accept-Encoding" ":"
3084	                                 #( content-coding )

3086	   An example of its use is

3088	       Accept-Encoding: compress, gzip

3090	   If no Accept-Encoding field is present in a request, the server may
3091	   assume that the client will accept any content coding. If an
3092	   Accept-Encoding field is present, but contains an empty field
3093	   value, then the user agent is refusing to accept any content coding.

3095	10.4  Accept-Language

3097	   The Accept-Language request-header field is similar to Accept, but
3098	   restricts the set of natural languages that are preferred as a
3099	   response to the request.

3101	       Accept-Language = "Accept-Language" ":"
3102	                         1#( language-tag [ ";" "q" "=" qvalue ] )

3104	   The language-tag is described in Section 3.10. Each language may be
3105	   given an associated quality value which represents an estimate of
3106	   the user's comprehension of that language. The quality value
3107	   defaults to "q=1" (100% comprehension) for listed languages. This
3108	   value may be used in the server's content negotiation algorithm
3109	   (Section 12). For example,

3111	       Accept-Language: da, en-gb;q=0.8, de;q=0.55

3113	   would mean: "I prefer Danish, but will accept British English (with
3114	   80% comprehension) or German (with a 55% comprehension)."

3116	   If the server cannot fulfill the request with one or more of the
3117	   languages given, or if the languages only represent a subset of a
3118	   multi-linguistic Entity-Body, it is acceptable to serve the request
3119	   in an unspecified language. This is equivalent to assigning a
3120	   quality value of "q=0.001" to any unlisted language.

3122	   If no Accept-Language header is present in the request, the server
3123	   should assume that all languages are equally acceptable.

3125	       Note: As intelligibility is highly dependent on the
3126	       individual user, it is recommended that client applications
3127	       make the choice of linguistic preference available to the
3128	       user. If the choice is not made available, then the
3129	       Accept-Language header field must not be given in the
3130	       request.

3132	10.5  Allow

3134	   The Allow entity-header field lists the set of methods supported by
3135	   the resource identified by the Request-URI. The purpose of this
3136	   field is strictly to inform the recipient of valid methods
3137	   associated with the resource. An Allow header field must be present
3138	   in a 405 (method not allowed) response. The Allow header field is
3139	   not permitted in a request using the POST method, and thus should
3140	   be ignored if it is received as part of a POST entity.

3142	       Allow          = "Allow" ":" 1#method

3144	    Example of use:

3146	       Allow: GET, HEAD, PUT

3148	   This field cannot prevent a client from trying other methods.
3149	   However, the indications given by the Allow header field value
3150	   should be followed. The actual set of allowed methods is defined by
3151	   the origin server at the time of each request.

3153	   The Allow header field may be provided with a PUT request to
3154	   recommend the methods to be supported by the new or modified
3155	   resource. The server is not required to support these methods and
3156	   should include an Allow header in the response giving the actual
3157	   supported methods.

3159	   A proxy must not modify the Allow header field even if it does not
3160	   understand all the methods specified, since the user agent may have
3161	   other means of communicating with the origin server.

3163	   The Allow header field does not indicate what methods are
3164	   implemented at the server level. Servers may use the Public
3165	   response header field (Section 10.32) to describe what methods are
3166	   implemented on the server as a whole.

3168	10.6  Authorization

3170	   A user agent that wishes to authenticate itself with a
3171	   server--usually, but not necessarily, after receiving a 401
3172	   response--may do so by including an Authorization request-header
3173	   field with the request. The Authorization field value consists of
3174	   credentials containing the authentication information of the user
3175	   agent for the realm of the resource being requested.

3177	       Authorization  = "Authorization" ":" credentials

3179	   HTTP access authentication is described in Section 11. If a request
3180	   is authenticated and a realm specified, the same credentials should
3181	   be valid for all other requests within this realm.

3183	   Responses to requests containing an Authorization field are not
3184	   cachable.

3186	10.7  Base

3188	   The Base entity-header field may be used to specify the base URI
3189	   for resolving relative URLs, as described in RFC 1808 [11].

3191	10.8  Cache-Control

3193	   The Cache-Control general-header field is used to specify
3194	   directives that must be obeyed by all caching mechanisms along the
3195	   request/response chain. The directives specify behavior intended to
3196	   prevent caches from adversely interfering with the request or
3197	   response. Cache directives are unidirectional in that the presence
3198	   of a directive in a request does not imply that the same directive
3199	   should be given in the response.

3201	       Cache-Control   = "Cache-Control" ":" 1#cache-directive

3203	       cache-directive = "cachable"
3204	                       | "max-age" "=" delta-seconds
3205	                       | "private" [ "=" <"> 1#field-name <"> ]
3206	                       | "no-cache" [ "=" <"> 1#field-name <"> ]

3208	   The Cache-Control header field may be used to modify the optional
3209	   behavior of caching mechanisms, and the default cachability of a
3210	   response message; it cannot be used to modify the required behavior
3211	   of caching mechanisms. HTTP requirements for caching and cachable
3212	   messages are described in Section 13.

3214	   The "cachable" directive indicates that the entire response message
3215	   is cachable unless required otherwise by HTTP restrictions on the
3216	   request method and response code. In other words, this directive
3217	   indicates that the server believes the response to be cachable.
3218	   This directive applies only to responses and must not be used with
3219	   any other cache directive.

3221	   When the "max-age" directive is present in a request message, an
3222	   application must forward the request toward the origin server if it
3223	   has no cached copy, or refresh its cached copy if it is older than
3224	   the age value given (in seconds) prior to returning a response. A
3225	   cached copy's age is determined by the cached message's Date header
3226	   field, or the equivalent as stored by the cache manager.

3228	   In most cases, a cached copy can be refreshed by forwarding a
3229	   conditional GET request toward the origin server with the stored
3230	   message's Last-Modified value in the If-Modified-Since field. The
3231	   Unless header field may be used to add further restrictions to the
3232	   modification test on the server. If a 304 (not modified) response
3233	   is received, the cache should replace the cached message's Date
3234	   with that of the 304 response and send this refreshed message as
3235	   the response. Any other response should be forwarded directly to
3236	   the requestor and, depending on the response code and the
3237	   discretion of the cache manager, may replace the message in the
3238	   cache.

3240	   When the "max-age" directive is present in a cached response
3241	   message, an application must refresh the message if it is older
3242	   than the age value given (in seconds) at the time of a new request
3243	   for that resource. The behavior should be equivalent to what would
3244	   occur if the request had included the max-age directive. If both
3245	   the new request and the cached message have max-age specified, then
3246	   the lesser of the two values must be used. A max-age value of zero
3247	   (0) forces a cache to perform a refresh (If-Modified-Since) on
3248	   every request. The max-age directive on a response implies that the
3249	   server believes it to be cachable.

3251	   The "private" directive indicates that parts of the response
3252	   message are intended for a single user and must not be cached
3253	   except within a private (non-shared) cache controlled by the user
3254	   agent. If no list of field names is given, then the entire message
3255	   is private; otherwise, only the information within the header
3256	   fields identified by the list of names is private and the remainder
3257	   of the message is believed to be cachable by any application. This
3258	   allows an origin server to state that the specified parts of the
3259	   message are intended for only one user and are not a valid response
3260	   for requests by other agents. The "private" directive is only
3261	   applicable to responses and must not be generated by clients.

3263	       Note: This usage of the word "private" implies only that the
3264	       message must not be cached publically; it does not ensure
3265	       the privacy of the message content.

3267	   The "no-cache" directive on a request message requires any cache to
3268	   forward the request toward the origin server even if it has a
3269	   cached copy of what is being requested. This allows a client to
3270	   insist upon receiving an authoritative response to its request. It
3271	   also allows a client to refresh a cached copy which is known to be
3272	   corrupted or stale. This is equivalent to the "no-cache"
3273	   pragma-directive in Section 10.29. The list of field names is not
3274	   used with requests and must not be generated by clients. The
3275	   no-cache directive overrides any max-age directive.

3277	   The "no-cache" directive on a response message indicates that parts
3278	   of the message must never be cached. If no list of field names is
3279	   given, then the entire message must not be cached; otherwise, only
3280	   the information within the header fields identified by the list of
3281	   names must not be cached and the remainder of the message is
3282	   believed to be cachable. This allows an origin server to state that
3283	   the specified parts of the message are intended for only one
3284	   recipient and must not be stored unless the user explicitly
3285	   requests it through a separate action.

3287	   The max-age, private, and no-cache directives may be used in
3288	   combination to define the cachability of each part of the message.
3289	   In all cases, no-cache takes precedence over private, which in turn
3290	   takes precedence over max-age.

3292	   Cache directives must be passed through by a proxy or gateway
3293	   application, regardless of their significance to that application,
3294	   since the directives may be applicable to all recipients along the
3295	   request/response chain. It is not possible to specify a
3296	   cache-directive for a specific cache.

3298	10.9  Connection

3300	   The Connection general-header field is used to indicate a list of
3301	   keywords and header field names containing information which is
3302	   only applicable to the current connection between the sender and
3303	   the nearest non-tunnel recipient on the request/response chain.
3304	   This information must not be forwarded or cached. Unlike the
3305	   default behavior, the recipient cannot safely ignore the semantics
3306	   of the listed field-names if they are not understood, since
3307	   forwarding them may imply that understanding.

3309	       Connection     = "Connection" ":" 1#field-name

3311	   Proxies and gateways must discard the named header fields, and the
3312	   Connection header itself, before forwarding the message. Proxies
3313	   and gateways may add their own Connection information to forwarded
3314	   messages if such options are desired for the forwarding connection.
3315	   These restrictions do not apply to a tunnel, since the tunnel is
3316	   acting as a relay between two connections and does not affect the
3317	   connection options.

3319	   Whether or not the listed field-name(s) occur as header fields in
3320	   the message is optional. If no corresponding header field is
3321	   present, then the field name is treated as a keyword. Keywords are
3322	   useful for indicating a desired option without assigning parameters
3323	   to that option. This allows for a minimal syntax to provide
3324	   connection-based options without pre-restricting the syntax or
3325	   number of those options. HTTP/1.1 only defines the "keep-alive"
3326	   keyword.

3328	   The semantics of Connection are defined by HTTP/1.1 in order to
3329	   provide a safe transition to connection-based features. Connection
3330	   header fields received in an HTTP/1.0 message, as would be the case
3331	   if an older proxy mistakenly forwards the field, cannot be trusted
3332	   and must be discarded except under experimental conditions.

3334	10.9.1 Persistent Connections

3336	   The "keep-alive" keyword in a Connection header field allows the
3337	   sender to indicate its desire for a persistent connection (i.e., a
3338	   connection that lasts beyond the current request/response
3339	   transaction). Persistent connections allow the client to perform
3340	   multiple requests without the overhead of connection tear-down and
3341	   set-up between each request.

3343	   As an example, a client would send

3345	       Connection: Keep-Alive

3347	   to indicate that it desires to keep the connection open for
3348	   multiple requests. The server may then respond with a message
3349	   containing

3351	       Connection: Keep-Alive

3353	   to indicate that the connection will be kept open for the next
3354	   request. The Connection header field with a keep-alive keyword must
3355	   be sent on all requests and responses that wish to continue the
3356	   persistence. The client sends requests as normal and the server
3357	   responds as normal, except that all messages containing an entity
3358	   body must have a length that can be determined without closing the
3359	   connection (i.e., each message containg an entity body must have a
3360	   valid Content-Length, be a multipart media type, or be encoded
3361	   using the "chunked" transfer coding, as described in Section 7.2.2).

3363	   The Keep-Alive header field (Section 10.24) may be used to include
3364	   diagnostic information and other optional parameters. For example,
3365	   the server may responds with

3367	       Connection: Keep-Alive
3368	       Keep-Alive: timeout=10, max=5

3370	   to indicate that the server has selected (perhaps dynamically) a
3371	   maximum of 5 requests, but will timeout if the next request is not
3372	   received within 10 seconds. Note, however, that this additional
3373	   information is optional and the Keep-Alive header field does not
3374	   need to be present. If it is present, the semantics of the
3375	   Connection header field prevents it from being accidentally
3376	   forwarded to downstream connections.

3378	   The persistent connection ends when either side closes the
3379	   connection or after the receipt of a response which lacks the
3380	   "keep-alive" keyword. The server may close the connection
3381	   immediately after responding to a request without a "keep-alive"
3382	   keyword. A client can tell if the connection will be closed by
3383	   looking for a "keep-alive" in the response.

3385	10.10  Content-Encoding

3387	   The Content-Encoding entity-header field is used as a modifier to
3388	   the media-type. When present, its value indicates what additional
3389	   content codings have been applied to the resource, and thus what
3390	   decoding mechanisms must be applied in order to obtain the
3391	   media-type referenced by the Content-Type header field.
3392	   Content-Encoding is primarily used to allow a document to be
3393	   compressed without losing the identity of its underlying media type.

3395	       Content-Encoding = "Content-Encoding" ":" 1#content-coding

3397	   Content codings are defined in Section 3.5. An example of its use is

3399	       Content-Encoding: gzip

3401	   The Content-Encoding is a characteristic of the resource identified
3402	   by the Request-URI. Typically, the resource is stored with this
3403	   encoding and is only decoded before rendering or analogous usage.

3405	   If multiple encodings have been applied to a resource, the content
3406	   codings must be listed in the order in which they were applied.
3407	   Additional information about the encoding parameters may be
3408	   provided by other Entity-Header fields not defined by this
3409	   specification.

3411	10.11  Content-Language

3413	   The Content-Language entity-header field describes the natural
3414	   language(s) of the intended audience for the enclosed entity. Note
3415	   that this may not be equivalent to all the languages used within
3416	   the entity.

3418	       Content-Language = "Content-Language" ":" 1#language-tag

3420	   Language tags are defined in Section 3.10. The primary purpose of
3421	   Content-Language is to allow a selective consumer to identify and
3422	   differentiate resources according to the consumer's own preferred
3423	   language. Thus, if the body content is intended only for a
3424	   Danish-literate audience, the appropriate field is

3426	       Content-Language: dk

3428	   If no Content-Language is specified, the default is that the
3429	   content is intended for all language audiences. This may mean that
3430	   the sender does not consider it to be specific to any natural
3431	   language, or that the sender does not know for which language it is
3432	   intended.

3434	   Multiple languages may be listed for content that is intended for
3435	   multiple audiences. For example, a rendition of the "Treaty of
3436	   Waitangi," presented simultaneously in the original Maori and
3437	   English versions, would call for

3439	       Content-Language: mi, en

3441	   However, just because multiple languages are present within an
3442	   entity does not mean that it is intended for multiple linguistic
3443	   audiences. An example would be a beginner's language primer, such
3444	   as "A First Lesson in Latin," which is clearly intended to be used
3445	   by an English-literate audience. In this case, the Content-Language
3446	   should only include "en".

3448	   Content-Language may be applied to any media type -- it should not
3449	   be limited to textual documents.

3451	10.12  Content-Length

3453	   The Content-Length entity-header field indicates the size of the
3454	   Entity-Body, in decimal number of octets, sent to the recipient or,
3455	   in the case of the HEAD method, the size of the Entity-Body that
3456	   would have been sent had the request been a GET.

3458	       Content-Length = "Content-Length" ":" 1*DIGIT

3460	   An example is

3462	       Content-Length: 3495

3464	   Applications should use this field to indicate the size of the
3465	   Entity-Body to be transferred, regardless of the media type of the
3466	   entity. A valid Content-Length field value is required on all
3467	   HTTP/1.1 request messages containing an entity body.

3469	   Any Content-Length greater than or equal to zero is a valid value.
3470	   Section 7.2.2 describes how to determine the length of an
3471	   Entity-Body if a Content-Length is not given.

3473	       Note: The meaning of this field is significantly different
3474	       from the corresponding definition in MIME, where it is an
3475	       optional field used within the "message/external-body"
3476	       content-type. In HTTP, it should be used whenever the
3477	       entity's length can be determined prior to being transferred.

3479	10.13  Content-MD5

3481	   TBS

3483	10.14  Content-Range

3485	   TBS

3487	10.15  Content-Type

3489	   The Content-Type entity-header field indicates the media type of
3490	   the Entity-Body sent to the recipient or, in the case of the HEAD
3491	   method, the media type that would have been sent had the request
3492	   been a GET.

3494	       Content-Type   = "Content-Type" ":" media-type

3496	   Media types are defined in Section 3.7. An example of the field is

3498	       Content-Type: text/html; charset=ISO-8859-4

3500	   Further discussion of methods for identifying the media type of an
3501	   entity is provided in Section 7.2.1.

3503	10.16  Content-Version

3505	   The Content-Version entity-header field defines the version tag
3506	   associated with a rendition of an evolving entity. Together with
3507	   the Derived-From field described in Section 10.18, it allows a
3508	   group of people to work simultaneously on the creation of a work as
3509	   an iterative process. The field should be used to allow evolution
3510	   of a particular work along a single path. It should not be used to
3511	   indicate derived works or renditions in different representations.
3512	   It may also me used as an opaque value for comparing a cached
3513	   entity's version with that of the current resource.

3515	       Content-Version= "Content-Version" ":" quoted-string

3517	   Examples of the Content-Version field include:

3519	       Content-Version: "2.1.2"

3521	       Content-Version: "Fred 19950116-12:26:48"

3523	       Content-Version: "2.5a4-omega7"

3525	   The value of the Content-Version field should be considered opaque
3526	   to all parties but the origin server. A user agent may suggest a
3527	   value for the version of an entity transferred via a PUT request;
3528	   however, only the origin server can reliably assign that value.

3530	10.17  Date

3532	   The Date general-header field represents the date and time at which
3533	   the message was originated, having the same semantics as orig-date
3534	   in RFC 822. The field value is an HTTP-date, as described in
3535	   Section 3.3.

3537	       Date           = "Date" ":" HTTP-date

3539	   An example is

3541	       Date: Tue, 15 Nov 1994 08:12:31 GMT

3543	   If a message is received via direct connection with the user agent
3544	   (in the case of requests) or the origin server (in the case of
3545	   responses), then the date can be assumed to be the current date at
3546	   the receiving end. However, since the date--as it is believed by the
3547	   origin--is important for evaluating cached responses, origin servers
3548	   should always include a Date header. Clients should only send a
3549	   Date header field in messages that include an entity body, as in
3550	   the case of the PUT and POST requests, and even then it is
3551	   optional. A received message which does not have a Date header
3552	   field should be assigned one by the recipient if the message will
3553	   be cached by that recipient or gatewayed via a protocol which
3554	   requires a Date.

3556	   In theory, the date should represent the moment just before the
3557	   entity is generated. In practice, the date can be generated at any
3558	   time during the message origination without affecting its semantic
3559	   value.

3561	       Note: An earlier version of this document incorrectly
3562	       specified that this field should contain the creation date
3563	       of the enclosed Entity-Body. This has been changed to
3564	       reflect actual (and proper) usage.

3566	10.18  Derived-From

3568	   The Derived-From entity-header field can be used to indicate the
3569	   version tag of the resource from which the enclosed entity was
3570	   derived before modifications were made by the sender. This field is
3571	   used to help manage the process of merging successive changes to a
3572	   resource, particularly when such changes are being made in parallel
3573	   and from multiple sources.

3575	       Derived-From   = "Derived-From" ":" quoted-string

3577	   An example use of the field is:

3579	       Derived-From: "2.1.1"

3581	   The Derived-From field is required for PUT and PATCH requests if
3582	   the entity being sent was previously retrieved from the same URI
3583	   and a Content-Version header was included with the entity when it
3584	   was last retrieved.

3586	10.19  Expires

3588	   The Expires entity-header field gives the date/time after which the
3589	   entity should be considered stale. This allows information
3590	   providers to suggest the volatility of the resource, or a date
3591	   after which the information may no longer be valid. Applications
3592	   must not cache this entity beyond the date given. The presence of
3593	   an Expires field does not imply that the original resource will
3594	   change or cease to exist at, before, or after that time. However,
3595	   information providers that know or even suspect that a resource
3596	   will change by a certain date should include an Expires header with
3597	   that date. The format is an absolute date and time as defined by
3598	   HTTP-date in Section 3.3.

3600	       Expires        = "Expires" ":" HTTP-date

3602	   An example of its use is

3604	       Expires: Thu, 01 Dec 1994 16:00:00 GMT

3606	   If the date given is equal to or earlier than the value of the Date
3607	   header, the recipient must not cache the enclosed entity. If a
3608	   resource is dynamic by nature, as is the case with many
3609	   data-producing processes, entities from that resource should be
3610	   given an appropriate Expires value which reflects that dynamism.

3612	   The Expires field cannot be used to force a user agent to refresh
3613	   its display or reload a resource; its semantics apply only to
3614	   caching mechanisms, and such mechanisms need only check a
3615	   resource's expiration status when a new request for that resource
3616	   is initiated.

3618	   User agents often have history mechanisms, such as "Back" buttons
3619	   and history lists, which can be used to redisplay an entity
3620	   retrieved earlier in a session. By default, the Expires field does
3621	   not apply to history mechanisms. If the entity is still in storage,
3622	   a history mechanism should display it even if the entity has
3623	   expired, unless the user has specifically configured the agent to
3624	   refresh expired history documents.

3626	       Note: Applications are encouraged to be tolerant of bad or
3627	       misinformed implementations of the Expires header. A value
3628	       of zero (0) or an invalid date format should be considered
3629	       equivalent to an "expires immediately." Although these
3630	       values are not legitimate for HTTP/1.1, a robust
3631	       implementation is always desirable.

3633	10.20  Forwarded

3635	   The Forwarded general-header field is to be used by gateways and
3636	   proxies to indicate the intermediate steps between the user agent
3637	   and the server on requests, and between the origin server and the
3638	   client on responses. It is analogous to the "Received" field of RFC
3639	   822 [9] and is intended to be used for tracing transport problems
3640	   and avoiding request loops.

3642	       Forwarded      = "Forwarded" ":" #( "by" URI [ "(" product ")" ]
3643	                        [ "for" FQDN ] )

3645	       FQDN           = 

3647	   For example, a message could be sent from a client on
3648	   ptsun00.cern.ch to a server at www.ics.uci.edu port 80, via an
3649	   intermediate HTTP proxy at info.cern.ch port 8000. The request
3650	   received by the server at www.ics.uci.edu would then have the
3651	   following Forwarded header field:

3653	       Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch

3655	   Multiple Forwarded header fields are allowed and should represent
3656	   each proxy/gateway that has forwarded the message. It is strongly
3657	   recommended that proxies/gateways used as a portal through a
3658	   network firewall do not, by default, send out information about the
3659	   internal hosts within the firewall region. This information should
3660	   only be propagated if explicitly enabled. If not enabled, the for
3661	   token and FQDN should not be included in the field value, and any
3662	   Forwarded headers already present in the message (those added
3663	   behind the firewall) should be removed.

3665	10.21  From

3667	   The From request-header field, if given, should contain an Internet
3668	   e-mail address for the human user who controls the requesting user
3669	   agent. The address should be machine-usable, as defined by mailbox
3670	   in RFC 822 [9] (as updated by RFC 1123 [8]):

3672	       From           = "From" ":" mailbox

3674	   An example is:

3676	       From: webmaster@w3.org

3678	   This header field may be used for logging purposes and as a means
3679	   for identifying the source of invalid or unwanted requests. It
3680	   should not be used as an insecure form of access protection. The
3681	   interpretation of this field is that the request is being performed
3682	   on behalf of the person given, who accepts responsibility for the
3683	   method performed. In particular, robot agents should include this
3684	   header so that the person responsible for running the robot can be
3685	   contacted if problems occur on the receiving end.

3687	   The Internet e-mail address in this field may be separate from the
3688	   Internet host which issued the request. For example, when a request
3689	   is passed through a proxy the original issuer's address should be
3690	   used.

3692	       Note: The client should not send the From header field
3693	       without the user's approval, as it may conflict with the
3694	       user's privacy interests or their site's security policy. It
3695	       is strongly recommended that the user be able to disable,
3696	       enable, and modify the value of this field at any time prior
3697	       to a request.

3699	10.22  Host

3701	   The Host request-header field allows the client to specify, for the
3702	   server's benefit, the Internet host given by the original Uniform
3703	   Resource Identifier (Section 3.2) of the resource being requested,
3704	   as it was obtained from the user or the referring resource. This
3705	   allows a server to differentiate between internally-ambiguous URLs
3706	   (such as the root "/" URL of a server harboring multiple virtual
3707	   hostnames). This field is required on all HTTP/1.1 requests which
3708	   do not already include the host in the Request-URI.

3710	       Host           = "Host" ":" host          ; Section 3.2.2

3712	   Example:

3714	       Host: www.w3.org

3716	   The contents of the Host header field should exactly match the host
3717	   information used to contact the origin server or gateway in
3718	   question. It must not include the trailing ":port" information
3719	   which may also be found in the net_loc portion of a URL
3720	   (Section 3.2).

3722	10.23  If-Modified-Since

3724	   The If-Modified-Since request-header field is used with the GET
3725	   method to make it conditional: if the requested resource has not
3726	   been modified since the time specified in this field, a copy of the
3727	   resource will not be returned from the server; instead, a 304 (not
3728	   modified) response will be returned without any Entity-Body.

3730	       If-Modified-Since = "If-Modified-Since" ":" HTTP-date

3732	   An example of the field is:

3734	       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

3736	   A conditional GET method requests that the identified resource be
3737	   transferred only if it has been modified since the date given by
3738	   the If-Modified-Since header. The algorithm for determining this
3739	   includes the following cases:

3741	      a) If the request would normally result in anything other than
3742	         a 200 (ok) status, or if the passed If-Modified-Since date
3743	         is invalid, the response is exactly the same as for a
3744	         normal GET. A date which is later than the server's current
3745	         time is invalid.

3747	      b) If the resource has been modified since the
3748	         If-Modified-Since date, the response is exactly the same as
3749	         for a normal GET.

3751	      c) If the resource has not been modified since a valid
3752	         If-Modified-Since date, the server must return a 304 (not
3753	         modified) response.

3755	   The purpose of this feature is to allow efficient updates of cached
3756	   information with a minimum amount of transaction overhead.

3758	10.24  Keep-Alive

3760	   The Keep-Alive general-header field may be used to include
3761	   diagnostic information and other optional parameters associated
3762	   with the "keep-alive" keyword of the Connection header field
3763	   (Section 10.9). This Keep-Alive field must only be used when the
3764	   "keep-alive" keyword is present (Section 10.9.1).

3766	       Keep-Alive     = "Keep-Alive" ":" 1#kaparam

3768	       kaparam        = ( "timeout" "=" delta-seconds )
3769	                      | ( "max" "=" 1*DIGIT )
3770	                      | ( attribute [ "=" value ] )

3772	   The Keep-Alive header field and the additional information it
3773	   provides are optional and do not need to be present to indicate a
3774	   persistent connection has been established. The semantics of the
3775	   Connection header field prevent the Keep-Alive field from being
3776	   accidentally forwarded to downstream connections.

3778	   HTTP/1.1 defines semantics for the optional "timeout" and "max"
3779	   parameters on responses; other parameters may be added and the
3780	   field may also be used on request messages. The "timeout" parameter
3781	   allows the server to indicate, for diagnostic purposes only, the
3782	   amount of time in seconds it is currently allowing between when the
3783	   response was generated and when the next request is received from
3784	   the client (i.e., the request timeout limit). Similarly, the "max"
3785	   parameter allows the server to indicate the maximum additional
3786	   requests that it will allow on the current persistent connection.

3788	   For example, the server may respond to a request for a persistent
3789	   connection with

3791	       Connection: Keep-Alive
3792	       Keep-Alive: timeout=10, max=5

3794	   to indicate that the server has selected (perhaps dynamically) a
3795	   maximum of 5 requests, but will timeout the connection if the next
3796	   request is not received within 10 seconds. Although these
3797	   parameters have no affect on the operational requirements of the
3798	   connection, they are sometimes useful for testing functionality and
3799	   monitoring server behavior.

3801	10.25  Last-Modified

3803	   The Last-Modified entity-header field indicates the date and time
3804	   at which the sender believes the resource was last modified. The
3805	   exact semantics of this field are defined in terms of how the
3806	   recipient should interpret it:  if the recipient has a copy of this
3807	   resource which is older than the date given by the Last-Modified
3808	   field, that copy should be considered stale.

3810	       Last-Modified  = "Last-Modified" ":" HTTP-date

3812	   An example of its use is

3814	       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

3816	   The exact meaning of this header field depends on the
3817	   implementation of the sender and the nature of the original
3818	   resource. For files, it may be just the file system last-modified
3819	   time. For entities with dynamically included parts, it may be the
3820	   most recent of the set of last-modify times for its component
3821	   parts. For database gateways, it may be the last-update timestamp
3822	   of the record. For virtual objects, it may be the last time the
3823	   internal state changed.

3825	   An origin server must not send a Last-Modified date which is later
3826	   than the server's time of message origination. In such cases, where
3827	   the resource's last modification would indicate some time in the
3828	   future, the server must replace that date with the message
3829	   origination date.

3831	10.26  Link

3833	   The Link entity-header field provides a means for describing a
3834	   relationship between the entity and some other resource. An entity
3835	   may include multiple Link values. Links at the metainformation
3836	   level typically indicate relationships like hierarchical structure
3837	   and navigation paths. The Link field is semantically equivalent to
3838	   the  element in HTML [5].

3840	       Link           = "Link" ":" #("<" URI ">"
3841	                        [ ";" "rel" "=" relationship ]
3842	                        [ ";" "rev" "=" relationship ]
3843	                        [ ";" "title" "=" quoted-string ] )

3845	       relationship   = sgml-name
3846	                      | ( <"> sgml-name *( SP sgml-name) <"> )

3848	       sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

3850	   Relationship values are case-insensitive and may be extended within
3851	   the constraints of the sgml-name syntax. The title parameter may be
3852	   used to label the destination of a link such that it can be used as
3853	   identification within a human-readable menu.

3855	   Examples of usage include:

3857	       Link: ; rel="Previous"

3859	       Link: ; rev="Made"; title="Tim Berners-Lee"

3861	   The first example indicates that chapter2  is previous to the
3862	   entity in a logical navigation path. The second indicates that the
3863	   person responsible for making the resource available is identified
3864	   by the given e-mail address.

3866	10.27  Location

3868	   The Location response-header field defines the exact location of
3869	   the resource that was identified by the Request-URI. For 2xx
3870	   responses, if the Request-URI corresponds to a negotiable set of
3871	   variants and the response includes one of those variants, then the
3872	   response must also include a Location header field containing the
3873	   exact location of the chosen variant. For 3xx responses, the
3874	   location should indicate the server's preferred URL for automatic
3875	   redirection to the resource. The field value consists of a single
3876	   absolute URL.

3878	       Location       = "Location" ":" absoluteURI

3880	   An example is

3882	       Location: http://www.w3.org/pub/WWW/People.html

3884	   If no base URL is provided by or within the entity, the value of
3885	   the Location field should be used as the base for resolving
3886	   relative URLs [11].

3888	10.28  MIME-Version

3890	   HTTP is not a MIME-compliant protocol (see Appendix C). However,
3891	   HTTP/1.1 messages may include a single MIME-Version general-header
3892	   field to indicate what version of the MIME protocol was used to
3893	   construct the message. Use of the MIME-Version header field
3894	   indicates that the message is in full compliance with the MIME
3895	   protocol (as defined in [7]). Proxies/gateways are responsible for
3896	   ensuring full compliance (where possible) when exporting HTTP
3897	   messages to strict MIME environments.

3899	       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

3901	   MIME version "1.0" is the default for use in HTTP/1.1. However,
3902	   HTTP/1.1 message parsing and semantics are defined by this document
3903	   and not the MIME specification.

3905	10.29  Pragma

3907	   The Pragma general-header field is used to include
3908	   implementation-specific directives that may apply to any recipient
3909	   along the request/response chain. All pragma directives specify
3910	   optional behavior from the viewpoint of the protocol; however, some
3911	   systems may require that behavior be consistent with the directives.

3913	       Pragma                  = "Pragma" ":" 1#pragma-directive

3915	       pragma-directive        = "no-cache" | extension-pragma
3916	       extension-pragma        = token [ "=" word ]

3918	   When the "no-cache" directive is present in a request message, an
3919	   application should forward the request toward the origin server
3920	   even if it has a cached copy of what is being requested. This
3921	   pragma directive has the same semantics as the "no-cache"
3922	   cache-directive (see Section 10.8) and is defined here for
3923	   backwards compatibility with HTTP/1.0. Clients should include both
3924	   header fields when a "no-cache" request is sent to a server not
3925	   known to be HTTP/1.1 compliant.

3927	   Pragma directives must be passed through by a proxy or gateway
3928	   application, regardless of their significance to that application,
3929	   since the directives may be applicable to all recipients along the
3930	   request/response chain. It is not possible to specify a pragma for
3931	   a specific recipient; however, any pragma directive not relevant to
3932	   a recipient should be ignored by that recipient.

3934	10.30  Proxy-Authenticate

3936	   The Proxy-Authenticate response-header field must be included as
3937	   part of a 407 (proxy authentication required) response. The field
3938	   value consists of a challenge that indicates the authentication
3939	   scheme and parameters applicable to the proxy for this Request-URI.

3941	       Proxy-Authentication    = "Proxy-Authentication" ":" challenge

3943	   The HTTP access authentication process is described in Section 11.
3944	   Unlike WWW-Authenticate, the Proxy-Authenticate header field
3945	   applies only to the current connection and must not be passed on to
3946	   downstream clients.

3948	10.31  Proxy-Authorization

3950	   The Proxy-Authorization request-header field allows the client to
3951	   identify itself (or its user) to a proxy which requires
3952	   authentication. The Proxy-Authorization field value consists of
3953	   credentials containing the authentication information of the user
3954	   agent for the proxy and/or realm of the resource being requested.

3956	       Proxy-Authorization     = "Proxy-Authorization" ":" credentials

3958	   The HTTP access authentication process is described in Section 11.
3959	   Unlike Authorization, the Proxy-Authorization applies only to the
3960	   current connection and must not be passed on to upstream servers.
3961	   If a request is authenticated and a realm specified, the same
3962	   credentials should be valid for all other requests within this
3963	   realm.

3965	10.32  Public

3967	   The Public response-header field lists the set of non-standard
3968	   methods supported by the server. The purpose of this field is
3969	   strictly to inform the recipient of the capabilities of the server
3970	   regarding unusual methods. The methods listed may or may not be
3971	   applicable to the Request-URI; the Allow header field
3972	   (Section 10.5) should be used to indicate methods allowed for a
3973	   particular URI. This does not prevent a client from trying other
3974	   methods. The field value should not include the methods predefined
3975	   for HTTP/1.1 in Section 5.1.1.

3977	       Public         = "Public" ":" 1#method

3979	   Example of use:

3981	       Public: OPTIONS, MGET, MHEAD

3983	   This header field applies only to the server directly connected to
3984	   the client (i.e., the nearest neighbor in a chain of connections).
3985	   If the response passes through a proxy, the proxy must either
3986	   remove the Public header field or replace it with one applicable to
3987	   its own capabilities.

3989	10.33  Range

3991	   TBS

3993	10.34  Referer

3995	   The Referer request-header field allows the client to specify, for
3996	   the server's benefit, the address (URI) of the resource from which
3997	   the Request-URI was obtained. This allows a server to generate
3998	   lists of back-links to resources for interest, logging, optimized
3999	   caching, etc. It also allows obsolete or mistyped links to be
4000	   traced for maintenance. The Referer field must not be sent if the
4001	   Request-URI was obtained from a source that does not have its own
4002	   URI, such as input from the user keyboard.

4004	       Referer        = "Referer" ":" ( absoluteURI | relativeURI )

4006	   Example:

4008	       Referer: http://www.w3.org/hypertext/DataSources/Overview.html

4010	   If a partial URI is given, it should be interpreted relative to the
4011	   Request-URI. The URI must not include a fragment.

4013	       Note: Because the source of a link may be private
4014	       information or may reveal an otherwise private information
4015	       source, it is strongly recommended that the user be able to
4016	       select whether or not the Referer field is sent. For
4017	       example, a browser client could have a toggle switch for
4018	       browsing openly/anonymously, which would respectively
4019	       enable/disable the sending of Referer and From information.

4021	10.35  Refresh

4023	   TBS

4025	10.36  Retry-After

4027	   The Retry-After response-header field can be used with a 503
4028	   (service unavailable) response to indicate how long the service is
4029	   expected to be unavailable to the requesting client. The value of
4030	   this field can be either an HTTP-date or an integer number of
4031	   seconds (in decimal) after the time of the response.

4033	       Retry-After    = "Retry-After" ":" ( HTTP-date | delta-seconds )

4035	   Two examples of its use are

4037	       Retry-After: Wed, 14 Dec 1994 18:22:54 GMT
4038	       Retry-After: 120

4040	   In the latter example, the delay is 2 minutes.

4042	10.37  Server

4044	   The Server response-header field contains information about the
4045	   software used by the origin server to handle the request. The field
4046	   can contain multiple product tokens (Section 3.8) and comments
4047	   identifying the server and any significant subproducts. By
4048	   convention, the product tokens are listed in order of their
4049	   significance for identifying the application.

4051	       Server         = "Server" ":" 1*( product | comment )

4053	   Example:

4055	       Server: CERN/3.0 libwww/2.17

4057	   If the response is being forwarded through a proxy, the proxy
4058	   application must not add its data to the product list. Instead, it
4059	   should include a Forwarded field (as described in Section 10.20).

4061	       Note: Revealing the specific software version of the server
4062	       may allow the server machine to become more vulnerable to
4063	       attacks against software that is known to contain security
4064	       holes. Server implementors are encouraged to make this field
4065	       a configurable option.

4067	10.38  Title

4069	   The Title entity-header field indicates the title of the entity

4071	       Title          = "Title" ":" *TEXT

4073	   An example of the field is

4075	       Title: Hypertext Transfer Protocol -- HTTP/1.1

4077	   This field is isomorphic with the  element in HTML [5].

4079	10.39  Transfer Encoding

4081	   The Transfer-Encoding general-header field indicates what (if any)
4082	   type of transformation has been applied to the message body in
4083	   order to safely transfer it between the sender and the recipient.
4084	   This differs from the Content-Encoding in that the transfer coding
4085	   is a property of the message, not of the original resource.

4087	       Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding

4089	   Transfer codings are defined in Section 3.6. An example is:

4091	       Transfer-Encoding: chunked

4093	   Many older HTTP/1.0 applications do not understand the
4094	   Transfer-Encoding header.

4096	10.40  Unless

4098	   The Unless request-header field performs a similar function as
4099	   If-Modified-Since, but the comparison is based on any Entity-Header
4100	   field value of the resource and is not restricted to the GET method.

4102	       Unless         = "Unless" ":" 1#logic-bag

4104	   For example,

4106	       Unless: {or {ne {Content-MD5 "Q2hlY2sgSW50ZWdyaXR5IQ=="}}
4107	                   {ne {Content-Length 10036}}
4108	                   {ne {Content-Version "12.4.8"}}
4109	                   {gt {Last-Modified "Mon, 04 Dec 1995 01:23:45 GMT"}}}

4111	   Multiple Unless headers, or multiple bags separated by commas, can
4112	   be combined by OR'ing them together:

4114	       Unless: {eq {A "a"}}
4115	       Unless: {eq {B "b"}}

4117	   is equivalent to

4119	       Unless: {eq {A "a"}},{eq {B "b"}}

4121	   which in turn is equivalent to

4123	       Unless: {or {eq {A "a"}} {eq {B "b"}}}

4125	   When a request containing an Unless header field is received, the
4126	   server must evaluate the expression defined by the listed
4127	   logic-bags (Section 3.11). If the expression evaluates to false,
4128	   then no change is made to the semantics of the request. If it
4129	   evaluates true and the request is not a conditional GET
4130	   (If-Modified-Since, Section 10.23) or a partial GET (Range,
4131	   Section 10.33), then the server must abort the request and respond
4132	   with the 412 (unless true) status code. If the request is a
4133	   conditional GET, then the server must disregard the
4134	   If-Modified-Since value and respond as it would for a normal GET.
4135	   Similarly, if the request is a partial GET, then the server must
4136	   disregard the Range value and respond as it would for a normal GET.

4138	10.41  Upgrade

4140	   The Upgrade general-header allows the client to specify what
4141	   additional communication protocols it supports and would like to
4142	   use if the server finds it appropriate to switch protocols. The
4143	   server must use the Upgrade header field within a 101 (switching
4144	   protocols) response to indicate which protocol(s) are being
4145	   switched.

4147	       Upgrade        = "Upgrade" ":" 1#product

4149	   For example,

4151	       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

4153	   The purpose of the Upgrade header is to allow easier migration
4154	   across protocols in order to better match the application needs
4155	   with protocol capabilities.

4157	10.42  URI

4159	   The URI entity-header field is used to inform the recipient of
4160	   other Uniform Resource Identifiers (Section 3.2) by which the
4161	   resource can be identified, and of all negotiable variants
4162	   corresponding to the Request-URI.

4164	       URI-header  = "URI" ":" 1#( uri-mirror | uri-name | uri-variant )

4166	       uri-mirror  = "{" "mirror" <"> URI <"> "}"
4167	       uri-name    = "{" "name" <"> URI <"> "}"
4168	       uri-variant = "{" "variant" <"> URI <"> qvalue
4169	                         [ "{" "type" <"> media-type <"> "}" ]
4170	                         [ "{" "language" <"> 1#language-tag <"> "}" ]
4171	                         [ "{" "encoding" <"> 1#content-coding <"> "}" ]
4172	                         [ "{" "length" 1*DIGIT "}" ]
4173	                         [ "{" "user-agent" "}" ]
4174	                     "}"

4176	   Any URI specified in this field can be absolute or relative to the
4177	   Request-URI. The "mirror" form of URI refers to a location which is
4178	   a mirror copy of the Request-URI. The "name" form refers to a
4179	   location-independent name corresponding to the Request-URI. The
4180	   "variant" form refers to one of the set of negotiable variants that
4181	   may be retrieved via a request on the Request-URI.

4183	   If the Request-URI maps to a set of variants, then the dimensions
4184	   of that variance must be given in any response containing one of
4185	   those variants. If the Location header field is present in a 2xx
4186	   response, its value identifies which one of the variants is
4187	   included with the response. An example is:

4189	       Location: http://www.w3.org/pub/WWW/TheProject.en.html

4191	       URI: {variant "TheProject.fr.html" 1.0
4192	                    {type "text/html"} {language "fr"}},
4193	            {variant "TheProject.en.html" 1.0
4194	                    {type "text/html"} {language "en"}},
4195	            {variant "TheProject.fr.txt" 0.7
4196	                    {type "text/plain"} {language "fr"}},
4197	            {variant "TheProject.en.txt" 0.8
4198	                    {type "text/plain"} {language "en"}}

4200	   which indicates that the negotiable Request-URI covers a group of
4201	   four individual resources that vary in media type and natural
4202	   language. The type, language, encoding, and length attributes refer
4203	   to their Content-* counterparts for each resource. The user-agent
4204	   attribute indicates that the associated URI is negotiable based on
4205	   the User-Agent header field.

4207	   User agents may use this information to notify the user of
4208	   additional formats and to guide the process of reactive content
4209	   negotiation (Section 12).

4211	10.43  User-Agent

4213	   The User-Agent request-header field contains information about the
4214	   user agent originating the request. This is for statistical
4215	   purposes, the tracing of protocol violations, and automated
4216	   recognition of user agents for the sake of tailoring responses to
4217	   avoid particular user agent limitations. Although it is not
4218	   required, user agents should include this field with requests. The
4219	   field can contain multiple product tokens (Section 3.8) and
4220	   comments identifying the agent and any subproducts which form a
4221	   significant part of the user agent. By convention, the product
4222	   tokens are listed in order of their significance for identifying
4223	   the application.

4225	       User-Agent     = "User-Agent" ":" 1*( product | comment )

4227	   Example:

4229	       User-Agent: CERN-LineMode/2.15 libwww/2.17b3

4231	10.44  WWW-Authenticate

4233	   The WWW-Authenticate response-header field must be included in 401
4234	   (unauthorized) response messages. The field value consists of at
4235	   least one challenge that indicates the authentication scheme(s) and
4236	   parameters applicable to the Request-URI.

4238	       WWW-Authenticate        = "WWW-Authenticate" ":" 1#challenge

4240	   The HTTP access authentication process is described in Section 11.
4241	   User agents must take special care in parsing the WWW-Authenticate
4242	   field value if it contains more than one challenge, or if more than
4243	   one WWW-Authenticate header field is provided, since the contents
4244	   of a challenge may itself contain a comma-separated list of
4245	   authentication parameters.

4247	11.  Access Authentication

4249	   HTTP provides a simple challenge-response authentication mechanism
4250	   which may be used by a server to challenge a client request and by
4251	   a client to provide authentication information. It uses an
4252	   extensible, case-insensitive token to identify the authentication
4253	   scheme, followed by a comma-separated list of attribute-value pairs
4254	   which carry the parameters necessary for achieving authentication
4255	   via that scheme.

4257	       auth-scheme    = token

4259	       auth-param     = token "=" quoted-string

4261	   The 401 (unauthorized) response message is used by an origin server
4262	   to challenge the authorization of a user agent. This response must
4263	   include a WWW-Authenticate header field containing at least one
4264	   challenge applicable to the requested resource.

4266	       challenge      = auth-scheme 1*SP realm *( "," auth-param )

4268	       realm          = "realm" "=" realm-value
4269	       realm-value    = quoted-string

4271	   The realm attribute (case-insensitive) is required for all
4272	   authentication schemes which issue a challenge. The realm value
4273	   (case-sensitive), in combination with the canonical root URL of the
4274	   server being accessed, defines the protection space. These realms
4275	   allow the protected resources on a server to be partitioned into a
4276	   set of protection spaces, each with its own authentication scheme
4277	   and/or authorization database. The realm value is a string,
4278	   generally assigned by the origin server, which may have additional
4279	   semantics specific to the authentication scheme.

4281	   A user agent that wishes to authenticate itself with a
4282	   server--usually, but not necessarily, after receiving a 401 or 411
4283	   response--may do so by including an Authorization header field with
4284	   the request. The Authorization field value consists of credentials
4285	   containing the authentication information of the user agent for the
4286	   realm of the resource being requested.

4288	       credentials    = basic-credentials
4289	                      | auth-scheme *("," auth-param )

4291	   The domain over which credentials can be automatically applied by a
4292	   user agent is determined by the protection space. If a prior
4293	   request has been authorized, the same credentials may be reused for
4294	   all other requests within that protection space for a period of
4295	   time determined by the authentication scheme, parameters, and/or
4296	   user preference. Unless otherwise defined by the authentication
4297	   scheme, a single protection space cannot extend outside the scope
4298	   of its server.

4300	   If the server does not wish to accept the credentials sent with a
4301	   request, it should return a 401 (unauthorized) response. The
4302	   response must include a WWW-Authenticate header field containing
4303	   the (possibly new) challenge applicable to the requested resource
4304	   and an entity explaining the refusal.

4306	   The HTTP protocol does not restrict applications to this simple
4307	   challenge-response mechanism for access authentication. Additional
4308	   mechanisms may be used, such as encryption at the transport level
4309	   or via message encapsulation, and with additional header fields
4310	   specifying authentication information. However, these additional
4311	   mechanisms are not defined by this specification.

4313	   Proxies must be completely transparent regarding user agent
4314	   authentication. That is, they must forward the WWW-Authenticate and
4315	   Authorization headers untouched, and must not cache the response to
4316	   a request containing Authorization.

4318	   HTTP/1.1 allows a client pass authentication information to and
4319	   from a proxy via the Proxy-Authenticate and Proxy-Authorization
4320	   headers.

4322	11.1  Basic Authentication Scheme

4324	   The "basic" authentication scheme is based on the model that the
4325	   user agent must authenticate itself with a user-ID and a password
4326	   for each realm. The realm value should be considered an opaque
4327	   string which can only be compared for equality with other realms on
4328	   that server. The server will service the request only if it can
4329	   validate the user-ID and password for the protection space of the
4330	   Request-URI. There are no optional authentication parameters.

4332	   Upon receipt of an unauthorized request for a URI within the
4333	   protection space, the server should respond with a challenge like
4334	   the following:

4336	       WWW-Authenticate: Basic realm="WallyWorld"

4338	   where "WallyWorld" is the string assigned by the server to identify
4339	   the protection space of the Request-URI.

4341	   To receive authorization, the client sends the user-ID and
4342	   password, separated by a single colon (":") character, within a
4343	   base64 [7] encoded string in the credentials.

4345	       basic-credentials = " Basic" SP basic-cookie

4347	       basic-cookie      = <base64 [7] encoding of userid-password,
4348	                           except not limited to 76 char/line>

4350	       userid-password   = [ token ] ":" *TEXT

4352	   If the user agent wishes to send the user-ID "Aladdin" and password
4353	   "open sesame", it would use the following header field:

4355	       Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

4357	   The basic authentication scheme is a non-secure method of filtering
4358	   unauthorized access to resources on an HTTP server. It is based on
4359	   the assumption that the connection between the client and the
4360	   server can be regarded as a trusted carrier. As this is not
4361	   generally true on an open network, the basic authentication scheme
4362	   should be used accordingly. In spite of this, clients should
4363	   implement the scheme in order to communicate with servers that use
4364	   it.

4366	11.2  Digest Authentication Scheme

4368	   The "digest" authentication scheme is [currently described in an
4369	   expired Internet-Draft, and this description will have to be
4370	   improved to reference a new draft or include the old one].

4372	12.  Content Negotiation

4374	   Content negotiation is an optional feature of the HTTP protocol. It
4375	   is designed to allow for selection of a preferred content
4376	   representation based upon the attributes of the negotiable variants
4377	   corresponding to the requested resource. HTTP/1.1 provides for two
4378	   types of negotiation: preemptive and reactive.

4380	   Servers that make use of content negotiated resources must include
4381	   URI response headers which accurately describe the available
4382	   variants, and include the relevant parameters necessary for the
4383	   client (user agent or proxy) to evaluate those variants.

4385	12.1  Preemptive Negotiation

4387	   Preemptive negotiation attempts to "negotiate" the variant
4388	   parameters by including the user agent preferences within each
4389	   request. In this way, the preferred representation of the resource
4390	   may be negotiated and obtained within a single request-response
4391	   round-trip, and without intervention from the user. However, this
4392	   also means that the user agent preferences are all the time, even
4393	   though relatively few resources are ever negotiable. Preemptive
4394	   negotiation may not always be desirable for the user and is
4395	   sometimes unnecessary for the content provider. Implementors should
4396	   provide mechanisms whereby the amount of preemptive content
4397	   negotiation, and the parameters of that negotiation, are
4398	   configurable by the user and server maintainer.

4400	   The first step in the negotiation algorithm is for the server to
4401	   determine whether or not there are any content variants for the
4402	   requested resource. Content variants may be in the form of multiple
4403	   preexisting entities or a set of dynamic conversion filters. These
4404	   variants make up the set of entities which may be sent in response
4405	   to a request for the given Request-URI. In most cases, there will
4406	   only be one available form of the resource, and thus a single
4407	   "variant".

4409	   For each variant form of the resource, the server identifies a set
4410	   of quality values (Section 3.9) which act as weights for measuring
4411	   the desirability of that resource as a response to the current
4412	   request. The calculated weights are all real numbers in the range 0
4413	   through 1, where 0 is the minimum and 1 the maximum value. The
4414	   maximum acceptable bytes for each media range and the size of the
4415	   resource variant are also factors in the equation.

4417	   The following parameters are included in the calculation:

4419	      qs   Source quality is measured by the content provider as
4420	           representing the amount of degradation from the original
4421	           source. For example, a picture originally in JPEG form
4422	           would have a lower qs when translated to the XBM format,
4423	           and much lower qs when translated to an ASCII-art
4424	           representation. Note, however, that this is a function of
4425	           the source -- an original piece of ASCII-art may degrade in
4426	           quality if it is captured in JPEG form. The qs value should
4427	           be assigned to each variant by the content provider; if no
4428	           qs value has been assigned, the default is generally
4429	           "qs=1". A server may define its own default qs value based
4430	           on the resource characteristics, but only if individual
4431	           resources can override those defaults.

4433	      qe   Encoding quality is measured by comparing the variant's
4434	           applied content-codings (Section 3.5) to those listed in
4435	           the request message's Accept-Encoding field. If the variant
4436	           has no assigned Content-Encoding, or if no Accept-Encoding
4437	           field is present, the value assigned is "qe=1". If all of
4438	           the variant's content encodings are listed in the
4439	           Accept-Encoding field, then the value assigned is "qe=1".
4440	           If any of the variant's content encodings are not listed in
4441	           the provided Accept-Encoding field, then the value assigned
4442	           is "qe=0".

4444	      qc   Charset quality is measured by comparing the variant
4445	           media-type's charset parameter value (if any) to those
4446	           character sets (Section 3.4) listed in the request
4447	           message's Accept-Charset field. If the variant's media-type
4448	           has no charset parameter, or the variant's charset is
4449	           US-ASCII, or if no Accept-Charset field is present, then
4450	           the value assigned is "qc=1". If the variant's charset is
4451	           listed in the Accept-Charset field, then the value assigned
4452	           is "qc=1". Otherwise, if the variant's charset is not
4453	           listed in the provided Accept-Encoding field, then the
4454	           value assigned is "qc=0".

4456	      ql   Language quality is measured by comparing the variant's
4457	           assigned language tag(s) (Section 3.10) to those listed in
4458	           the request message's Accept-Language field. If no variant
4459	           has an assigned Content-Language, or if no Accept-Language
4460	           field is present, the value assigned is "ql=1". If at least
4461	           one variant has an assigned content language, but the one
4462	           currently under consideration does not, then it should be
4463	           assigned the value "ql=0.5". If any of the variant's
4464	           content languages are listed in the Accept-Language field,
4465	           then the value assigned is the maximum of the "q" parameter
4466	           values for those language tags (Section 10.4); if there was
4467	           no exact match and at least one of the Accept-Language
4468	           field values is a complete subtag prefix of the content
4469	           language tag(s), then the "q" parameter value of the
4470	           largest matching prefix is used. If none of the variant's
4471	           content language tags or tag prefixes are listed in the
4472	           provided Accept-Language field, then the value assigned is
4473	           "ql=0.001".

4475	      q    Media type quality is measured by comparing the variant's
4476	           assigned media type (Section 3.7) to those listed in the
4477	           request message's Accept field. If no Accept field is
4478	           given, then the value assigned is "q=1". If at least one
4479	           listed media range (Section 10.1) matches the variant's
4480	           media type, then the "q" parameter value assigned to the
4481	           most specific of those matched is used (e.g.,
4482	           "text/html;version=3.0" is more specific than "text/html",
4483	           which is more specific than "text/*", which in turn is more
4484	           specific than "*/*"). If no media range in the provided
4485	           Accept field matches the variant's media type, then the
4486	           value assigned is "q=0".

4488	      mxb  The maximum number of bytes in an Entity-Body that the
4489	           client will accept is also obtained from the matching of
4490	           the variant's assigned media type to those listed in the
4491	           request message's Accept field. If no Accept field is
4492	           given, or if no media range in the provided Accept field
4493	           matches the variant's media type, then the value assigned
4494	           is "mxb=undefined"  (i.e., infinity). Otherwise, the value
4495	           used is that given to the "mxb" parameter in the media
4496	           range chosen above for the q value.

4498	      bs   The actual number of bytes in the Entity-Body for the
4499	           variant when it is included in a response message. This
4500	           should equal the value of Content-Length.

4502	   The mapping function is defined as:

4504	      Q(qs,qe,qc,ql,     { if mxb=undefined, then (qs*qe*qc*ql*q) }
4505	         q,mxb,bs)     = { if mxb >= bs,     then (qs*qe*qc*ql*q) }
4506	                         { if mxb <  bs,     then 0               }

4508	   The variants with a maximal value for the Q function represent the
4509	   preferred representation(s) of the entity; those with a Q values
4510	   less than the maximal value are therefore excluded from further
4511	   consideration. If multiple representations exist that only vary by
4512	   Content-Encoding, then the smallest representation (lowest bs) is
4513	   preferred.

4515	   If no variants remain with a value of Q greater than zero (0), the
4516	   server should respond with a 406 (none acceptable) response
4517	   message. If multiple variants remain with an equally high Q value,
4518	   the server may either choose one from those available and respond
4519	   with 200 (ok) or respond with 300 (multiple choices) and include an
4520	   entity describing the choices. In the latter case, the entity
4521	   should either be of type "text/html', such that the user can choose
4522	   from among the choices by following an exact link, or of some type
4523	   that would allow the user agent to perform the selection
4524	   automatically.

4526	   The 300 (multiple choices) response can be given even if the server
4527	   does not perform any winnowing of the representation choices via
4528	   the content negotiation algorithm described above. Furthermore, it
4529	   may include choices that were not considered as part of the
4530	   negotiation algorithm and resources that may be located at other
4531	   servers.

4533	   The algorithm presented above assumes that the user agent has
4534	   correctly implemented the protocol and is accurately communicating
4535	   its intentions in the form of Accept-related header fields. The
4536	   server may alter its response if it knows that the particular
4537	   version of user agent software making the request has incorrectly
4538	   or inadequately implemented these fields.

4540	13.  Caching

4542	   [This will be a summary of what is already defined in the Methods,
4543	   Status Codes, Cache-Control, Unless, and If-Modified-Since
4544	   sections.]

4546	14.  Security Considerations

4548	   This section is meant to inform application developers, information
4549	   providers, and users of the security limitations in HTTP/1.1 as
4550	   described by this document. The discussion does not include
4551	   definitive solutions to the problems revealed, though it does make
4552	   some suggestions for reducing security risks.

4554	14.1  Authentication of Clients

4556	   As mentioned in Section 11.1, the Basic authentication scheme is
4557	   not a secure method of user authentication, nor does it prevent the
4558	   Entity-Body from being transmitted in clear text across the
4559	   physical network used as the carrier. HTTP does not prevent
4560	   additional authentication schemes and encryption mechanisms from
4561	   being employed to increase security.

4563	14.2  Safe Methods

4565	   The writers of client software should be aware that the software
4566	   represents the user in their interactions over the Internet, and
4567	   should be careful to allow the user to be aware of any actions they
4568	   may take which may have an unexpected significance to themselves or
4569	   others.

4571	   In particular, the convention has been established that the GET and
4572	   HEAD methods should never have the significance of taking an action
4573	   other than retrieval. These methods should be considered "safe."
4574	   This allows user agents to represent other methods, such as POST,
4575	   PUT and DELETE, in a special way, so that the user is made aware of
4576	   the fact that a possibly unsafe action is being requested.

4578	   Naturally, it is not possible to ensure that the server does not
4579	   generate side-effects as a result of performing a GET request; in
4580	   fact, some dynamic resources consider that a feature. The important
4581	   distinction here is that the user did not request the side-effects,
4582	   so therefore cannot be held accountable for them.

4584	14.3  Abuse of Server Log Information

4586	   A server is in the position to save personal data about a user's
4587	   requests which may identify their reading patterns or subjects of
4588	   interest. This information is clearly confidential in nature and
4589	   its handling may be constrained by law in certain countries. People
4590	   using the HTTP protocol to provide data are responsible for
4591	   ensuring that such material is not distributed without the
4592	   permission of any individuals that are identifiable by the
4593	   published results.

4595	14.4  Transfer of Sensitive Information

4597	   Like any generic data transfer protocol, HTTP cannot regulate the
4598	   content of the data that is transferred, nor is there any a priori
4599	   method of determining the sensitivity of any particular piece of
4600	   information within the context of any given request. Therefore,
4601	   applications should supply as much control over this information as
4602	   possible to the provider of that information. Four header fields
4603	   are worth special mention in this context: Server, Forwarded,
4604	   Referer and From.

4606	   Revealing the specific software version of the server may allow the
4607	   server machine to become more vulnerable to attacks against
4608	   software that is known to contain security holes. Implementors
4609	   should make the Server header field a configurable option.

4611	   Proxies which serve as a portal through a network firewall should
4612	   take special precautions regarding the transfer of header
4613	   information that identifies the hosts behind the firewall. In
4614	   particular, they should remove, or replace with sanitized versions,
4615	   any Forwarded fields generated behind the firewall.

4617	   The Referer field allows reading patterns to be studied and reverse
4618	   links drawn. Although it can be very useful, its power can be
4619	   abused if user details are not separated from the information
4620	   contained in the Referer. Even when the personal information has
4621	   been removed, the Referer field may indicate a private document's
4622	   URI whose publication would be inappropriate.

4624	   The information sent in the From field might conflict with the
4625	   user's privacy interests or their site's security policy, and hence
4626	   it should not be transmitted without the user being able to
4627	   disable, enable, and modify the contents of the field. The user
4628	   must be able to set the contents of this field within a user
4629	   preference or application defaults configuration.

4631	   We suggest, though do not require, that a convenient toggle
4632	   interface be provided for the user to enable or disable the sending
4633	   of From and Referer information.

4635	15.  Acknowledgments

4637	   This specification makes heavy use of the augmented BNF and generic
4638	   constructs defined by David H. Crocker for RFC 822 [9]. Similarly,
4639	   it reuses many of the definitions provided by Nathaniel Borenstein
4640	   and Ned Freed for MIME [7]. We hope that their inclusion in this
4641	   specification will help reduce past confusion over the relationship
4642	   between HTTP and Internet mail message formats.

4644	   The HTTP protocol has evolved considerably over the past four
4645	   years. It has benefited from a large and active developer
4646	   community--the many people who have participated on the www-talk
4647	   mailing list--and it is that community which has been most
4648	   responsible for the success of HTTP and of the World-Wide Web in
4649	   general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob
4650	   Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker,
4651	   H&kon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett,
4652	   Tony Sanders, and Marc VanHeyningen deserve special recognition for
4653	   their efforts in defining early aspects of the protocol.

4655	   This document has benefited greatly from the comments of all those
4656	   participating in the HTTP-WG. In addition to those already
4657	   mentioned, the following individuals have contributed to this
4658	   specification:

4660	       Gary Adams                         Harald Tveit Alvestrand
4661	       Keith Ball                         Brian Behlendorf
4662	       Paul Burchard                      Maurizio Codogno
4663	       Mike Cowlishaw                     Roman Czyborra
4664	       Michael A. Dolan                   Jim Gettys
4665	       Marc Hedlund                       Koen Holtman
4666	       Alex Hopmann                       Bob Jernigan
4667	       Shel Kaphan                        Rohit Khare
4668	       Martijn Koster                     Alexei Kosut
4669	       Dave Kristol                       Daniel LaLiberte
4670	       Paul Leach                         Albert Lunde
4671	       John C. Mallery                    Jean-Philippe Martin-Flatin
4672	       Larry Masinter                     Mitra
4673	       Jeffrey Mogul                      Gavin Nicol
4674	       Bill Perry                         Jeffrey Perry
4675	       Owen Rees                          Luigi Rizzo
4676	       David Robinson                     Marc Salomon
4677	       Rich Salz                          Jim Seidman
4678	       Chuck Shotton                      Eric W. Sink
4679	       Simon E. Spero                     Richard N. Taylor
4680	       Robert S. Thau                     Franccedillaois Yergeau
4681	       Mary Ellen Zurko

4683	16. References

4685	   [1]  H. Alvestrand. "Tags for the identification of languages." RFC
4686	        1766, UNINETT, March 1995.

4688	   [2]  F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey,
4689	        B. Alberti. "The Internet Gopher Protocol: A distributed
4690	        document search and retrieval protocol." RFC 1436, University
4691	        of Minnesota, March 1993.

4693	   [3]  T. Berners-Lee. "Universal Resource Identifiers in WWW: A
4694	        Unifying Syntax for the Expression of Names and Addresses of
4695	        Objects on the Network as used in the World-Wide Web."
4696	        RFC 1630, CERN, June 1994.

4698	   [4]  T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource
4699	        Locators (URL)." RFC 1738, CERN, Xerox PARC, University of
4700	        Minnesota, December 1994.

4702	   [5]  T. Berners-Lee, D. Connolly. "HyperText Markup Language
4703	        Specification - 2.0." RFC 1866, MIT/LCS, November 1995.

4705	   [6]  T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer
4706	        Protocol - HTTP/1.0." Work in Progress
4707	        (draft-ietf-http-v10-spec-04.txt), MIT/LCS, UC Irvine,
4708	        September 1995.

4710	   [7]  N. Borenstein, N. Freed. "MIME (Multipurpose Internet Mail
4711	        Extensions) Part One: Mechanisms for Specifying and Describing
4712	        the Format of Internet Message Bodies." RFC 1521, Bellcore,
4713	        Innosoft, September 1993.

4715	   [8]  R. Braden. "Requirements for Internet hosts - application and
4716	        support." STD 3, RFC 1123, IETF, October 1989.

4718	   [9]  D. H. Crocker. "Standard for the Format of ARPA Internet Text
4719	        Messages." STD 11, RFC 822, UDEL, August 1982.

4721	   [10] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
4722	        J. Sui, M. Grinbaum. "WAIS Interface Protocol Prototype
4723	        Functional Specification." (v1.5), Thinking Machines
4724	        Corporation, April 1990.

4726	   [11] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC
4727	        Irvine, June 1995.

4729	   [12] M. Horton, R. Adams. "Standard for interchange of USENET
4730	        messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell
4731	        Laboratories, Center for Seismic Studies, December 1987.

4733	   [13] B. Kantor, P. Lapsley. "Network News Transfer Protocol: A
4734	        Proposed Standard for the Stream-Based Transmission of News."
4735	        RFC 977, UC San Diego, UC Berkeley, February 1986.

4737	   [14] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part
4738	        Two: Message Header Extensions for Non-ASCII Text." RFC 1522,
4739	        University of Tennessee, September 1993.

4741	   [15] E. Nebel, L. Masinter. "Form-based File Upload in HTML."
4742	        RFC 1867, Xerox Corporation, November 1995.

4744	   [16] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821,
4745	        USC/ISI, August 1982.

4747	   [17] J. Postel. "Media Type Registration Procedure." RFC 1590,
4748	        USC/ISI, March 1994.

4750	   [18] J. Postel, J. K. Reynolds. "File Transfer Protocol (FTP)." STD
4751	        9, RFC 959, USC/ISI, October 1985.

4753	   [19] J. Reynolds, J. Postel. "Assigned Numbers." STD 2, RFC 1700,
4754	        USC/ISI, October 1994.

4756	   [20] K. Sollins, L. Masinter. "Functional Requirements for Uniform
4757	        Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, December
4758	        1994.

4760	   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code
4761	        for Information Interchange. Standard ANSI X3.4-1986, ANSI,
4762	        1986.

4764	   [22] ISO-8859. International Standard -- Information Processing --
4765	        8-bit Single-Byte Coded Graphic Character Sets --
4766	        Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
4767	        Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
4768	        Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
4769	        Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
4770	        Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
4771	        Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
4772	        Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
4773	        Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
4774	        Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

4776	17.  Authors' Addresses

4778	   Roy T. Fielding
4779	   Department of Information and Computer Science
4780	   University of California
4781	   Irvine, CA 92717-3425, U.S.A.
4782	   Fax: +1 (714) 824-4056
4783	   Email: fielding@ics.uci.edu

4785	   Henrik Frystyk Nielsen
4786	   W3 Consortium
4787	   MIT Laboratory for Computer Science
4788	   545 Technology Square
4789	   Cambridge, MA 02139, U.S.A.
4790	   Fax: +1 (617) 258 8682
4791	   Email: frystyk@w3.org

4793	   Tim Berners-Lee
4794	   Director, W3 Consortium
4795	   MIT Laboratory for Computer Science
4796	   545 Technology Square
4797	   Cambridge, MA 02139, U.S.A.
4798	   Fax: +1 (617) 258 8682
4799	   Email: timbl@w3.org

4801	Appendices

4803	   These appendices are provided for informational reasons only -- they
4804	   do not form a part of the HTTP/1.1 specification.

4806	A.  Internet Media Type message/http

4808	   In addition to defining the HTTP/1.1 protocol, this document serves
4809	   as the specification for the Internet media type "message/http".
4810	   The following is to be registered with IANA [17].

4812	       Media Type name:         message

4814	       Media subtype name:      http

4816	       Required parameters:     none

4818	       Optional parameters:     version, msgtype

4820	              version: The HTTP-Version number of the enclosed message
4821	                       (e.g., "1.1"). If not present, the version can be
4822	                       determined from the first line of the body.

4824	              msgtype: The message type -- "request" or "response". If
4825	                       not present, the type can be determined from the
4826	                       first line of the body.

4828	       Encoding considerations: only "7bit", "8bit", or "binary" are
4829	                                permitted

4831	       Security considerations: none

4833	B.  Tolerant Applications

4835	   Although this document specifies the requirements for the
4836	   generation of HTTP/1.1 messages, not all applications will be
4837	   correct in their implementation. We therefore recommend that
4838	   operational applications be tolerant of deviations whenever those
4839	   deviations can be interpreted unambiguously.

4841	   Clients should be tolerant in parsing the Status-Line and servers
4842	   tolerant when parsing the Request-Line. In particular, they should
4843	   accept any amount of SP or HT characters between fields, even
4844	   though only a single SP is required.

4846	   The line terminator for HTTP-header fields is the sequence CRLF.
4847	   However, we recommend that applications, when parsing such headers,
4848	   recognize a single LF as a line terminator and ignore the leading
4849	   CR.

4851	C.  Relationship to MIME

4853	   HTTP/1.1 reuses many of the constructs defined for Internet Mail
4854	   (RFC 822 [9]) and the Multipurpose Internet Mail Extensions
4855	   (MIME [7]) to allow entities to be transmitted in an open variety
4856	   of representations and with extensible mechanisms. However, HTTP is
4857	   not a MIME-compliant application. HTTP's performance requirements
4858	   differ substantially from those of Internet mail. Since it is not
4859	   limited by the restrictions of existing mail protocols and SMTP
4860	   gateways, HTTP does not obey some of the constraints imposed by
4861	   RFC 822 and MIME for mail transport.

4863	   This appendix describes specific areas where HTTP differs from
4864	   MIME. Proxies/gateways to MIME-compliant protocols must be aware of
4865	   these differences and provide the appropriate conversions where
4866	   necessary.

4868	C.1  Conversion to Canonical Form

4870	   MIME requires that an entity be converted to canonical form prior
4871	   to being transferred, as described in Appendix G of RFC 1521 [7].
4872	   Although HTTP does require media types to be transferred in
4873	   canonical form, it changes the definition of "canonical form" for
4874	   text-based media types as described in Section 3.7.1.

4876	C.1.1 Representation of Line Breaks

4878	   MIME requires that the canonical form of any text type represent
4879	   line breaks as CRLF and forbids the use of CR or LF outside of line
4880	   break sequences. Since HTTP allows CRLF, bare CR, and bare LF (or
4881	   the octet sequence(s) to which they would be translated for the
4882	   given character set) to indicate a line break within text content,
4883	   recipients of an HTTP message cannot rely upon receiving
4884	   MIME-canonical line breaks in text.

4886	   Where it is possible, a proxy/gateway from HTTP to a MIME-compliant
4887	   protocol should translate all line breaks within text/* media types
4888	   to the MIME canonical form of CRLF. However, this may be
4889	   complicated by the presence of a Content-Encoding and by the fact
4890	   that HTTP allows the use of some character sets which do not use
4891	   octets 13 and 10 to represent CR and LF, as is the case for some
4892	   multi-byte character sets. If canonicalization is performed, the
4893	   Content-Length header field value must be updated to reflect the
4894	   new body length.

4896	C.1.2 Default Character Set

4898	   MIME requires that all subtypes of the top-level Content-Type
4899	   "text" have a default character set of US-ASCII [21]. In contrast,
4900	   HTTP defines the default character set for "text" to be
4901	   ISO-8859-1 [22] (a superset of US-ASCII). Therefore, if a text/*
4902	   media type given in the Content-Type header field does not already
4903	   include an explicit charset parameter, the parameter

4905	       ;charset="iso-8859-1"

4907	   should be added by the proxy/gateway if the entity contains any
4908	   octets greater than 127.

4910	C.2  Conversion of Date Formats

4912	   HTTP/1.1 uses a restricted subset of date formats to simplify the
4913	   process of date comparison. Proxies/gateways from other protocols
4914	   should ensure that any Date header field present in a message
4915	   conforms to one of the HTTP/1.1 formats and rewrite the date if
4916	   necessary.

4918	C.3  Introduction of Content-Encoding

4920	   MIME does not include any concept equivalent to HTTP's
4921	   Content-Encoding header field. Since this acts as a modifier on the
4922	   media type, proxies/gateways to MIME-compliant protocols must
4923	   either change the value of the Content-Type header field or decode
4924	   the Entity-Body before forwarding the message.

4926	       Note: Some experimental applications of Content-Type for
4927	       Internet mail have used a media-type parameter of
4928	       ";conversions=<content-coding>" to perform an equivalent
4929	       function as Content-Encoding. However, this parameter is not
4930	       part of the MIME specification at the time of this writing.

4932	C.4  No Content-Transfer-Encoding

4934	   HTTP does not use the Content-Transfer-Encoding (CTE) field of
4935	   MIME. Proxies/gateways from MIME-compliant protocols must remove
4936	   any non-identity CTE ("quoted-printable" or "base64") encoding
4937	   prior to delivering the response message to an HTTP client.
4938	   Proxies/gateways to MIME-compliant protocols are responsible for
4939	   ensuring that the message is in the correct format and encoding for
4940	   safe transport on that protocol, where "safe transport" is defined
4941	   by the limitations of the protocol being used. At a minimum, the
4942	   CTE field of

4944	       Content-Transfer-Encoding: binary

4946	   should be added by the proxy/gateway if it is unwilling to apply a
4947	   content transfer encoding.

4949	   An HTTP client may include a Content-Transfer-Encoding as an
4950	   extension Entity-Header in a POST request when it knows the
4951	   destination of that request is a proxy/gateway to a MIME-compliant
4952	   protocol.

4954	C.5  Introduction of Transfer-Encoding

4956	   HTTP/1.1 introduces the Transfer-Encoding header field
4957	   (Section 10.39). Proxies/gateways must remove any transfer coding
4958	   prior to forwarding a message via a MIME-compliant protocol. The
4959	   process for decoding the "chunked" transfer coding (Section 3.6)
4960	   can be represented in pseudo-code as:

4962	       length := 0
4963	       read chunk-size and CRLF
4964	       while (chunk-size > 0) {
4965	          read chunk-data and CRLF
4966	          append chunk-data to Entity-Body
4967	          length := length + chunk-size
4968	          read chunk-size and CRLF
4969	       }
4970	       read entity-header
4971	       while (entity-header not empty) {
4972	          append entity-header to existing header fields
4973	          read entity-header
4974	       }
4975	       Content-Length := length
4976	       Remove "chunked" from Transfer-Encoding

4978	D.  Changes from HTTP/1.0

4980	   This section will summarize the differences between versions 1.0
4981	   and 1.1 of the Hypertext Transfer Protocol.