5Internet Engineering Task Force (IETF) R. Fielding, Ed.
6Request for Comments: 9110 Adobe
7STD: 97 M. Nottingham, Ed.
8Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, Fastly
9 7538, 7615, 7694 J. Reschke, Ed.
10Updates: 3864 greenbytes
11Category: Standards Track June 2022
19 The Hypertext Transfer Protocol (HTTP) is a stateless application-
20 level protocol for distributed, collaborative, hypertext information
21 systems. This document describes the overall architecture of HTTP,
22 establishes common terminology, and defines aspects of the protocol
23 that are shared by all versions. In this definition are core
24 protocol elements, extensibility mechanisms, and the "http" and
25 "https" Uniform Resource Identifier (URI) schemes.
27 This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232,
28 7233, 7235, 7538, 7615, 7694, and portions of 7230.
32 This is an Internet Standards Track document.
34 This document is a product of the Internet Engineering Task Force
35 (IETF). It represents the consensus of the IETF community. It has
36 received public review and has been approved for publication by the
37 Internet Engineering Steering Group (IESG). Further information on
38 Internet Standards is available in Section 2 of RFC 7841.
40 Information about the current status of this document, any errata,
41 and how to provide feedback on it may be obtained at
42 https://www.rfc-editor.org/info/rfc9110.
46 Copyright (c) 2022 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (https://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Revised BSD License text as described in Section 4.e of the
56 Trust Legal Provisions and are provided without warranty as described
57 in the Revised BSD License.
59 This document may contain material from IETF Documents or IETF
60 Contributions published or made publicly available before November
61 10, 2008. The person(s) controlling the copyright in some of this
62 material may not have granted the IETF Trust the right to allow
63 modifications of such material outside the IETF Standards Process.
64 Without obtaining an adequate license from the person(s) controlling
65 the copyright in such materials, this document may not be modified
66 outside the IETF Standards Process, and derivative works of it may
67 not be created outside the IETF Standards Process, except to format
68 it for publication as an RFC or to translate it into languages other
75 1.2. History and Evolution
77 1.4. Specifications Obsoleted by This Document
80 2.2. Requirements Notation
81 2.3. Length Requirements
84 3. Terminology and Core Concepts
87 3.3. Connections, Clients, and Servers
93 3.9. Example Message Exchange
94 4. Identifiers in HTTP
96 4.2. HTTP-Related URI Schemes
97 4.2.1. http URI Scheme
98 4.2.2. https URI Scheme
99 4.2.3. http(s) Normalization and Comparison
100 4.2.4. Deprecation of userinfo in http(s) URIs
101 4.2.5. http(s) References with Fragment Identifiers
102 4.3. Authoritative Access
106 4.3.4. https Certificate Verification
107 4.3.5. IP-ID Reference Identity
110 5.2. Field Lines and Combined Field Value
114 5.6. Common Rules for Defining Field Values
115 5.6.1. Lists (#rule ABNF Extension)
116 5.6.1.1. Sender Requirements
117 5.6.1.2. Recipient Requirements
120 5.6.4. Quoted Strings
123 5.6.7. Date/Time Formats
124 6. Message Abstraction
125 6.1. Framing and Completeness
129 6.4.1. Content Semantics
130 6.4.2. Identifying Content
132 6.5.1. Limitations on Use of Trailers
133 6.5.2. Processing Trailer Fields
134 6.6. Message Metadata
137 7. Routing HTTP Messages
138 7.1. Determining the Target Resource
139 7.2. Host and :authority
140 7.3. Routing Inbound Requests
144 7.4. Rejecting Misdirected Requests
145 7.5. Response Correlation
146 7.6. Message Forwarding
150 7.7. Message Transformations
152 8. Representation Data and Metadata
153 8.1. Representation Data
154 8.2. Representation Metadata
158 8.3.3. Multipart Types
159 8.4. Content-Encoding
160 8.4.1. Content Codings
161 8.4.1.1. Compress Coding
162 8.4.1.2. Deflate Coding
164 8.5. Content-Language
167 8.7. Content-Location
168 8.8. Validator Fields
169 8.8.1. Weak versus Strong
176 8.8.3.3. Example: Entity Tags Varying on Content-Negotiated
180 9.2. Common Method Properties
182 9.2.2. Idempotent Methods
183 9.2.3. Methods and Caching
184 9.3. Method Definitions
194 10.1. Request Context Fields
200 10.2. Response Context Fields
205 11. HTTP Authentication
206 11.1. Authentication Scheme
207 11.2. Authentication Parameters
208 11.3. Challenge and Response
210 11.5. Establishing a Protection Space (Realm)
211 11.6. Authenticating Users to Origin Servers
212 11.6.1. WWW-Authenticate
213 11.6.2. Authorization
214 11.6.3. Authentication-Info
215 11.7. Authenticating Clients to Proxies
216 11.7.1. Proxy-Authenticate
217 11.7.2. Proxy-Authorization
218 11.7.3. Proxy-Authentication-Info
219 12. Content Negotiation
220 12.1. Proactive Negotiation
221 12.2. Reactive Negotiation
222 12.3. Request Content Negotiation
223 12.4. Content Negotiation Field Features
225 12.4.2. Quality Values
226 12.4.3. Wildcard Values
227 12.5. Content Negotiation Fields
229 12.5.2. Accept-Charset
230 12.5.3. Accept-Encoding
231 12.5.4. Accept-Language
233 13. Conditional Requests
236 13.1.2. If-None-Match
237 13.1.3. If-Modified-Since
238 13.1.4. If-Unmodified-Since
240 13.2. Evaluation of Preconditions
241 13.2.1. When to Evaluate
242 13.2.2. Precedence of Preconditions
245 14.1.1. Range Specifiers
251 14.6. Media Type multipart/byteranges
253 15.1. Overview of Status Codes
254 15.2. Informational 1xx
256 15.2.2. 101 Switching Protocols
261 15.3.4. 203 Non-Authoritative Information
262 15.3.5. 204 No Content
263 15.3.6. 205 Reset Content
264 15.3.7. 206 Partial Content
265 15.3.7.1. Single Part
266 15.3.7.2. Multiple Parts
267 15.3.7.3. Combining Parts
268 15.4. Redirection 3xx
269 15.4.1. 300 Multiple Choices
270 15.4.2. 301 Moved Permanently
272 15.4.4. 303 See Other
273 15.4.5. 304 Not Modified
274 15.4.6. 305 Use Proxy
276 15.4.8. 307 Temporary Redirect
277 15.4.9. 308 Permanent Redirect
278 15.5. Client Error 4xx
279 15.5.1. 400 Bad Request
280 15.5.2. 401 Unauthorized
281 15.5.3. 402 Payment Required
282 15.5.4. 403 Forbidden
283 15.5.5. 404 Not Found
284 15.5.6. 405 Method Not Allowed
285 15.5.7. 406 Not Acceptable
286 15.5.8. 407 Proxy Authentication Required
287 15.5.9. 408 Request Timeout
288 15.5.10. 409 Conflict
290 15.5.12. 411 Length Required
291 15.5.13. 412 Precondition Failed
292 15.5.14. 413 Content Too Large
293 15.5.15. 414 URI Too Long
294 15.5.16. 415 Unsupported Media Type
295 15.5.17. 416 Range Not Satisfiable
296 15.5.18. 417 Expectation Failed
297 15.5.19. 418 (Unused)
298 15.5.20. 421 Misdirected Request
299 15.5.21. 422 Unprocessable Content
300 15.5.22. 426 Upgrade Required
301 15.6. Server Error 5xx
302 15.6.1. 500 Internal Server Error
303 15.6.2. 501 Not Implemented
304 15.6.3. 502 Bad Gateway
305 15.6.4. 503 Service Unavailable
306 15.6.5. 504 Gateway Timeout
307 15.6.6. 505 HTTP Version Not Supported
309 16.1. Method Extensibility
310 16.1.1. Method Registry
311 16.1.2. Considerations for New Methods
312 16.2. Status Code Extensibility
313 16.2.1. Status Code Registry
314 16.2.2. Considerations for New Status Codes
315 16.3. Field Extensibility
316 16.3.1. Field Name Registry
317 16.3.2. Considerations for New Fields
318 16.3.2.1. Considerations for New Field Names
319 16.3.2.2. Considerations for New Field Values
320 16.4. Authentication Scheme Extensibility
321 16.4.1. Authentication Scheme Registry
322 16.4.2. Considerations for New Authentication Schemes
323 16.5. Range Unit Extensibility
324 16.5.1. Range Unit Registry
325 16.5.2. Considerations for New Range Units
326 16.6. Content Coding Extensibility
327 16.6.1. Content Coding Registry
328 16.6.2. Considerations for New Content Codings
329 16.7. Upgrade Token Registry
330 17. Security Considerations
331 17.1. Establishing Authority
332 17.2. Risks of Intermediaries
333 17.3. Attacks Based on File and Path Names
334 17.4. Attacks Based on Command, Code, or Query Injection
335 17.5. Attacks via Protocol Element Length
336 17.6. Attacks Using Shared-Dictionary Compression
337 17.7. Disclosure of Personal Information
338 17.8. Privacy of Server Log Information
339 17.9. Disclosure of Sensitive Information in URIs
340 17.10. Application Handling of Field Names
341 17.11. Disclosure of Fragment after Redirects
342 17.12. Disclosure of Product Information
343 17.13. Browser Fingerprinting
344 17.14. Validator Retention
345 17.15. Denial-of-Service Attacks Using Range
346 17.16. Authentication Considerations
347 17.16.1. Confidentiality of Credentials
348 17.16.2. Credentials and Idle Clients
349 17.16.3. Protection Spaces
350 17.16.4. Additional Response Fields
351 18. IANA Considerations
352 18.1. URI Scheme Registration
353 18.2. Method Registration
354 18.3. Status Code Registration
355 18.4. Field Name Registration
356 18.5. Authentication Scheme Registration
357 18.6. Content Coding Registration
358 18.7. Range Unit Registration
359 18.8. Media Type Registration
360 18.9. Port Registration
361 18.10. Upgrade Token Registration
363 19.1. Normative References
364 19.2. Informative References
365 Appendix A. Collected ABNF
366 Appendix B. Changes from Previous RFCs
367 B.1. Changes from RFC 2818
368 B.2. Changes from RFC 7230
369 B.3. Changes from RFC 7231
370 B.4. Changes from RFC 7232
371 B.5. Changes from RFC 7233
372 B.6. Changes from RFC 7235
373 B.7. Changes from RFC 7538
374 B.8. Changes from RFC 7615
375 B.9. Changes from RFC 7694
384 The Hypertext Transfer Protocol (HTTP) is a family of stateless,
385 application-level, request/response protocols that share a generic
386 interface, extensible semantics, and self-descriptive messages to
387 enable flexible interaction with network-based hypertext information
390 HTTP hides the details of how a service is implemented by presenting
391 a uniform interface to clients that is independent of the types of
392 resources provided. Likewise, servers do not need to be aware of
393 each client's purpose: a request can be considered in isolation
394 rather than being associated with a specific type of client or a
395 predetermined sequence of application steps. This allows general-
396 purpose implementations to be used effectively in many different
397 contexts, reduces interaction complexity, and enables independent
400 HTTP is also designed for use as an intermediation protocol, wherein
401 proxies and gateways can translate non-HTTP information systems into
402 a more generic interface.
404 One consequence of this flexibility is that the protocol cannot be
405 defined in terms of what occurs behind the interface. Instead, we
406 are limited to defining the syntax of communication, the intent of
407 received communication, and the expected behavior of recipients. If
408 the communication is considered in isolation, then successful actions
409 ought to be reflected in corresponding changes to the observable
410 interface provided by servers. However, since multiple clients might
411 act in parallel and perhaps at cross-purposes, we cannot require that
412 such changes be observable beyond the scope of a single response.
4141.2. History and Evolution
416 HTTP has been the primary information transfer protocol for the World
417 Wide Web since its introduction in 1990. It began as a trivial
418 mechanism for low-latency requests, with a single method (GET) to
419 request transfer of a presumed hypertext document identified by a
420 given pathname. As the Web grew, HTTP was extended to enclose
421 requests and responses within messages, transfer arbitrary data
422 formats using MIME-like media types, and route requests through
423 intermediaries. These protocols were eventually defined as HTTP/0.9
424 and HTTP/1.0 (see [HTTP/1.0]).
426 HTTP/1.1 was designed to refine the protocol's features while
427 retaining compatibility with the existing text-based messaging
428 syntax, improving its interoperability, scalability, and robustness
429 across the Internet. This included length-based data delimiters for
430 both fixed and dynamic (chunked) content, a consistent framework for
431 content negotiation, opaque validators for conditional requests,
432 cache controls for better cache consistency, range requests for
433 partial updates, and default persistent connections. HTTP/1.1 was
434 introduced in 1995 and published on the Standards Track in 1997
435 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014
436 ([RFC7230] through [RFC7235]).
438 HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of
439 the existing TLS and TCP protocols for exchanging concurrent HTTP
440 messages with efficient field compression and server push. HTTP/3
441 ([HTTP/3]) provides greater independence for concurrent messages by
442 using QUIC as a secure multiplexed transport over UDP instead of TCP.
444 All three major versions of HTTP rely on the semantics defined by
445 this document. They have not obsoleted each other because each one
446 has specific benefits and limitations depending on the context of
447 use. Implementations are expected to choose the most appropriate
448 transport and messaging syntax for their particular context.
450 This revision of HTTP separates the definition of semantics (this
451 document) and caching ([CACHING]) from the current HTTP/1.1 messaging
452 syntax ([HTTP/1.1]) to allow each major protocol version to progress
453 independently while referring to the same core semantics.
457 HTTP provides a uniform interface for interacting with a resource
458 (Section 3.1) -- regardless of its type, nature, or implementation --
459 by sending messages that manipulate or transfer representations
462 Each message is either a request or a response. A client constructs
463 request messages that communicate its intentions and routes those
464 messages toward an identified origin server. A server listens for
465 requests, parses each message received, interprets the message
466 semantics in relation to the identified target resource, and responds
467 to that request with one or more response messages. The client
468 examines received responses to see if its intentions were carried
469 out, determining what to do next based on the status codes and
472 HTTP semantics include the intentions defined by each request method
473 (Section 9), extensions to those semantics that might be described in
474 request header fields, status codes that describe the response
475 (Section 15), and other control data and resource metadata that might
476 be given in response fields.
478 Semantics also include representation metadata that describe how
479 content is intended to be interpreted by a recipient, request header
480 fields that might influence content selection, and the various
481 selection algorithms that are collectively referred to as "content
482 negotiation" (Section 12).
4841.4. Specifications Obsoleted by This Document
486 +============================================+===========+=====+
487 | Title | Reference | See |
488 +============================================+===========+=====+
489 | HTTP Over TLS | [RFC2818] | B.1 |
490 +--------------------------------------------+-----------+-----+
491 | HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
492 +--------------------------------------------+-----------+-----+
493 | HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
494 +--------------------------------------------+-----------+-----+
495 | HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
496 +--------------------------------------------+-----------+-----+
497 | HTTP/1.1 Range Requests | [RFC7233] | B.5 |
498 +--------------------------------------------+-----------+-----+
499 | HTTP/1.1 Authentication | [RFC7235] | B.6 |
500 +--------------------------------------------+-----------+-----+
501 | HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 |
502 +--------------------------------------------+-----------+-----+
503 | HTTP Authentication-Info and Proxy- | [RFC7615] | B.8 |
504 | Authentication-Info Response Header Fields | | |
505 +--------------------------------------------+-----------+-----+
506 | HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
507 +--------------------------------------------+-----------+-----+
511 [*] This document only obsoletes the portions of RFC 7230 that are
512 independent of the HTTP/1.1 messaging syntax and connection
513 management; the remaining bits of RFC 7230 are obsoleted by
514 "HTTP/1.1" [HTTP/1.1].
520 This specification uses the Augmented Backus-Naur Form (ABNF)
521 notation of [RFC5234], extended with the notation for case-
522 sensitivity in strings defined in [RFC7405].
524 It also uses a list extension, defined in Section 5.6.1, that allows
525 for compact definition of comma-separated lists using a "#" operator
526 (similar to how the "*" operator indicates repetition). Appendix A
527 shows the collected grammar with all list operators expanded to
528 standard ABNF notation.
530 As a convention, ABNF rule names prefixed with "obs-" denote obsolete
531 grammar rules that appear for historical reasons.
533 The following core rules are included by reference, as defined in
534 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
535 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
536 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
537 (line feed), OCTET (any 8-bit sequence of data), SP (space), and
538 VCHAR (any visible US-ASCII character).
540 Section 5.6 defines some generic syntactic components for field
543 This specification uses the terms "character", "character encoding
544 scheme", "charset", and "protocol element" as they are defined in
5472.2. Requirements Notation
549 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
550 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
551 "OPTIONAL" in this document are to be interpreted as described in
552 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
553 capitals, as shown here.
555 This specification targets conformance criteria according to the role
556 of a participant in HTTP communication. Hence, requirements are
557 placed on senders, recipients, clients, servers, user agents,
558 intermediaries, origin servers, proxies, gateways, or caches,
559 depending on what behavior is being constrained by the requirement.
560 Additional requirements are placed on implementations, resource
561 owners, and protocol element registrations when they apply beyond the
562 scope of a single communication.
564 The verb "generate" is used instead of "send" where a requirement
565 applies only to implementations that create the protocol element,
566 rather than an implementation that forwards a received element
569 An implementation is considered conformant if it complies with all of
570 the requirements associated with the roles it partakes in HTTP.
572 A sender MUST NOT generate protocol elements that do not match the
573 grammar defined by the corresponding ABNF rules. Within a given
574 message, a sender MUST NOT generate protocol elements or syntax
575 alternatives that are only allowed to be generated by participants in
576 other roles (i.e., a role that the sender does not have for that
579 Conformance to HTTP includes both conformance to the particular
580 messaging syntax of the protocol version in use and conformance to
581 the semantics of protocol elements sent. For example, a client that
582 claims conformance to HTTP/1.1 but fails to recognize the features
583 required of HTTP/1.1 recipients will fail to interoperate with
584 servers that adjust their responses in accordance with those claims.
585 Features that reflect user choices, such as content negotiation and
586 user-selected extensions, can impact application behavior beyond the
587 protocol stream; sending protocol elements that inaccurately reflect
588 a user's choices will confuse the user and inhibit choice.
590 When an implementation fails semantic conformance, recipients of that
591 implementation's messages will eventually develop workarounds to
592 adjust their behavior accordingly. A recipient MAY employ such
593 workarounds while remaining conformant to this protocol if the
594 workarounds are limited to the implementations at fault. For
595 example, servers often scan portions of the User-Agent field value,
596 and user agents often scan the Server field value, to adjust their
597 own behavior with respect to known bugs or poorly chosen defaults.
5992.3. Length Requirements
601 A recipient SHOULD parse a received protocol element defensively,
602 with only marginal expectations that the element will conform to its
603 ABNF grammar and fit within a reasonable buffer size.
605 HTTP does not have specific length limitations for many of its
606 protocol elements because the lengths that might be appropriate will
607 vary widely, depending on the deployment context and purpose of the
608 implementation. Hence, interoperability between senders and
609 recipients depends on shared expectations regarding what is a
610 reasonable length for each protocol element. Furthermore, what is
611 commonly understood to be a reasonable length for some protocol
612 elements has changed over the course of the past three decades of
613 HTTP use and is expected to continue changing in the future.
615 At a minimum, a recipient MUST be able to parse and process protocol
616 element lengths that are at least as long as the values that it
617 generates for those same protocol elements in other messages. For
618 example, an origin server that publishes very long URI references to
619 its own resources needs to be able to parse and process those same
620 references when received as a target URI.
622 Many received protocol elements are only parsed to the extent
623 necessary to identify and forward that element downstream. For
624 example, an intermediary might parse a received field into its field
625 name and field value components, but then forward the field without
626 further parsing inside the field value.
630 A recipient MUST interpret a received protocol element according to
631 the semantics defined for it by this specification, including
632 extensions to this specification, unless the recipient has determined
633 (through experience or configuration) that the sender incorrectly
634 implements what is implied by those semantics. For example, an
635 origin server might disregard the contents of a received
636 Accept-Encoding header field if inspection of the User-Agent header
637 field indicates a specific implementation version that is known to
638 fail on receipt of certain content codings.
640 Unless noted otherwise, a recipient MAY attempt to recover a usable
641 protocol element from an invalid construct. HTTP does not define
642 specific error handling mechanisms except when they have a direct
643 impact on security, since different applications of the protocol
644 require different error handling strategies. For example, a Web
645 browser might wish to transparently recover from a response where the
646 Location header field doesn't parse according to the ABNF, whereas a
647 systems control client might consider any form of error recovery to
650 Some requests can be automatically retried by a client in the event
651 of an underlying connection failure, as described in Section 9.2.2.
655 HTTP's version number consists of two decimal digits separated by a
656 "." (period or decimal point). The first digit (major version)
657 indicates the messaging syntax, whereas the second digit (minor
658 version) indicates the highest minor version within that major
659 version to which the sender is conformant (able to understand for
660 future communication).
662 While HTTP's core semantics don't change between protocol versions,
663 their expression "on the wire" can change, and so the HTTP version
664 number changes when incompatible changes are made to the wire format.
665 Additionally, HTTP allows incremental, backwards-compatible changes
666 to be made to the protocol without changing its version through the
667 use of defined extension points (Section 16).
669 The protocol version as a whole indicates the sender's conformance
670 with the set of requirements laid out in that version's corresponding
671 specification(s). For example, the version "HTTP/1.1" is defined by
672 the combined specifications of this document, "HTTP Caching"
673 [CACHING], and "HTTP/1.1" [HTTP/1.1].
675 HTTP's major version number is incremented when an incompatible
676 message syntax is introduced. The minor number is incremented when
677 changes made to the protocol have the effect of adding to the message
678 semantics or implying additional capabilities of the sender.
680 The minor version advertises the sender's communication capabilities
681 even when the sender is only using a backwards-compatible subset of
682 the protocol, thereby letting the recipient know that more advanced
683 features can be used in response (by servers) or in future requests
686 When a major version of HTTP does not define any minor versions, the
687 minor version "0" is implied. The "0" is used when referring to that
688 protocol within elements that require a minor version identifier.
6903. Terminology and Core Concepts
692 HTTP was created for the World Wide Web (WWW) architecture and has
693 evolved over time to support the scalability needs of a worldwide
694 hypertext system. Much of that architecture is reflected in the
695 terminology used to define HTTP.
699 The target of an HTTP request is called a "resource". HTTP does not
700 limit the nature of a resource; it merely defines an interface that
701 might be used to interact with resources. Most resources are
702 identified by a Uniform Resource Identifier (URI), as described in
705 One design goal of HTTP is to separate resource identification from
706 request semantics, which is made possible by vesting the request
707 semantics in the request method (Section 9) and a few request-
708 modifying header fields. A resource cannot treat a request in a
709 manner inconsistent with the semantics of the method of the request.
710 For example, though the URI of a resource might imply semantics that
711 are not safe, a client can expect the resource to avoid actions that
712 are unsafe when processing a request with a safe method (see
715 HTTP relies upon the Uniform Resource Identifier (URI) standard [URI]
716 to indicate the target resource (Section 7.1) and relationships
721 A "representation" is information that is intended to reflect a past,
722 current, or desired state of a given resource, in a format that can
723 be readily communicated via the protocol. A representation consists
724 of a set of representation metadata and a potentially unbounded
725 stream of representation data (Section 8).
727 HTTP allows "information hiding" behind its uniform interface by
728 defining communication with respect to a transferable representation
729 of the resource state, rather than transferring the resource itself.
730 This allows the resource identified by a URI to be anything,
731 including temporal functions like "the current weather in Laguna
732 Beach", while potentially providing information that represents that
733 resource at the time a message is generated [REST].
735 The uniform interface is similar to a window through which one can
736 observe and act upon a thing only through the communication of
737 messages to an independent actor on the other side. A shared
738 abstraction is needed to represent ("take the place of") the current
739 or desired state of that thing in our communications. When a
740 representation is hypertext, it can provide both a representation of
741 the resource state and processing instructions that help guide the
742 recipient's future interactions.
744 A target resource might be provided with, or be capable of
745 generating, multiple representations that are each intended to
746 reflect the resource's current state. An algorithm, usually based on
747 content negotiation (Section 12), would be used to select one of
748 those representations as being most applicable to a given request.
749 This "selected representation" provides the data and metadata for
750 evaluating conditional requests (Section 13) and constructing the
751 content for 200 (OK), 206 (Partial Content), and 304 (Not Modified)
752 responses to GET (Section 9.3.1).
7543.3. Connections, Clients, and Servers
756 HTTP is a client/server protocol that operates over a reliable
757 transport- or session-layer "connection".
759 An HTTP "client" is a program that establishes a connection to a
760 server for the purpose of sending one or more HTTP requests. An HTTP
761 "server" is a program that accepts connections in order to service
762 HTTP requests by sending HTTP responses.
764 The terms client and server refer only to the roles that these
765 programs perform for a particular connection. The same program might
766 act as a client on some connections and a server on others.
768 HTTP is defined as a stateless protocol, meaning that each request
769 message's semantics can be understood in isolation, and that the
770 relationship between connections and messages on them has no impact
771 on the interpretation of those messages. For example, a CONNECT
772 request (Section 9.3.6) or a request with the Upgrade header field
773 (Section 7.8) can occur at any time, not just in the first message on
774 a connection. Many implementations depend on HTTP's stateless design
775 in order to reuse proxied connections or dynamically load balance
776 requests across multiple servers.
778 As a result, a server MUST NOT assume that two requests on the same
779 connection are from the same user agent unless the connection is
780 secured and specific to that agent. Some non-standard HTTP
781 extensions (e.g., [RFC4559]) have been known to violate this
782 requirement, resulting in security and interoperability problems.
786 HTTP is a stateless request/response protocol for exchanging
787 "messages" across a connection. The terms "sender" and "recipient"
788 refer to any implementation that sends or receives a given message,
791 A client sends requests to a server in the form of a "request"
792 message with a method (Section 9) and request target (Section 7.1).
793 The request might also contain header fields (Section 6.3) for
794 request modifiers, client information, and representation metadata,
795 content (Section 6.4) intended for processing in accordance with the
796 method, and trailer fields (Section 6.5) to communicate information
797 collected while sending the content.
799 A server responds to a client's request by sending one or more
800 "response" messages, each including a status code (Section 15). The
801 response might also contain header fields for server information,
802 resource metadata, and representation metadata, content to be
803 interpreted in accordance with the status code, and trailer fields to
804 communicate information collected while sending the content.
808 The term "user agent" refers to any of the various client programs
809 that initiate a request.
811 The most familiar form of user agent is the general-purpose Web
812 browser, but that's only a small percentage of implementations.
813 Other common user agents include spiders (web-traversing robots),
814 command-line tools, billboard screens, household appliances, scales,
815 light bulbs, firmware update scripts, mobile apps, and communication
816 devices in a multitude of shapes and sizes.
818 Being a user agent does not imply that there is a human user directly
819 interacting with the software agent at the time of a request. In
820 many cases, a user agent is installed or configured to run in the
821 background and save its results for later inspection (or save only a
822 subset of those results that might be interesting or erroneous).
823 Spiders, for example, are typically given a start URI and configured
824 to follow certain behavior while crawling the Web as a hypertext
827 Many user agents cannot, or choose not to, make interactive
828 suggestions to their user or provide adequate warning for security or
829 privacy concerns. In the few cases where this specification requires
830 reporting of errors to the user, it is acceptable for such reporting
831 to only be observable in an error console or log file. Likewise,
832 requirements that an automated action be confirmed by the user before
833 proceeding might be met via advance configuration choices, run-time
834 options, or simple avoidance of the unsafe action; confirmation does
835 not imply any specific user interface or interruption of normal
836 processing if the user has already made that choice.
840 The term "origin server" refers to a program that can originate
841 authoritative responses for a given target resource.
843 The most familiar form of origin server are large public websites.
844 However, like user agents being equated with browsers, it is easy to
845 be misled into thinking that all origin servers are alike. Common
846 origin servers also include home automation units, configurable
847 networking components, office machines, autonomous robots, news
848 feeds, traffic cameras, real-time ad selectors, and video-on-demand
851 Most HTTP communication consists of a retrieval request (GET) for a
852 representation of some resource identified by a URI. In the simplest
853 case, this might be accomplished via a single bidirectional
854 connection (===) between the user agent (UA) and the origin server
858 UA ======================================= O
865 HTTP enables the use of intermediaries to satisfy requests through a
866 chain of connections. There are three common forms of HTTP
867 "intermediary": proxy, gateway, and tunnel. In some cases, a single
868 intermediary might act as an origin server, proxy, gateway, or
869 tunnel, switching behavior based on the nature of each request.
872 UA =========== A =========== B =========== C =========== O
877 The figure above shows three intermediaries (A, B, and C) between the
878 user agent and origin server. A request or response message that
879 travels the whole chain will pass through four separate connections.
880 Some HTTP communication options might apply only to the connection
881 with the nearest, non-tunnel neighbor, only to the endpoints of the
882 chain, or to all connections along the chain. Although the diagram
883 is linear, each participant might be engaged in multiple,
884 simultaneous communications. For example, B might be receiving
885 requests from many clients other than A, and/or forwarding requests
886 to servers other than C, at the same time that it is handling A's
887 request. Likewise, later requests might be sent through a different
888 path of connections, often based on dynamic configuration for load
891 The terms "upstream" and "downstream" are used to describe
892 directional requirements in relation to the message flow: all
893 messages flow from upstream to downstream. The terms "inbound" and
894 "outbound" are used to describe directional requirements in relation
895 to the request route: inbound means "toward the origin server",
896 whereas outbound means "toward the user agent".
898 A "proxy" is a message-forwarding agent that is chosen by the client,
899 usually via local configuration rules, to receive requests for some
900 type(s) of absolute URI and attempt to satisfy those requests via
901 translation through the HTTP interface. Some translations are
902 minimal, such as for proxy requests for "http" URIs, whereas other
903 requests might require translation to and from entirely different
904 application-level protocols. Proxies are often used to group an
905 organization's HTTP requests through a common intermediary for the
906 sake of security services, annotation services, or shared caching.
907 Some proxies are designed to apply transformations to selected
908 messages or content while they are being forwarded, as described in
911 A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
912 an origin server for the outbound connection but translates received
913 requests and forwards them inbound to another server or servers.
914 Gateways are often used to encapsulate legacy or untrusted
915 information services, to improve server performance through
916 "accelerator" caching, and to enable partitioning or load balancing
917 of HTTP services across multiple machines.
919 All HTTP requirements applicable to an origin server also apply to
920 the outbound communication of a gateway. A gateway communicates with
921 inbound servers using any protocol that it desires, including private
922 extensions to HTTP that are outside the scope of this specification.
923 However, an HTTP-to-HTTP gateway that wishes to interoperate with
924 third-party HTTP servers needs to conform to user agent requirements
925 on the gateway's inbound connection.
927 A "tunnel" acts as a blind relay between two connections without
928 changing the messages. Once active, a tunnel is not considered a
929 party to the HTTP communication, though the tunnel might have been
930 initiated by an HTTP request. A tunnel ceases to exist when both
931 ends of the relayed connection are closed. Tunnels are used to
932 extend a virtual connection through an intermediary, such as when
933 Transport Layer Security (TLS, [TLS13]) is used to establish
934 confidential communication through a shared firewall proxy.
936 The above categories for intermediary only consider those acting as
937 participants in the HTTP communication. There are also
938 intermediaries that can act on lower layers of the network protocol
939 stack, filtering or redirecting HTTP traffic without the knowledge or
940 permission of message senders. Network intermediaries are
941 indistinguishable (at a protocol level) from an on-path attacker,
942 often introducing security flaws or interoperability problems due to
943 mistakenly violating HTTP semantics.
945 For example, an "interception proxy" [RFC3040] (also commonly known
946 as a "transparent proxy" [RFC1919]) differs from an HTTP proxy
947 because it is not chosen by the client. Instead, an interception
948 proxy filters or redirects outgoing TCP port 80 packets (and
949 occasionally other common port traffic). Interception proxies are
950 commonly found on public network access points, as a means of
951 enforcing account subscription prior to allowing use of non-local
952 Internet services, and within corporate firewalls to enforce network
957 A "cache" is a local store of previous response messages and the
958 subsystem that controls its message storage, retrieval, and deletion.
959 A cache stores cacheable responses in order to reduce the response
960 time and network bandwidth consumption on future, equivalent
961 requests. Any client or server MAY employ a cache, though a cache
962 cannot be used while acting as a tunnel.
964 The effect of a cache is that the request/response chain is shortened
965 if one of the participants along the chain has a cached response
966 applicable to that request. The following illustrates the resulting
967 chain if B has a cached copy of an earlier response from O (via C)
968 for a request that has not been cached by UA or A.
971 UA =========== A =========== B - - - - - - C - - - - - - O
976 A response is "cacheable" if a cache is allowed to store a copy of
977 the response message for use in answering subsequent requests. Even
978 when a response is cacheable, there might be additional constraints
979 placed by the client or by the origin server on when that cached
980 response can be used for a particular request. HTTP requirements for
981 cache behavior and cacheable responses are defined in [CACHING].
983 There is a wide variety of architectures and configurations of caches
984 deployed across the World Wide Web and inside large organizations.
985 These include national hierarchies of proxy caches to save bandwidth
986 and reduce latency, content delivery networks that use gateway
987 caching to optimize regional and global distribution of popular
988 sites, collaborative systems that broadcast or multicast cache
989 entries, archives of pre-fetched cache entries for use in off-line or
990 high-latency environments, and so on.
9923.9. Example Message Exchange
994 The following example illustrates a typical HTTP/1.1 message exchange
995 for a GET request (Section 9.3.1) on the URI "http://www.example.com/
1000 GET /hello.txt HTTP/1.1
1001 User-Agent: curl/7.64.1
1002 Host: www.example.com
1003 Accept-Language: en, mi
1008 Date: Mon, 27 Jul 2009 12:28:53 GMT
1010 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
1011 ETag: "34aa387-d-1568eb00"
1012 Accept-Ranges: bytes
1014 Vary: Accept-Encoding
1015 Content-Type: text/plain
1017 Hello World! My content includes a trailing CRLF.
10194. Identifiers in HTTP
1021 Uniform Resource Identifiers (URIs) [URI] are used throughout HTTP as
1022 the means for identifying resources (Section 3.1).
1026 URI references are used to target requests, indicate redirects, and
1027 define relationships.
1029 The definitions of "URI-reference", "absolute-URI", "relative-part",
1030 "authority", "port", "host", "path-abempty", "segment", and "query"
1031 are adopted from the URI generic syntax. An "absolute-path" rule is
1032 defined for protocol elements that can contain a non-empty path
1033 component. (This rule differs slightly from the path-abempty rule of
1034 RFC 3986, which allows for an empty path, and path-absolute rule,
1035 which does not allow paths that begin with "//".) A "partial-URI"
1036 rule is defined for protocol elements that can contain a relative URI
1037 but not a fragment component.
1039 URI-reference = <URI-reference, see [URI], Section 4.1>
1040 absolute-URI = <absolute-URI, see [URI], Section 4.3>
1041 relative-part = <relative-part, see [URI], Section 4.2>
1042 authority = <authority, see [URI], Section 3.2>
1043 uri-host = <host, see [URI], Section 3.2.2>
1044 port = <port, see [URI], Section 3.2.3>
1045 path-abempty = <path-abempty, see [URI], Section 3.3>
1046 segment = <segment, see [URI], Section 3.3>
1047 query = <query, see [URI], Section 3.4>
1049 absolute-path = 1*( "/" segment )
1050 partial-URI = relative-part [ "?" query ]
1052 Each protocol element in HTTP that allows a URI reference will
1053 indicate in its ABNF production whether the element allows any form
1054 of reference (URI-reference), only a URI in absolute form (absolute-
1055 URI), only the path and optional query components (partial-URI), or
1056 some combination of the above. Unless otherwise indicated, URI
1057 references are parsed relative to the target URI (Section 7.1).
1059 It is RECOMMENDED that all senders and recipients support, at a
1060 minimum, URIs with lengths of 8000 octets in protocol elements. Note
1061 that this implies some structures and on-wire representations (for
1062 example, the request line in HTTP/1.1) will necessarily be larger in
10654.2. HTTP-Related URI Schemes
1067 IANA maintains the registry of URI Schemes [BCP35] at
1068 <https://www.iana.org/assignments/uri-schemes/>. Although requests
1069 might target any URI scheme, the following schemes are inherent to
1072 +============+====================================+=========+
1073 | URI Scheme | Description | Section |
1074 +============+====================================+=========+
1075 | http | Hypertext Transfer Protocol | 4.2.1 |
1076 +------------+------------------------------------+---------+
1077 | https | Hypertext Transfer Protocol Secure | 4.2.2 |
1078 +------------+------------------------------------+---------+
1082 Note that the presence of an "http" or "https" URI does not imply
1083 that there is always an HTTP server at the identified origin
1084 listening for connections. Anyone can mint a URI, whether or not a
1085 server exists and whether or not that server currently maps that
1086 identifier to a resource. The delegated nature of registered names
1087 and IP addresses creates a federated namespace whether or not an HTTP
10904.2.1. http URI Scheme
1092 The "http" URI scheme is hereby defined for minting identifiers
1093 within the hierarchical namespace governed by a potential HTTP origin
1094 server listening for TCP ([TCP]) connections on a given port.
1096 http-URI = "http" "://" authority path-abempty [ "?" query ]
1098 The origin server for an "http" URI is identified by the authority
1099 component, which includes a host identifier ([URI], Section 3.2.2)
1100 and optional port number ([URI], Section 3.2.3). If the port
1101 subcomponent is empty or not given, TCP port 80 (the reserved port
1102 for WWW services) is the default. The origin determines who has the
1103 right to respond authoritatively to requests that target the
1104 identified resource, as defined in Section 4.3.2.
1106 A sender MUST NOT generate an "http" URI with an empty host
1107 identifier. A recipient that processes such a URI reference MUST
1108 reject it as invalid.
1110 The hierarchical path component and optional query component identify
1111 the target resource within that origin server's namespace.
11134.2.2. https URI Scheme
1115 The "https" URI scheme is hereby defined for minting identifiers
1116 within the hierarchical namespace governed by a potential origin
1117 server listening for TCP connections on a given port and capable of
1118 establishing a TLS ([TLS13]) connection that has been secured for
1119 HTTP communication. In this context, "secured" specifically means
1120 that the server has been authenticated as acting on behalf of the
1121 identified authority and all HTTP communication with that server has
1122 confidentiality and integrity protection that is acceptable to both
1125 https-URI = "https" "://" authority path-abempty [ "?" query ]
1127 The origin server for an "https" URI is identified by the authority
1128 component, which includes a host identifier ([URI], Section 3.2.2)
1129 and optional port number ([URI], Section 3.2.3). If the port
1130 subcomponent is empty or not given, TCP port 443 (the reserved port
1131 for HTTP over TLS) is the default. The origin determines who has the
1132 right to respond authoritatively to requests that target the
1133 identified resource, as defined in Section 4.3.3.
1135 A sender MUST NOT generate an "https" URI with an empty host
1136 identifier. A recipient that processes such a URI reference MUST
1137 reject it as invalid.
1139 The hierarchical path component and optional query component identify
1140 the target resource within that origin server's namespace.
1142 A client MUST ensure that its HTTP requests for an "https" resource
1143 are secured, prior to being communicated, and that it only accepts
1144 secured responses to those requests. Note that the definition of
1145 what cryptographic mechanisms are acceptable to client and server are
1146 usually negotiated and can change over time.
1148 Resources made available via the "https" scheme have no shared
1149 identity with the "http" scheme. They are distinct origins with
1150 separate namespaces. However, extensions to HTTP that are defined as
1151 applying to all origins with the same host, such as the Cookie
1152 protocol [COOKIE], allow information set by one service to impact
1153 communication with other services within a matching group of host
1154 domains. Such extensions ought to be designed with great care to
1155 prevent information obtained from a secured connection being
1156 inadvertently exchanged within an unsecured context.
11584.2.3. http(s) Normalization and Comparison
1160 URIs with an "http" or "https" scheme are normalized and compared
1161 according to the methods defined in Section 6 of [URI], using the
1162 defaults described above for each scheme.
1164 HTTP does not require the use of a specific method for determining
1165 equivalence. For example, a cache key might be compared as a simple
1166 string, after syntax-based normalization, or after scheme-based
1169 Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and
1170 "https" URIs involves the following additional rules:
1172 * If the port is equal to the default port for a scheme, the normal
1173 form is to omit the port subcomponent.
1175 * When not being used as the target of an OPTIONS request, an empty
1176 path component is equivalent to an absolute path of "/", so the
1177 normal form is to provide a path of "/" instead.
1179 * The scheme and host are case-insensitive and normally provided in
1180 lowercase; all other components are compared in a case-sensitive
1183 * Characters other than those in the "reserved" set are equivalent
1184 to their percent-encoded octets: the normal form is to not encode
1185 them (see Sections 2.1 and 2.2 of [URI]).
1187 For example, the following three URIs are equivalent:
1189 http://example.com:80/~smith/home.html
1190 http://EXAMPLE.com/%7Esmith/home.html
1191 http://EXAMPLE.com:/%7esmith/home.html
1193 Two HTTP URIs that are equivalent after normalization (using any
1194 method) can be assumed to identify the same resource, and any HTTP
1195 component MAY perform normalization. As a result, distinct resources
1196 SHOULD NOT be identified by HTTP URIs that are equivalent after
1197 normalization (using any method defined in Section 6.2 of [URI]).
11994.2.4. Deprecation of userinfo in http(s) URIs
1201 The URI generic syntax for authority also includes a userinfo
1202 subcomponent ([URI], Section 3.2.1) for including user authentication
1203 information in the URI. In that subcomponent, the use of the format
1204 "user:password" is deprecated.
1206 Some implementations make use of the userinfo component for internal
1207 configuration of authentication information, such as within command
1208 invocation options, configuration files, or bookmark lists, even
1209 though such usage might expose a user identifier or password.
1211 A sender MUST NOT generate the userinfo subcomponent (and its "@"
1212 delimiter) when an "http" or "https" URI reference is generated
1213 within a message as a target URI or field value.
1215 Before making use of an "http" or "https" URI reference received from
1216 an untrusted source, a recipient SHOULD parse for userinfo and treat
1217 its presence as an error; it is likely being used to obscure the
1218 authority for the sake of phishing attacks.
12204.2.5. http(s) References with Fragment Identifiers
1222 Fragment identifiers allow for indirect identification of a secondary
1223 resource, independent of the URI scheme, as defined in Section 3.5 of
1224 [URI]. Some protocol elements that refer to a URI allow inclusion of
1225 a fragment, while others do not. They are distinguished by use of
1226 the ABNF rule for elements where fragment is allowed; otherwise, a
1227 specific rule that excludes fragments is used.
1229 | *Note:* The fragment identifier component is not part of the
1230 | scheme definition for a URI scheme (see Section 4.3 of [URI]),
1231 | thus does not appear in the ABNF definitions for the "http" and
1232 | "https" URI schemes above.
12344.3. Authoritative Access
1236 Authoritative access refers to dereferencing a given identifier, for
1237 the sake of access to the identified resource, in a way that the
1238 client believes is authoritative (controlled by the resource owner).
1239 The process for determining whether access is granted is defined by
1240 the URI scheme and often uses data within the URI components, such as
1241 the authority component when the generic syntax is used. However,
1242 authoritative access is not limited to the identified mechanism.
1244 Section 4.3.1 defines the concept of an origin as an aid to such
1245 uses, and the subsequent subsections explain how to establish that a
1246 peer has the authority to represent an origin.
1248 See Section 17.1 for security considerations related to establishing
1253 The "origin" for a given URI is the triple of scheme, host, and port
1254 after normalizing the scheme and host to lowercase and normalizing
1255 the port to remove any leading zeros. If port is elided from the
1256 URI, the default port for that scheme is used. For example, the URI
1258 https://Example.Com/happy.js
1260 would have the origin
1262 { "https", "example.com", "443" }
1264 which can also be described as the normalized URI prefix with port
1267 https://example.com:443
1269 Each origin defines its own namespace and controls how identifiers
1270 within that namespace are mapped to resources. In turn, how the
1271 origin responds to valid requests, consistently over time, determines
1272 the semantics that users will associate with a URI, and the
1273 usefulness of those semantics is what ultimately transforms these
1274 mechanisms into a resource for users to reference and access in the
1277 Two origins are distinct if they differ in scheme, host, or port.
1278 Even when it can be verified that the same entity controls two
1279 distinct origins, the two namespaces under those origins are distinct
1280 unless explicitly aliased by a server authoritative for that origin.
1282 Origin is also used within HTML and related Web protocols, beyond the
1283 scope of this document, as described in [RFC6454].
1287 Although HTTP is independent of the transport protocol, the "http"
1288 scheme (Section 4.2.1) is specific to associating authority with
1289 whomever controls the origin server listening for TCP connections on
1290 the indicated port of whatever host is identified within the
1291 authority component. This is a very weak sense of authority because
1292 it depends on both client-specific name resolution mechanisms and
1293 communication that might not be secured from an on-path attacker.
1294 Nevertheless, it is a sufficient minimum for binding "http"
1295 identifiers to an origin server for consistent resolution within a
1296 trusted environment.
1298 If the host identifier is provided as an IP address, the origin
1299 server is the listener (if any) on the indicated TCP port at that IP
1300 address. If host is a registered name, the registered name is an
1301 indirect identifier for use with a name resolution service, such as
1302 DNS, to find an address for an appropriate origin server.
1304 When an "http" URI is used within a context that calls for access to
1305 the indicated resource, a client MAY attempt access by resolving the
1306 host identifier to an IP address, establishing a TCP connection to
1307 that address on the indicated port, and sending over that connection
1308 an HTTP request message containing a request target that matches the
1309 client's target URI (Section 7.1).
1311 If the server responds to such a request with a non-interim HTTP
1312 response message, as described in Section 15, then that response is
1313 considered an authoritative answer to the client's request.
1315 Note, however, that the above is not the only means for obtaining an
1316 authoritative response, nor does it imply that an authoritative
1317 response is always necessary (see [CACHING]). For example, the Alt-
1318 Svc header field [ALTSVC] allows an origin server to identify other
1319 services that are also authoritative for that origin. Access to
1320 "http" identified resources might also be provided by protocols
1321 outside the scope of this document.
1325 The "https" scheme (Section 4.2.2) associates authority based on the
1326 ability of a server to use the private key corresponding to a
1327 certificate that the client considers to be trustworthy for the
1328 identified origin server. The client usually relies upon a chain of
1329 trust, conveyed from some prearranged or configured trust anchor, to
1330 deem a certificate trustworthy (Section 4.3.4).
1332 In HTTP/1.1 and earlier, a client will only attribute authority to a
1333 server when they are communicating over a successfully established
1334 and secured connection specifically to that URI origin's host. The
1335 connection establishment and certificate verification are used as
1338 In HTTP/2 and HTTP/3, a client will attribute authority to a server
1339 when they are communicating over a successfully established and
1340 secured connection if the URI origin's host matches any of the hosts
1341 present in the server's certificate and the client believes that it
1342 could open a connection to that host for that URI. In practice, a
1343 client will make a DNS query to check that the origin's host contains
1344 the same server IP address as the established connection. This
1345 restriction can be removed by the origin server sending an equivalent
1346 ORIGIN frame [RFC8336].
1348 The request target's host and port value are passed within each HTTP
1349 request, identifying the origin and distinguishing it from other
1350 namespaces that might be controlled by the same server (Section 7.2).
1351 It is the origin's responsibility to ensure that any services
1352 provided with control over its certificate's private key are equally
1353 responsible for managing the corresponding "https" namespaces or at
1354 least prepared to reject requests that appear to have been
1355 misdirected (Section 7.4).
1357 An origin server might be unwilling to process requests for certain
1358 target URIs even when they have the authority to do so. For example,
1359 when a host operates distinct services on different ports (e.g., 443
1360 and 8000), checking the target URI at the origin server is necessary
1361 (even after the connection has been secured) because a network
1362 attacker might cause connections for one port to be received at some
1363 other port. Failing to check the target URI might allow such an
1364 attacker to replace a response to one target URI (e.g.,
1365 "https://example.com/foo") with a seemingly authoritative response
1366 from the other port (e.g., "https://example.com:8000/foo").
1368 Note that the "https" scheme does not rely on TCP and the connected
1369 port number for associating authority, since both are outside the
1370 secured communication and thus cannot be trusted as definitive.
1371 Hence, the HTTP communication might take place over any channel that
1372 has been secured, as defined in Section 4.2.2, including protocols
1375 When an "https" URI is used within a context that calls for access to
1376 the indicated resource, a client MAY attempt access by resolving the
1377 host identifier to an IP address, establishing a TCP connection to
1378 that address on the indicated port, securing the connection end-to-
1379 end by successfully initiating TLS over TCP with confidentiality and
1380 integrity protection, and sending over that connection an HTTP
1381 request message containing a request target that matches the client's
1382 target URI (Section 7.1).
1384 If the server responds to such a request with a non-interim HTTP
1385 response message, as described in Section 15, then that response is
1386 considered an authoritative answer to the client's request.
1388 Note, however, that the above is not the only means for obtaining an
1389 authoritative response, nor does it imply that an authoritative
1390 response is always necessary (see [CACHING]).
13924.3.4. https Certificate Verification
1394 To establish a secured connection to dereference a URI, a client MUST
1395 verify that the service's identity is an acceptable match for the
1396 URI's origin server. Certificate verification is used to prevent
1397 server impersonation by an on-path attacker or by an attacker that
1398 controls name resolution. This process requires that a client be
1399 configured with a set of trust anchors.
1401 In general, a client MUST verify the service identity using the
1402 verification process defined in Section 6 of [RFC6125]. The client
1403 MUST construct a reference identity from the service's host: if the
1404 host is a literal IP address (Section 4.3.5), the reference identity
1405 is an IP-ID, otherwise the host is a name and the reference identity
1408 A reference identity of type CN-ID MUST NOT be used by clients. As
1409 noted in Section 6.2.1 of [RFC6125], a reference identity of type CN-
1410 ID might be used by older clients.
1412 A client might be specially configured to accept an alternative form
1413 of server identity verification. For example, a client might be
1414 connecting to a server whose address and hostname are dynamic, with
1415 an expectation that the service will present a specific certificate
1416 (or a certificate matching some externally defined reference
1417 identity) rather than one matching the target URI's origin.
1419 In special cases, it might be appropriate for a client to simply
1420 ignore the server's identity, but it must be understood that this
1421 leaves a connection open to active attack.
1423 If the certificate is not valid for the target URI's origin, a user
1424 agent MUST either obtain confirmation from the user before proceeding
1425 (see Section 3.5) or terminate the connection with a bad certificate
1426 error. Automated clients MUST log the error to an appropriate audit
1427 log (if available) and SHOULD terminate the connection (with a bad
1428 certificate error). Automated clients MAY provide a configuration
1429 setting that disables this check, but MUST provide a setting which
14324.3.5. IP-ID Reference Identity
1434 A server that is identified using an IP address literal in the "host"
1435 field of an "https" URI has a reference identity of type IP-ID. An
1436 IP version 4 address uses the "IPv4address" ABNF rule, and an IP
1437 version 6 address uses the "IP-literal" production with the
1438 "IPv6address" option; see Section 3.2.2 of [URI]. A reference
1439 identity of IP-ID contains the decoded bytes of the IP address.
1441 An IP version 4 address is 4 octets, and an IP version 6 address is
1442 16 octets. Use of IP-ID is not defined for any other IP version.
1443 The iPAddress choice in the certificate subjectAltName extension does
1444 not explicitly include the IP version and so relies on the length of
1445 the address to distinguish versions; see Section 4.2.1.6 of
1448 A reference identity of type IP-ID matches if the address is
1449 identical to an iPAddress value of the subjectAltName extension of
1454 HTTP uses "fields" to provide data in the form of extensible name/
1455 value pairs with a registered key namespace. Fields are sent and
1456 received within the header and trailer sections of messages
1461 A field name labels the corresponding field value as having the
1462 semantics defined by that name. For example, the Date header field
1463 is defined in Section 6.6.1 as containing the origination timestamp
1464 for the message in which it appears.
1468 Field names are case-insensitive and ought to be registered within
1469 the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see
1472 The interpretation of a field does not change between minor versions
1473 of the same major HTTP version, though the default behavior of a
1474 recipient in the absence of such a field can change. Unless
1475 specified otherwise, fields are defined for all versions of HTTP. In
1476 particular, the Host and Connection fields ought to be recognized by
1477 all HTTP implementations whether or not they advertise conformance
1480 New fields can be introduced without changing the protocol version if
1481 their defined semantics allow them to be safely ignored by recipients
1482 that do not recognize them; see Section 16.3.
1484 A proxy MUST forward unrecognized header fields unless the field name
1485 is listed in the Connection header field (Section 7.6.1) or the proxy
1486 is specifically configured to block, or otherwise transform, such
1487 fields. Other recipients SHOULD ignore unrecognized header and
1488 trailer fields. Adhering to these requirements allows HTTP's
1489 functionality to be extended without updating or removing deployed
14925.2. Field Lines and Combined Field Value
1494 Field sections are composed of any number of "field lines", each with
1495 a "field name" (see Section 5.1) identifying the field, and a "field
1496 line value" that conveys data for that instance of the field.
1498 When a field name is only present once in a section, the combined
1499 "field value" for that field consists of the corresponding field line
1500 value. When a field name is repeated within a section, its combined
1501 field value consists of the list of corresponding field line values
1502 within that section, concatenated in order, with each field line
1503 value separated by a comma.
1505 For example, this section:
1507 Example-Field: Foo, Bar
1510 contains two field lines, both with the field name "Example-Field".
1511 The first field line has a field line value of "Foo, Bar", while the
1512 second field line value is "Baz". The field value for "Example-
1513 Field" is the list "Foo, Bar, Baz".
1517 A recipient MAY combine multiple field lines within a field section
1518 that have the same field name into one field line, without changing
1519 the semantics of the message, by appending each subsequent field line
1520 value to the initial field line value in order, separated by a comma
1521 (",") and optional whitespace (OWS, defined in Section 5.6.3). For
1522 consistency, use comma SP.
1524 The order in which field lines with the same name are received is
1525 therefore significant to the interpretation of the field value; a
1526 proxy MUST NOT change the order of these field line values when
1527 forwarding a message.
1529 This means that, aside from the well-known exception noted below, a
1530 sender MUST NOT generate multiple field lines with the same name in a
1531 message (whether in the headers or trailers) or append a field line
1532 when a field line of the same name already exists in the message,
1533 unless that field's definition allows multiple field line values to
1534 be recombined as a comma-separated list (i.e., at least one
1535 alternative of the field's definition allows a comma-separated list,
1536 such as an ABNF rule of #(values) defined in Section 5.6.1).
1538 | *Note:* In practice, the "Set-Cookie" header field ([COOKIE])
1539 | often appears in a response message across multiple field lines
1540 | and does not use the list syntax, violating the above
1541 | requirements on multiple field lines with the same field name.
1542 | Since it cannot be combined into a single field value,
1543 | recipients ought to handle "Set-Cookie" as a special case while
1544 | processing fields. (See Appendix A.2.3 of [Kri2001] for
1547 The order in which field lines with differing field names are
1548 received in a section is not significant. However, it is good
1549 practice to send header fields that contain additional control data
1550 first, such as Host on requests and Date on responses, so that
1551 implementations can decide when not to handle a message as early as
1554 A server MUST NOT apply a request to the target resource until it
1555 receives the entire request header section, since later header field
1556 lines might include conditionals, authentication credentials, or
1557 deliberately misleading duplicate header fields that could impact
1562 HTTP does not place a predefined limit on the length of each field
1563 line, field value, or on the length of a header or trailer section as
1564 a whole, as described in Section 2. Various ad hoc limitations on
1565 individual lengths are found in practice, often depending on the
1566 specific field's semantics.
1568 A server that receives a request header field line, field value, or
1569 set of fields larger than it wishes to process MUST respond with an
1570 appropriate 4xx (Client Error) status code. Ignoring such header
1571 fields would increase the server's vulnerability to request smuggling
1572 attacks (Section 11.2 of [HTTP/1.1]).
1574 A client MAY discard or truncate received field lines that are larger
1575 than the client wishes to process if the field semantics are such
1576 that the dropped value(s) can be safely ignored without changing the
1577 message framing or response semantics.
1581 HTTP field values consist of a sequence of characters in a format
1582 defined by the field's grammar. Each field's grammar is usually
1583 defined using ABNF ([RFC5234]).
1585 field-value = *field-content
1586 field-content = field-vchar
1587 [ 1*( SP / HTAB / field-vchar ) field-vchar ]
1588 field-vchar = VCHAR / obs-text
1591 A field value does not include leading or trailing whitespace. When
1592 a specific version of HTTP allows such whitespace to appear in a
1593 message, a field parsing implementation MUST exclude such whitespace
1594 prior to evaluating the field value.
1596 Field values are usually constrained to the range of US-ASCII
1597 characters [USASCII]. Fields needing a greater range of characters
1598 can use an encoding, such as the one defined in [RFC8187].
1599 Historically, HTTP allowed field content with text in the ISO-8859-1
1600 charset [ISO-8859-1], supporting other charsets only through use of
1601 [RFC2047] encoding. Specifications for newly defined fields SHOULD
1602 limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB.
1603 A recipient SHOULD treat other allowed octets in field content (i.e.,
1604 obs-text) as opaque data.
1606 Field values containing CR, LF, or NUL characters are invalid and
1607 dangerous, due to the varying ways that implementations might parse
1608 and interpret those characters; a recipient of CR, LF, or NUL within
1609 a field value MUST either reject the message or replace each of those
1610 characters with SP before further processing or forwarding of that
1611 message. Field values containing other CTL characters are also
1612 invalid; however, recipients MAY retain such characters for the sake
1613 of robustness when they appear within a safe context (e.g., an
1614 application-specific quoted string that will not be processed by any
1615 downstream HTTP parser).
1617 Fields that only anticipate a single member as the field value are
1618 referred to as "singleton fields".
1620 Fields that allow multiple members as the field value are referred to
1621 as "list-based fields". The list operator extension of Section 5.6.1
1622 is used as a common notation for defining field values that can
1623 contain multiple members.
1625 Because commas (",") are used as the delimiter between members, they
1626 need to be treated with care if they are allowed as data within a
1627 member. This is true for both list-based and singleton fields, since
1628 a singleton field might be erroneously sent with multiple members and
1629 detecting such errors improves interoperability. Fields that expect
1630 to contain a comma within a member, such as within an HTTP-date or
1631 URI-reference element, ought to be defined with delimiters around
1632 that element to distinguish any comma within that data from potential
1635 For example, a textual date and a URI (either of which might contain
1636 a comma) could be safely carried in list-based field values like
1639 Example-URIs: "http://example.com/a.html,foo",
1640 "http://without-a-comma.example.com/"
1641 Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
1643 Note that double-quote delimiters are almost always used with the
1644 quoted-string production (Section 5.6.4); using a different syntax
1645 inside double-quotes will likely cause unnecessary confusion.
1647 Many fields (such as Content-Type, defined in Section 8.3) use a
1648 common syntax for parameters that allows both unquoted (token) and
1649 quoted (quoted-string) syntax for a parameter value (Section 5.6.6).
1650 Use of common syntax allows recipients to reuse existing parser
1651 components. When allowing both forms, the meaning of a parameter
1652 value ought to be the same whether it was received as a token or a
1655 | *Note:* For defining field value syntax, this specification
1656 | uses an ABNF rule named after the field name to define the
1657 | allowed grammar for that field's value (after said value has
1658 | been extracted from the underlying messaging syntax and
1659 | multiple instances combined into a list).
16615.6. Common Rules for Defining Field Values
16635.6.1. Lists (#rule ABNF Extension)
1665 A #rule extension to the ABNF rules of [RFC5234] is used to improve
1666 readability in the definitions of some list-based field values.
1668 A construct "#" is defined, similar to "*", for defining comma-
1669 delimited lists of elements. The full form is "<n>#<m>element"
1670 indicating at least <n> and at most <m> elements, each separated by a
1671 single comma (",") and optional whitespace (OWS, defined in
16745.6.1.1. Sender Requirements
1676 In any production that uses the list construct, a sender MUST NOT
1677 generate empty list elements. In other words, a sender has to
1678 generate lists that satisfy the following syntax:
1680 1#element => element *( OWS "," OWS element )
1684 #element => [ 1#element ]
1686 and for n >= 1 and m > 1:
1688 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
1690 Appendix A shows the collected ABNF for senders after the list
1691 constructs have been expanded.
16935.6.1.2. Recipient Requirements
1695 Empty elements do not contribute to the count of elements present. A
1696 recipient MUST parse and ignore a reasonable number of empty list
1697 elements: enough to handle common mistakes by senders that merge
1698 values, but not so much that they could be used as a denial-of-
1699 service mechanism. In other words, a recipient MUST accept lists
1700 that satisfy the following syntax:
1702 #element => [ element ] *( OWS "," OWS [ element ] )
1704 Note that because of the potential presence of empty list elements,
1705 the RFC 5234 ABNF cannot enforce the cardinality of list elements,
1706 and consequently all cases are mapped as if there was no cardinality
1709 For example, given these ABNF productions:
1711 example-list = 1#example-list-elmt
1712 example-list-elmt = token ; see Section 5.6.2
1714 Then the following are valid values for example-list (not including
1715 the double quotes, which are present for delimitation only):
1719 "foo , ,bar,charlie"
1721 In contrast, the following values would be invalid, since at least
1722 one non-empty element is required by the example-list production:
1730 Tokens are short textual identifiers that do not include whitespace
1735 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
1736 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
1738 ; any VCHAR, except delimiters
1740 Many HTTP field values are defined using common syntax components,
1741 separated by whitespace or specific delimiting characters.
1742 Delimiters are chosen from the set of US-ASCII visual characters not
1743 allowed in a token (DQUOTE and "(),/:;<=>?@[\]{}").
1747 This specification uses three rules to denote the use of linear
1748 whitespace: OWS (optional whitespace), RWS (required whitespace), and
1749 BWS ("bad" whitespace).
1751 The OWS rule is used where zero or more linear whitespace octets
1752 might appear. For protocol elements where optional whitespace is
1753 preferred to improve readability, a sender SHOULD generate the
1754 optional whitespace as a single SP; otherwise, a sender SHOULD NOT
1755 generate optional whitespace except as needed to overwrite invalid or
1756 unwanted protocol elements during in-place message filtering.
1758 The RWS rule is used when at least one linear whitespace octet is
1759 required to separate field tokens. A sender SHOULD generate RWS as a
1762 OWS and RWS have the same semantics as a single SP. Any content
1763 known to be defined as OWS or RWS MAY be replaced with a single SP
1764 before interpreting it or forwarding the message downstream.
1766 The BWS rule is used where the grammar allows optional whitespace
1767 only for historical reasons. A sender MUST NOT generate BWS in
1768 messages. A recipient MUST parse for such bad whitespace and remove
1769 it before interpreting the protocol element.
1771 BWS has no semantics. Any content known to be defined as BWS MAY be
1772 removed before interpreting it or forwarding the message downstream.
1774 OWS = *( SP / HTAB )
1775 ; optional whitespace
1776 RWS = 1*( SP / HTAB )
1777 ; required whitespace
17815.6.4. Quoted Strings
1783 A string of text is parsed as a single value if it is quoted using
1786 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1787 qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
1789 The backslash octet ("\") can be used as a single-octet quoting
1790 mechanism within quoted-string and comment constructs. Recipients
1791 that process the value of a quoted-string MUST handle a quoted-pair
1792 as if it were replaced by the octet following the backslash.
1794 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1796 A sender SHOULD NOT generate a quoted-pair in a quoted-string except
1797 where necessary to quote DQUOTE and backslash octets occurring within
1798 that string. A sender SHOULD NOT generate a quoted-pair in a comment
1799 except where necessary to quote parentheses ["(" and ")"] and
1800 backslash octets occurring within that comment.
1804 Comments can be included in some HTTP fields by surrounding the
1805 comment text with parentheses. Comments are only allowed in fields
1806 containing "comment" as part of their field value definition.
1808 comment = "(" *( ctext / quoted-pair / comment ) ")"
1809 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
1813 Parameters are instances of name/value pairs; they are often used in
1814 field values as a common syntax for appending auxiliary information
1815 to an item. Each parameter is usually delimited by an immediately
1816 preceding semicolon.
1818 parameters = *( OWS ";" OWS [ parameter ] )
1819 parameter = parameter-name "=" parameter-value
1820 parameter-name = token
1821 parameter-value = ( token / quoted-string )
1823 Parameter names are case-insensitive. Parameter values might or
1824 might not be case-sensitive, depending on the semantics of the
1825 parameter name. Examples of parameters and some equivalent forms can
1826 be seen in media types (Section 8.3.1) and the Accept header field
1829 A parameter value that matches the token production can be
1830 transmitted either as a token or within a quoted-string. The quoted
1831 and unquoted values are equivalent.
1833 | *Note:* Parameters do not allow whitespace (not even "bad"
1834 | whitespace) around the "=" character.
18365.6.7. Date/Time Formats
1838 Prior to 1995, there were three different formats commonly used by
1839 servers to communicate timestamps. For compatibility with old
1840 implementations, all three are defined here. The preferred format is
1841 a fixed-length and single-zone subset of the date and time
1842 specification used by the Internet Message Format [RFC5322].
1844 HTTP-date = IMF-fixdate / obs-date
1846 An example of the preferred format is
1848 Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
1850 Examples of the two obsolete formats are
1852 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1853 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1855 A recipient that parses a timestamp value in an HTTP field MUST
1856 accept all three HTTP-date formats. When a sender generates a field
1857 that contains one or more timestamps defined as HTTP-date, the sender
1858 MUST generate those timestamps in the IMF-fixdate format.
1860 An HTTP-date value represents time as an instance of Coordinated
1861 Universal Time (UTC). The first two formats indicate UTC by the
1862 three-letter abbreviation for Greenwich Mean Time, "GMT", a
1863 predecessor of the UTC name; values in the asctime format are assumed
1866 A "clock" is an implementation capable of providing a reasonable
1867 approximation of the current instant in UTC. A clock implementation
1868 ought to use NTP ([RFC5905]), or some similar protocol, to
1869 synchronize with UTC.
1873 IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
1874 ; fixed length/zone/capitalization subset of the format
1875 ; see Section 3.3 of [RFC5322]
1877 day-name = %s"Mon" / %s"Tue" / %s"Wed"
1878 / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
1880 date1 = day SP month SP year
1884 month = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
1885 / %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
1886 / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
1891 time-of-day = hour ":" minute ":" second
1892 ; 00:00:00 - 23:59:60 (leap second)
1900 obs-date = rfc850-date / asctime-date
1902 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
1903 date2 = day "-" month "-" 2DIGIT
1906 day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
1907 / %s"Thursday" / %s"Friday" / %s"Saturday"
1910 asctime-date = day-name SP date3 SP time-of-day SP year
1911 date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
1914 HTTP-date is case sensitive. Note that Section 4.2 of [CACHING]
1915 relaxes this for cache recipients.
1917 A sender MUST NOT generate additional whitespace in an HTTP-date
1918 beyond that specifically included as SP in the grammar. The
1919 semantics of day-name, day, month, year, and time-of-day are the same
1920 as those defined for the Internet Message Format constructs with the
1921 corresponding name ([RFC5322], Section 3.3).
1923 Recipients of a timestamp value in rfc850-date format, which uses a
1924 two-digit year, MUST interpret a timestamp that appears to be more
1925 than 50 years in the future as representing the most recent year in
1926 the past that had the same last two digits.
1928 Recipients of timestamp values are encouraged to be robust in parsing
1929 timestamps unless otherwise restricted by the field definition. For
1930 example, messages are occasionally forwarded over HTTP from a non-
1931 HTTP source that might generate any of the date and time
1932 specifications defined by the Internet Message Format.
1934 | *Note:* HTTP requirements for timestamp formats apply only to
1935 | their usage within the protocol stream. Implementations are
1936 | not required to use these formats for user presentation,
1937 | request logging, etc.
19396. Message Abstraction
1941 Each major version of HTTP defines its own syntax for communicating
1942 messages. This section defines an abstract data type for HTTP
1943 messages based on a generalization of those message characteristics,
1944 common structure, and capacity for conveying semantics. This
1945 abstraction is used to define requirements on senders and recipients
1946 that are independent of the HTTP version, such that a message in one
1947 version can be relayed through other versions without changing its
1950 A "message" consists of the following:
1952 * control data to describe and route the message,
1954 * a headers lookup table of name/value pairs for extending that
1955 control data and conveying additional information about the
1956 sender, message, content, or context,
1958 * a potentially unbounded stream of content, and
1960 * a trailers lookup table of name/value pairs for communicating
1961 information obtained while sending the content.
1963 Framing and control data is sent first, followed by a header section
1964 containing fields for the headers table. When a message includes
1965 content, the content is sent after the header section, potentially
1966 followed by a trailer section that might contain fields for the
1969 Messages are expected to be processed as a stream, wherein the
1970 purpose of that stream and its continued processing is revealed while
1971 being read. Hence, control data describes what the recipient needs
1972 to know immediately, header fields describe what needs to be known
1973 before receiving content, the content (when present) presumably
1974 contains what the recipient wants or needs to fulfill the message
1975 semantics, and trailer fields provide optional metadata that was
1976 unknown prior to sending the content.
1978 Messages are intended to be "self-descriptive": everything a
1979 recipient needs to know about the message can be determined by
1980 looking at the message itself, after decoding or reconstituting parts
1981 that have been compressed or elided in transit, without requiring an
1982 understanding of the sender's current application state (established
1983 via prior messages). However, a client MUST retain knowledge of the
1984 request when parsing, interpreting, or caching a corresponding
1985 response. For example, responses to the HEAD method look just like
1986 the beginning of a response to GET but cannot be parsed in the same
1989 Note that this message abstraction is a generalization across many
1990 versions of HTTP, including features that might not be found in some
1991 versions. For example, trailers were introduced within the HTTP/1.1
1992 chunked transfer coding as a trailer section after the content. An
1993 equivalent feature is present in HTTP/2 and HTTP/3 within the header
1994 block that terminates each stream.
19966.1. Framing and Completeness
1998 Message framing indicates how each message begins and ends, such that
1999 each message can be distinguished from other messages or noise on the
2000 same connection. Each major version of HTTP defines its own framing
2003 HTTP/0.9 and early deployments of HTTP/1.0 used closure of the
2004 underlying connection to end a response. For backwards
2005 compatibility, this implicit framing is also allowed in HTTP/1.1.
2006 However, implicit framing can fail to distinguish an incomplete
2007 response if the connection closes early. For that reason, almost all
2008 modern implementations use explicit framing in the form of length-
2009 delimited sequences of message data.
2011 A message is considered "complete" when all of the octets indicated
2012 by its framing are available. Note that, when no explicit framing is
2013 used, a response message that is ended by the underlying connection's
2014 close is considered complete even though it might be
2015 indistinguishable from an incomplete response, unless a transport-
2016 level error indicates that it is not complete.
2020 Messages start with control data that describe its primary purpose.
2021 Request message control data includes a request method (Section 9),
2022 request target (Section 7.1), and protocol version (Section 2.5).
2023 Response message control data includes a status code (Section 15),
2024 optional reason phrase, and protocol version.
2026 In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the
2027 first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]),
2028 control data is sent as pseudo-header fields with a reserved name
2029 prefix (e.g., ":authority").
2031 Every HTTP message has a protocol version. Depending on the version
2032 in use, it might be identified within the message explicitly or
2033 inferred by the connection over which the message is received.
2034 Recipients use that version information to determine limitations or
2035 potential for later communication with that sender.
2037 When a message is forwarded by an intermediary, the protocol version
2038 is updated to reflect the version used by that intermediary. The Via
2039 header field (Section 7.6.3) is used to communicate upstream protocol
2040 information within a forwarded message.
2042 A client SHOULD send a request version equal to the highest version
2043 to which the client is conformant and whose major version is no
2044 higher than the highest version supported by the server, if this is
2045 known. A client MUST NOT send a version to which it is not
2048 A client MAY send a lower request version if it is known that the
2049 server incorrectly implements the HTTP specification, but only after
2050 the client has attempted at least one normal request and determined
2051 from the response status code or header fields (e.g., Server) that
2052 the server improperly handles higher request versions.
2054 A server SHOULD send a response version equal to the highest version
2055 to which the server is conformant that has a major version less than
2056 or equal to the one received in the request. A server MUST NOT send
2057 a version to which it is not conformant. A server can send a 505
2058 (HTTP Version Not Supported) response if it wishes, for any reason,
2059 to refuse service of the client's major protocol version.
2061 A recipient that receives a message with a major version number that
2062 it implements and a minor version number higher than what it
2063 implements SHOULD process the message as if it were in the highest
2064 minor version within that major version to which the recipient is
2065 conformant. A recipient can assume that a message with a higher
2066 minor version, when sent to a recipient that has not yet indicated
2067 support for that higher version, is sufficiently backwards-compatible
2068 to be safely processed by any implementation of the same major
2073 Fields (Section 5) that are sent or received before the content are
2074 referred to as "header fields" (or just "headers", colloquially).
2076 The "header section" of a message consists of a sequence of header
2077 field lines. Each header field might modify or extend message
2078 semantics, describe the sender, define the content, or provide
2081 | *Note:* We refer to named fields specifically as a "header
2082 | field" when they are only allowed to be sent in the header
2087 HTTP messages often transfer a complete or partial representation as
2088 the message "content": a stream of octets sent after the header
2089 section, as delineated by the message framing.
2091 This abstract definition of content reflects the data after it has
2092 been extracted from the message framing. For example, an HTTP/1.1
2093 message body (Section 6 of [HTTP/1.1]) might consist of a stream of
2094 data encoded with the chunked transfer coding -- a sequence of data
2095 chunks, one zero-length chunk, and a trailer section -- whereas the
2096 content of that same message includes only the data stream after the
2097 transfer coding has been decoded; it does not include the chunk
2098 lengths, chunked framing syntax, nor the trailer fields
2101 | *Note:* Some field names have a "Content-" prefix. This is an
2102 | informal convention; while some of these fields refer to the
2103 | content of the message, as defined above, others are scoped to
2104 | the selected representation (Section 3.2). See the individual
2105 | field's definition to disambiguate.
21076.4.1. Content Semantics
2109 The purpose of content in a request is defined by the method
2110 semantics (Section 9).
2112 For example, a representation in the content of a PUT request
2113 (Section 9.3.4) represents the desired state of the target resource
2114 after the request is successfully applied, whereas a representation
2115 in the content of a POST request (Section 9.3.3) represents
2116 information to be processed by the target resource.
2118 In a response, the content's purpose is defined by the request
2119 method, response status code (Section 15), and response fields
2120 describing that content. For example, the content of a 200 (OK)
2121 response to GET (Section 9.3.1) represents the current state of the
2122 target resource, as observed at the time of the message origination
2123 date (Section 6.6.1), whereas the content of the same status code in
2124 a response to POST might represent either the processing result or
2125 the new state of the target resource after applying the processing.
2127 The content of a 206 (Partial Content) response to GET contains
2128 either a single part of the selected representation or a multipart
2129 message body containing multiple parts of that representation, as
2130 described in Section 15.3.7.
2132 Response messages with an error status code usually contain content
2133 that represents the error condition, such that the content describes
2134 the error state and what steps are suggested for resolving it.
2136 Responses to the HEAD request method (Section 9.3.2) never include
2137 content; the associated response header fields indicate only what
2138 their values would have been if the request method had been GET
2141 2xx (Successful) responses to a CONNECT request method
2142 (Section 9.3.6) switch the connection to tunnel mode instead of
2145 All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
2146 responses do not include content.
2148 All other responses do include content, although that content might
21516.4.2. Identifying Content
2153 When a complete or partial representation is transferred as message
2154 content, it is often desirable for the sender to supply, or the
2155 recipient to determine, an identifier for a resource corresponding to
2156 that specific representation. For example, a client making a GET
2157 request on a resource for "the current weather report" might want an
2158 identifier specific to the content returned (e.g., "weather report
2159 for Laguna Beach at 20210720T1711"). This can be useful for sharing
2160 or bookmarking content from resources that are expected to have
2161 changing representations over time.
2163 For a request message:
2165 * If the request has a Content-Location header field, then the
2166 sender asserts that the content is a representation of the
2167 resource identified by the Content-Location field value. However,
2168 such an assertion cannot be trusted unless it can be verified by
2169 other means (not defined by this specification). The information
2170 might still be useful for revision history links.
2172 * Otherwise, the content is unidentified by HTTP, but a more
2173 specific identifier might be supplied within the content itself.
2175 For a response message, the following rules are applied in order
2176 until a match is found:
2178 1. If the request method is HEAD or the response status code is 204
2179 (No Content) or 304 (Not Modified), there is no content in the
2182 2. If the request method is GET and the response status code is 200
2183 (OK), the content is a representation of the target resource
2186 3. If the request method is GET and the response status code is 203
2187 (Non-Authoritative Information), the content is a potentially
2188 modified or enhanced representation of the target resource as
2189 provided by an intermediary.
2191 4. If the request method is GET and the response status code is 206
2192 (Partial Content), the content is one or more parts of a
2193 representation of the target resource.
2195 5. If the response has a Content-Location header field and its field
2196 value is a reference to the same URI as the target URI, the
2197 content is a representation of the target resource.
2199 6. If the response has a Content-Location header field and its field
2200 value is a reference to a URI different from the target URI, then
2201 the sender asserts that the content is a representation of the
2202 resource identified by the Content-Location field value.
2203 However, such an assertion cannot be trusted unless it can be
2204 verified by other means (not defined by this specification).
2206 7. Otherwise, the content is unidentified by HTTP, but a more
2207 specific identifier might be supplied within the content itself.
2211 Fields (Section 5) that are located within a "trailer section" are
2212 referred to as "trailer fields" (or just "trailers", colloquially).
2213 Trailer fields can be useful for supplying message integrity checks,
2214 digital signatures, delivery metrics, or post-processing status
2217 Trailer fields ought to be processed and stored separately from the
2218 fields in the header section to avoid contradicting message semantics
2219 known at the time the header section was complete. The presence or
2220 absence of certain header fields might impact choices made for the
2221 routing or processing of the message as a whole before the trailers
2222 are received; those choices cannot be unmade by the later discovery
22256.5.1. Limitations on Use of Trailers
2227 A trailer section is only possible when supported by the version of
2228 HTTP in use and enabled by an explicit framing mechanism. For
2229 example, the chunked transfer coding in HTTP/1.1 allows a trailer
2230 section to be sent after the content (Section 7.1.2 of [HTTP/1.1]).
2232 Many fields cannot be processed outside the header section because
2233 their evaluation is necessary prior to receiving the content, such as
2234 those that describe message framing, routing, authentication, request
2235 modifiers, response controls, or content format. A sender MUST NOT
2236 generate a trailer field unless the sender knows the corresponding
2237 header field name's definition permits the field to be sent in
2240 Trailer fields can be difficult to process by intermediaries that
2241 forward messages from one protocol version to another. If the entire
2242 message can be buffered in transit, some intermediaries could merge
2243 trailer fields into the header section (as appropriate) before it is
2244 forwarded. However, in most cases, the trailers are simply
2245 discarded. A recipient MUST NOT merge a trailer field into a header
2246 section unless the recipient understands the corresponding header
2247 field definition and that definition explicitly permits and defines
2248 how trailer field values can be safely merged.
2250 The presence of the keyword "trailers" in the TE header field
2251 (Section 10.1.4) of a request indicates that the client is willing to
2252 accept trailer fields, on behalf of itself and any downstream
2253 clients. For requests from an intermediary, this implies that all
2254 downstream clients are willing to accept trailer fields in the
2255 forwarded response. Note that the presence of "trailers" does not
2256 mean that the client(s) will process any particular trailer field in
2257 the response; only that the trailer section(s) will not be dropped by
2260 Because of the potential for trailer fields to be discarded in
2261 transit, a server SHOULD NOT generate trailer fields that it believes
2262 are necessary for the user agent to receive.
22646.5.2. Processing Trailer Fields
2266 The "Trailer" header field (Section 6.6.2) can be sent to indicate
2267 fields likely to be sent in the trailer section, which allows
2268 recipients to prepare for their receipt before processing the
2269 content. For example, this could be useful if a field name indicates
2270 that a dynamic checksum should be calculated as the content is
2271 received and then immediately checked upon receipt of the trailer
2274 Like header fields, trailer fields with the same name are processed
2275 in the order received; multiple trailer field lines with the same
2276 name have the equivalent semantics as appending the multiple values
2277 as a list of members. Trailer fields that might be generated more
2278 than once during a message MUST be defined as a list-based field even
2279 if each member value is only processed once per field line received.
2281 At the end of a message, a recipient MAY treat the set of received
2282 trailer fields as a data structure of name/value pairs, similar to
2283 (but separate from) the header fields. Additional processing
2284 expectations, if any, can be defined within the field specification
2285 for a field intended for use in trailers.
22876.6. Message Metadata
2289 Fields that describe the message itself, such as when and how the
2290 message has been generated, can appear in both requests and
2295 The "Date" header field represents the date and time at which the
2296 message was originated, having the same semantics as the Origination
2297 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
2298 field value is an HTTP-date, as defined in Section 5.6.7.
2304 Date: Tue, 15 Nov 1994 08:12:31 GMT
2306 A sender that generates a Date header field SHOULD generate its field
2307 value as the best available approximation of the date and time of
2308 message generation. In theory, the date ought to represent the
2309 moment just before generating the message content. In practice, a
2310 sender can generate the date value at any time during message
2313 An origin server with a clock (as defined in Section 5.6.7) MUST
2314 generate a Date header field in all 2xx (Successful), 3xx
2315 (Redirection), and 4xx (Client Error) responses, and MAY generate a
2316 Date header field in 1xx (Informational) and 5xx (Server Error)
2319 An origin server without a clock MUST NOT generate a Date header
2322 A recipient with a clock that receives a response message without a
2323 Date header field MUST record the time it was received and append a
2324 corresponding Date header field to the message's header section if it
2325 is cached or forwarded downstream.
2327 A recipient with a clock that receives a response with an invalid
2328 Date header field value MAY replace that value with the time that
2329 response was received.
2331 A user agent MAY send a Date header field in a request, though
2332 generally will not do so unless it is believed to convey useful
2333 information to the server. For example, custom applications of HTTP
2334 might convey a Date if the server is expected to adjust its
2335 interpretation of the user's request based on differences between the
2336 user agent and server clocks.
2340 The "Trailer" header field provides a list of field names that the
2341 sender anticipates sending as trailer fields within that message.
2342 This allows a recipient to prepare for receipt of the indicated
2343 metadata before it starts processing the content.
2345 Trailer = #field-name
2347 For example, a sender might indicate that a signature will be
2348 computed as the content is being streamed and provide the final
2349 signature as a trailer field. This allows a recipient to perform the
2350 same check on the fly as it receives the content.
2352 A sender that intends to generate one or more trailer fields in a
2353 message SHOULD generate a Trailer header field in the header section
2354 of that message to indicate which fields might be present in the
2357 If an intermediary discards the trailer section in transit, the
2358 Trailer field could provide a hint of what metadata was lost, though
2359 there is no guarantee that a sender of Trailer will always follow
2360 through by sending the named fields.
23627. Routing HTTP Messages
2364 HTTP request message routing is determined by each client based on
2365 the target resource, the client's proxy configuration, and
2366 establishment or reuse of an inbound connection. The corresponding
2367 response routing follows the same connection chain back to the
23707.1. Determining the Target Resource
2372 Although HTTP is used in a wide variety of applications, most clients
2373 rely on the same resource identification mechanism and configuration
2374 techniques as general-purpose Web browsers. Even when communication
2375 options are hard-coded in a client's configuration, we can think of
2376 their combined effect as a URI reference (Section 4.1).
2378 A URI reference is resolved to its absolute form in order to obtain
2379 the "target URI". The target URI excludes the reference's fragment
2380 component, if any, since fragment identifiers are reserved for
2381 client-side processing ([URI], Section 3.5).
2383 To perform an action on a "target resource", the client sends a
2384 request message containing enough components of its parsed target URI
2385 to enable recipients to identify that same resource. For historical
2386 reasons, the parsed target URI components, collectively referred to
2387 as the "request target", are sent within the message control data and
2388 the Host header field (Section 7.2).
2390 There are two unusual cases for which the request target components
2391 are in a method-specific form:
2393 * For CONNECT (Section 9.3.6), the request target is the host name
2394 and port number of the tunnel destination, separated by a colon.
2396 * For OPTIONS (Section 9.3.7), the request target can be a single
2399 See the respective method definitions for details. These forms MUST
2400 NOT be used with other methods.
2402 Upon receipt of a client's request, a server reconstructs the target
2403 URI from the received components in accordance with their local
2404 configuration and incoming connection context. This reconstruction
2405 is specific to each major protocol version. For example, Section 3.3
2406 of [HTTP/1.1] defines how a server determines the target URI of an
2409 | *Note:* Previous specifications defined the recomposed target
2410 | URI as a distinct concept, the "effective request URI".
24127.2. Host and :authority
2414 The "Host" header field in a request provides the host and port
2415 information from the target URI, enabling the origin server to
2416 distinguish among resources while servicing requests for multiple
2419 In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in
2420 some cases, supplanted by the ":authority" pseudo-header field of a
2421 request's control data.
2423 Host = uri-host [ ":" port ] ; Section 4
2425 The target URI's authority information is critical for handling a
2426 request. A user agent MUST generate a Host header field in a request
2427 unless it sends that information as an ":authority" pseudo-header
2428 field. A user agent that sends Host SHOULD send it as the first
2429 field in the header section of a request.
2431 For example, a GET request to the origin server for
2432 <http://www.example.org/pub/WWW/> would begin with:
2434 GET /pub/WWW/ HTTP/1.1
2435 Host: www.example.org
2437 Since the host and port information acts as an application-level
2438 routing mechanism, it is a frequent target for malware seeking to
2439 poison a shared cache or redirect a request to an unintended server.
2440 An interception proxy is particularly vulnerable if it relies on the
2441 host and port information for redirecting requests to internal
2442 servers, or for use as a cache key in a shared cache, without first
2443 verifying that the intercepted connection is targeting a valid IP
2444 address for that host.
24467.3. Routing Inbound Requests
2448 Once the target URI and its origin are determined, a client decides
2449 whether a network request is necessary to accomplish the desired
2450 semantics and, if so, where that request is to be directed.
2454 If the client has a cache [CACHING] and the request can be satisfied
2455 by it, then the request is usually directed there first.
2459 If the request is not satisfied by a cache, then a typical client
2460 will check its configuration to determine whether a proxy is to be
2461 used to satisfy the request. Proxy configuration is implementation-
2462 dependent, but is often based on URI prefix matching, selective
2463 authority matching, or both, and the proxy itself is usually
2464 identified by an "http" or "https" URI.
2466 If an "http" or "https" proxy is applicable, the client connects
2467 inbound by establishing (or reusing) a connection to that proxy and
2468 then sending it an HTTP request message containing a request target
2469 that matches the client's target URI.
2473 If no proxy is applicable, a typical client will invoke a handler
2474 routine (specific to the target URI's scheme) to obtain access to the
2475 identified resource. How that is accomplished is dependent on the
2476 target URI scheme and defined by its associated specification.
2478 Section 4.3.2 defines how to obtain access to an "http" resource by
2479 establishing (or reusing) an inbound connection to the identified
2480 origin server and then sending it an HTTP request message containing
2481 a request target that matches the client's target URI.
2483 Section 4.3.3 defines how to obtain access to an "https" resource by
2484 establishing (or reusing) an inbound secured connection to an origin
2485 server that is authoritative for the identified origin and then
2486 sending it an HTTP request message containing a request target that
2487 matches the client's target URI.
24897.4. Rejecting Misdirected Requests
2491 Once a request is received by a server and parsed sufficiently to
2492 determine its target URI, the server decides whether to process the
2493 request itself, forward the request to another server, redirect the
2494 client to a different resource, respond with an error, or drop the
2495 connection. This decision can be influenced by anything about the
2496 request or connection context, but is specifically directed at
2497 whether the server has been configured to process requests for that
2498 target URI and whether the connection context is appropriate for that
2501 For example, a request might have been misdirected, deliberately or
2502 accidentally, such that the information within a received Host header
2503 field differs from the connection's host or port. If the connection
2504 is from a trusted gateway, such inconsistency might be expected;
2505 otherwise, it might indicate an attempt to bypass security filters,
2506 trick the server into delivering non-public content, or poison a
2507 cache. See Section 17 for security considerations regarding message
2510 Unless the connection is from a trusted gateway, an origin server
2511 MUST reject a request if any scheme-specific requirements for the
2512 target URI are not met. In particular, a request for an "https"
2513 resource MUST be rejected unless it has been received over a
2514 connection that has been secured via a certificate valid for that
2515 target URI's origin, as defined by Section 4.2.2.
2517 The 421 (Misdirected Request) status code in a response indicates
2518 that the origin server has rejected the request because it appears to
2519 have been misdirected (Section 15.5.20).
25217.5. Response Correlation
2523 A connection might be used for multiple request/response exchanges.
2524 The mechanism used to correlate between request and response messages
2525 is version dependent; some versions of HTTP use implicit ordering of
2526 messages, while others use an explicit identifier.
2528 All responses, regardless of the status code (including interim
2529 responses) can be sent at any time after a request is received, even
2530 if the request is not yet complete. A response can complete before
2531 its corresponding request is complete (Section 6.1). Likewise,
2532 clients are not expected to wait any specific amount of time for a
2533 response. Clients (including intermediaries) might abandon a request
2534 if the response is not received within a reasonable period of time.
2536 A client that receives a response while it is still sending the
2537 associated request SHOULD continue sending that request unless it
2538 receives an explicit indication to the contrary (see, e.g.,
2539 Section 9.5 of [HTTP/1.1] and Section 6.4 of [HTTP/2]).
25417.6. Message Forwarding
2543 As described in Section 3.7, intermediaries can serve a variety of
2544 roles in the processing of HTTP requests and responses. Some
2545 intermediaries are used to improve performance or availability.
2546 Others are used for access control or to filter content. Since an
2547 HTTP stream has characteristics similar to a pipe-and-filter
2548 architecture, there are no inherent limits to the extent an
2549 intermediary can enhance (or interfere) with either direction of the
2552 Intermediaries are expected to forward messages even when protocol
2553 elements are not recognized (e.g., new methods, status codes, or
2554 field names) since that preserves extensibility for downstream
2557 An intermediary not acting as a tunnel MUST implement the Connection
2558 header field, as specified in Section 7.6.1, and exclude fields from
2559 being forwarded that are only intended for the incoming connection.
2561 An intermediary MUST NOT forward a message to itself unless it is
2562 protected from an infinite request loop. In general, an intermediary
2563 ought to recognize its own server names, including any aliases, local
2564 variations, or literal IP addresses, and respond to such requests
2567 An HTTP message can be parsed as a stream for incremental processing
2568 or forwarding downstream. However, senders and recipients cannot
2569 rely on incremental delivery of partial messages, since some
2570 implementations will buffer or delay message forwarding for the sake
2571 of network efficiency, security checks, or content transformations.
2575 The "Connection" header field allows the sender to list desired
2576 control options for the current connection.
2578 Connection = #connection-option
2579 connection-option = token
2581 Connection options are case-insensitive.
2583 When a field aside from Connection is used to supply control
2584 information for or about the current connection, the sender MUST list
2585 the corresponding field name within the Connection header field.
2586 Note that some versions of HTTP prohibit the use of fields for such
2587 information, and therefore do not allow the Connection field.
2589 Intermediaries MUST parse a received Connection header field before a
2590 message is forwarded and, for each connection-option in this field,
2591 remove any header or trailer field(s) from the message with the same
2592 name as the connection-option, and then remove the Connection header
2593 field itself (or replace it with the intermediary's own control
2594 options for the forwarded message).
2596 Hence, the Connection header field provides a declarative way of
2597 distinguishing fields that are only intended for the immediate
2598 recipient ("hop-by-hop") from those fields that are intended for all
2599 recipients on the chain ("end-to-end"), enabling the message to be
2600 self-descriptive and allowing future connection-specific extensions
2601 to be deployed without fear that they will be blindly forwarded by
2602 older intermediaries.
2604 Furthermore, intermediaries SHOULD remove or replace fields that are
2605 known to require removal before forwarding, whether or not they
2606 appear as a connection-option, after applying those fields'
2607 semantics. This includes but is not limited to:
2609 * Proxy-Connection (Appendix C.2.2 of [HTTP/1.1])
2611 * Keep-Alive (Section 19.7.1 of [RFC2068])
2613 * TE (Section 10.1.4)
2615 * Transfer-Encoding (Section 6.1 of [HTTP/1.1])
2617 * Upgrade (Section 7.8)
2619 A sender MUST NOT send a connection option corresponding to a field
2620 that is intended for all recipients of the content. For example,
2621 Cache-Control is never appropriate as a connection option
2622 (Section 5.2 of [CACHING]).
2624 Connection options do not always correspond to a field present in the
2625 message, since a connection-specific field might not be needed if
2626 there are no parameters associated with a connection option. In
2627 contrast, a connection-specific field received without a
2628 corresponding connection option usually indicates that the field has
2629 been improperly forwarded by an intermediary and ought to be ignored
2632 When defining a new connection option that does not correspond to a
2633 field, specification authors ought to reserve the corresponding field
2634 name anyway in order to avoid later collisions. Such reserved field
2635 names are registered in the "Hypertext Transfer Protocol (HTTP) Field
2636 Name Registry" (Section 16.3.1).
2640 The "Max-Forwards" header field provides a mechanism with the TRACE
2641 (Section 9.3.8) and OPTIONS (Section 9.3.7) request methods to limit
2642 the number of times that the request is forwarded by proxies. This
2643 can be useful when the client is attempting to trace a request that
2644 appears to be failing or looping mid-chain.
2646 Max-Forwards = 1*DIGIT
2648 The Max-Forwards value is a decimal integer indicating the remaining
2649 number of times this request message can be forwarded.
2651 Each intermediary that receives a TRACE or OPTIONS request containing
2652 a Max-Forwards header field MUST check and update its value prior to
2653 forwarding the request. If the received value is zero (0), the
2654 intermediary MUST NOT forward the request; instead, the intermediary
2655 MUST respond as the final recipient. If the received Max-Forwards
2656 value is greater than zero, the intermediary MUST generate an updated
2657 Max-Forwards field in the forwarded message with a field value that
2658 is the lesser of a) the received value decremented by one (1) or b)
2659 the recipient's maximum supported value for Max-Forwards.
2661 A recipient MAY ignore a Max-Forwards header field received with any
2662 other request methods.
2666 The "Via" header field indicates the presence of intermediate
2667 protocols and recipients between the user agent and the server (on
2668 requests) or between the origin server and the client (on responses),
2669 similar to the "Received" header field in email (Section 3.6.7 of
2670 [RFC5322]). Via can be used for tracking message forwards, avoiding
2671 request loops, and identifying the protocol capabilities of senders
2672 along the request/response chain.
2674 Via = #( received-protocol RWS received-by [ RWS comment ] )
2676 received-protocol = [ protocol-name "/" ] protocol-version
2678 received-by = pseudonym [ ":" port ]
2681 Each member of the Via field value represents a proxy or gateway that
2682 has forwarded the message. Each intermediary appends its own
2683 information about how the message was received, such that the end
2684 result is ordered according to the sequence of forwarding recipients.
2686 A proxy MUST send an appropriate Via header field, as described
2687 below, in each message that it forwards. An HTTP-to-HTTP gateway
2688 MUST send an appropriate Via header field in each inbound request
2689 message and MAY send a Via header field in forwarded response
2692 For each intermediary, the received-protocol indicates the protocol
2693 and protocol version used by the upstream sender of the message.
2694 Hence, the Via field value records the advertised protocol
2695 capabilities of the request/response chain such that they remain
2696 visible to downstream recipients; this can be useful for determining
2697 what backwards-incompatible features might be safe to use in
2698 response, or within a later request, as described in Section 2.5.
2699 For brevity, the protocol-name is omitted when the received protocol
2702 The received-by portion is normally the host and optional port number
2703 of a recipient server or client that subsequently forwarded the
2704 message. However, if the real host is considered to be sensitive
2705 information, a sender MAY replace it with a pseudonym. If a port is
2706 not provided, a recipient MAY interpret that as meaning it was
2707 received on the default port, if any, for the received-protocol.
2709 A sender MAY generate comments to identify the software of each
2710 recipient, analogous to the User-Agent and Server header fields.
2711 However, comments in Via are optional, and a recipient MAY remove
2712 them prior to forwarding the message.
2714 For example, a request message could be sent from an HTTP/1.0 user
2715 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
2716 forward the request to a public proxy at p.example.net, which
2717 completes the request by forwarding it to the origin server at
2718 www.example.com. The request received by www.example.com would then
2719 have the following Via header field:
2721 Via: 1.0 fred, 1.1 p.example.net
2723 An intermediary used as a portal through a network firewall SHOULD
2724 NOT forward the names and ports of hosts within the firewall region
2725 unless it is explicitly enabled to do so. If not enabled, such an
2726 intermediary SHOULD replace each received-by host of any host behind
2727 the firewall by an appropriate pseudonym for that host.
2729 An intermediary MAY combine an ordered subsequence of Via header
2730 field list members into a single member if the entries have identical
2731 received-protocol values. For example,
2733 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
2735 could be collapsed to
2737 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
2739 A sender SHOULD NOT combine multiple list members unless they are all
2740 under the same organizational control and the hosts have already been
2741 replaced by pseudonyms. A sender MUST NOT combine members that have
2742 different received-protocol values.
27447.7. Message Transformations
2746 Some intermediaries include features for transforming messages and
2747 their content. A proxy might, for example, convert between image
2748 formats in order to save cache space or to reduce the amount of
2749 traffic on a slow link. However, operational problems might occur
2750 when these transformations are applied to content intended for
2751 critical applications, such as medical imaging or scientific data
2752 analysis, particularly when integrity checks or digital signatures
2753 are used to ensure that the content received is identical to the
2756 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
2757 designed or configured to modify messages in a semantically
2758 meaningful way (i.e., modifications, beyond those required by normal
2759 HTTP processing, that change the message in a way that would be
2760 significant to the original sender or potentially significant to
2761 downstream recipients). For example, a transforming proxy might be
2762 acting as a shared annotation server (modifying responses to include
2763 references to a local annotation database), a malware filter, a
2764 format transcoder, or a privacy filter. Such transformations are
2765 presumed to be desired by whichever client (or client organization)
2768 If a proxy receives a target URI with a host name that is not a fully
2769 qualified domain name, it MAY add its own domain to the host name it
2770 received when forwarding the request. A proxy MUST NOT change the
2771 host name if the target URI contains a fully qualified domain name.
2773 A proxy MUST NOT modify the "absolute-path" and "query" parts of the
2774 received target URI when forwarding it to the next inbound server
2775 except as required by that forwarding protocol. For example, a proxy
2776 forwarding a request to an origin server via HTTP/1.1 will replace an
2777 empty path with "/" (Section 3.2.1 of [HTTP/1.1]) or "*"
2778 (Section 3.2.4 of [HTTP/1.1]), depending on the request method.
2780 A proxy MUST NOT transform the content (Section 6.4) of a response
2781 message that contains a no-transform cache directive (Section 5.2.2.6
2782 of [CACHING]). Note that this does not apply to message
2783 transformations that do not change the content, such as the addition
2784 or removal of transfer codings (Section 7 of [HTTP/1.1]).
2786 A proxy MAY transform the content of a message that does not contain
2787 a no-transform cache directive. A proxy that transforms the content
2788 of a 200 (OK) response can inform downstream recipients that a
2789 transformation has been applied by changing the response status code
2790 to 203 (Non-Authoritative Information) (Section 15.3.4).
2792 A proxy SHOULD NOT modify header fields that provide information
2793 about the endpoints of the communication chain, the resource state,
2794 or the selected representation (other than the content) unless the
2795 field's definition specifically allows such modification or the
2796 modification is deemed necessary for privacy or security.
2800 The "Upgrade" header field is intended to provide a simple mechanism
2801 for transitioning from HTTP/1.1 to some other protocol on the same
2804 A client MAY send a list of protocol names in the Upgrade header
2805 field of a request to invite the server to switch to one or more of
2806 the named protocols, in order of descending preference, before
2807 sending the final response. A server MAY ignore a received Upgrade
2808 header field if it wishes to continue using the current protocol on
2809 that connection. Upgrade cannot be used to insist on a protocol
2814 protocol = protocol-name ["/" protocol-version]
2815 protocol-name = token
2816 protocol-version = token
2818 Although protocol names are registered with a preferred case,
2819 recipients SHOULD use case-insensitive comparison when matching each
2820 protocol-name to supported protocols.
2822 A server that sends a 101 (Switching Protocols) response MUST send an
2823 Upgrade header field to indicate the new protocol(s) to which the
2824 connection is being switched; if multiple protocol layers are being
2825 switched, the sender MUST list the protocols in layer-ascending
2826 order. A server MUST NOT switch to a protocol that was not indicated
2827 by the client in the corresponding request's Upgrade header field. A
2828 server MAY choose to ignore the order of preference indicated by the
2829 client and select the new protocol(s) based on other factors, such as
2830 the nature of the request or the current load on the server.
2832 A server that sends a 426 (Upgrade Required) response MUST send an
2833 Upgrade header field to indicate the acceptable protocols, in order
2834 of descending preference.
2836 A server MAY send an Upgrade header field in any other response to
2837 advertise that it implements support for upgrading to the listed
2838 protocols, in order of descending preference, when appropriate for a
2841 The following is a hypothetical example sent by a client:
2844 Host: www.example.com
2846 Upgrade: websocket, IRC/6.9, RTA/x11
2848 The capabilities and nature of the application-level communication
2849 after the protocol change is entirely dependent upon the new
2850 protocol(s) chosen. However, immediately after sending the 101
2851 (Switching Protocols) response, the server is expected to continue
2852 responding to the original request as if it had received its
2853 equivalent within the new protocol (i.e., the server still has an
2854 outstanding request to satisfy after the protocol has been changed,
2855 and is expected to do so without requiring the request to be
2858 For example, if the Upgrade header field is received in a GET request
2859 and the server decides to switch protocols, it first responds with a
2860 101 (Switching Protocols) message in HTTP/1.1 and then immediately
2861 follows that with the new protocol's equivalent of a response to a
2862 GET on the target resource. This allows a connection to be upgraded
2863 to protocols with the same semantics as HTTP without the latency cost
2864 of an additional round trip. A server MUST NOT switch protocols
2865 unless the received message semantics can be honored by the new
2866 protocol; an OPTIONS request can be honored by any protocol.
2868 The following is an example response to the above hypothetical
2871 HTTP/1.1 101 Switching Protocols
2875 [... data stream switches to websocket with an appropriate response
2876 (as defined by new protocol) to the "GET /hello" request ...]
2878 A sender of Upgrade MUST also send an "Upgrade" connection option in
2879 the Connection header field (Section 7.6.1) to inform intermediaries
2881 field in an HTTP/1.0 request MUST ignore that Upgrade field.
2883 A client cannot begin using an upgraded protocol on the connection
2884 until it has completely sent the request message (i.e., the client
2885 can't change the protocol it is sending in the middle of a message).
2886 If a server receives both an Upgrade and an Expect header field with
2887 the "100-continue" expectation (Section 10.1.1), the server MUST send
2888 a 100 (Continue) response before sending a 101 (Switching Protocols)
2891 The Upgrade header field only applies to switching protocols on top
2892 of the existing connection; it cannot be used to switch the
2893 underlying connection (transport) protocol, nor to switch the
2894 existing communication to a different connection. For those
2895 purposes, it is more appropriate to use a 3xx (Redirection) response
2898 This specification only defines the protocol name "HTTP" for use by
2899 the family of Hypertext Transfer Protocols, as defined by the HTTP
2900 version rules of Section 2.5 and future updates to this
2901 specification. Additional protocol names ought to be registered
2902 using the registration procedure defined in Section 16.7.
29048. Representation Data and Metadata
29068.1. Representation Data
2908 The representation data associated with an HTTP message is either
2909 provided as the content of the message or referred to by the message
2910 semantics and the target URI. The representation data is in a format
2911 and encoding defined by the representation metadata header fields.
2913 The data type of the representation data is determined via the header
2914 fields Content-Type and Content-Encoding. These define a two-layer,
2915 ordered encoding model:
2917 representation-data := Content-Encoding( Content-Type( data ) )
29198.2. Representation Metadata
2921 Representation header fields provide metadata about the
2922 representation. When a message includes content, the representation
2923 header fields describe how to interpret that data. In a response to
2924 a HEAD request, the representation header fields describe the
2925 representation data that would have been enclosed in the content if
2926 the same request had been a GET.
2930 The "Content-Type" header field indicates the media type of the
2931 associated representation: either the representation enclosed in the
2932 message content or the selected representation, as determined by the
2933 message semantics. The indicated media type defines both the data
2934 format and how that data is intended to be processed by a recipient,
2935 within the scope of the received message semantics, after any content
2936 codings indicated by Content-Encoding are decoded.
2938 Content-Type = media-type
2940 Media types are defined in Section 8.3.1. An example of the field is
2942 Content-Type: text/html; charset=ISO-8859-4
2944 A sender that generates a message containing content SHOULD generate
2945 a Content-Type header field in that message unless the intended media
2946 type of the enclosed representation is unknown to the sender. If a
2947 Content-Type header field is not present, the recipient MAY either
2948 assume a media type of "application/octet-stream" ([RFC2046],
2949 Section 4.5.1) or examine the data to determine its type.
2951 In practice, resource owners do not always properly configure their
2952 origin server to provide the correct Content-Type for a given
2953 representation. Some user agents examine the content and, in certain
2954 cases, override the received type (for example, see [Sniffing]).
2955 This "MIME sniffing" risks drawing incorrect conclusions about the
2956 data, which might expose the user to additional security risks (e.g.,
2957 "privilege escalation"). Furthermore, distinct media types often
2958 share a common data format, differing only in how the data is
2959 intended to be processed, which is impossible to distinguish by
2960 inspecting the data alone. When sniffing is implemented,
2961 implementers are encouraged to provide a means for the user to
2964 Although Content-Type is defined as a singleton field, it is
2965 sometimes incorrectly generated multiple times, resulting in a
2966 combined field value that appears to be a list. Recipients often
2967 attempt to handle this error by using the last syntactically valid
2968 member of the list, leading to potential interoperability and
2969 security issues if different implementations have different error
2974 HTTP uses media types [RFC2046] in the Content-Type (Section 8.3) and
2975 Accept (Section 12.5.1) header fields in order to provide open and
2976 extensible data typing and type negotiation. Media types define both
2977 a data format and various processing models: how to process that data
2978 in accordance with the message context.
2980 media-type = type "/" subtype parameters
2984 The type and subtype tokens are case-insensitive.
2986 The type/subtype MAY be followed by semicolon-delimited parameters
2987 (Section 5.6.6) in the form of name/value pairs. The presence or
2988 absence of a parameter might be significant to the processing of a
2989 media type, depending on its definition within the media type
2990 registry. Parameter values might or might not be case-sensitive,
2991 depending on the semantics of the parameter name.
2993 For example, the following media types are equivalent in describing
2994 HTML text data encoded in the UTF-8 character encoding scheme, but
2995 the first is preferred for consistency (the "charset" parameter value
2996 is defined as being case-insensitive in [RFC2046], Section 4.1.2):
2998 text/html;charset=utf-8
2999 Text/HTML;Charset="utf-8"
3000 text/html; charset="utf-8"
3001 text/html;charset=UTF-8
3003 Media types ought to be registered with IANA according to the
3004 procedures defined in [BCP13].
3008 HTTP uses "charset" names to indicate or negotiate the character
3009 encoding scheme ([RFC6365], Section 2) of a textual representation.
3010 In the fields defined by this document, charset names appear either
3011 in parameters (Content-Type), or, for Accept-Encoding, in the form of
3012 a plain token. In both cases, charset names are matched case-
3015 Charset names ought to be registered in the IANA "Character Sets"
3016 registry (<https://www.iana.org/assignments/character-sets>)
3017 according to the procedures defined in Section 2 of [RFC2978].
3019 | *Note:* In theory, charset names are defined by the "mime-
3020 | charset" ABNF rule defined in Section 2.3 of [RFC2978] (as
3021 | corrected in [Err1912]). That rule allows two characters that
3022 | are not included in "token" ("{" and "}"), but no charset name
3023 | registered at the time of this writing includes braces (see
30268.3.3. Multipart Types
3028 MIME provides for a number of "multipart" types -- encapsulations of
3029 one or more representations within a single message body. All
3030 multipart types share a common syntax, as defined in Section 5.1.1 of
3031 [RFC2046], and include a boundary parameter as part of the media type
3032 value. The message body is itself a protocol element; a sender MUST
3033 generate only CRLF to represent line breaks between body parts.
3035 HTTP message framing does not use the multipart boundary as an
3036 indicator of message body length, though it might be used by
3037 implementations that generate or process the content. For example,
3038 the "multipart/form-data" type is often used for carrying form data
3039 in a request, as described in [RFC7578], and the "multipart/
3040 byteranges" type is defined by this specification for use in some 206
3041 (Partial Content) responses (see Section 15.3.7).
30438.4. Content-Encoding
3045 The "Content-Encoding" header field indicates what content codings
3046 have been applied to the representation, beyond those inherent in the
3047 media type, and thus what decoding mechanisms have to be applied in
3048 order to obtain data in the media type referenced by the Content-Type
3049 header field. Content-Encoding is primarily used to allow a
3050 representation's data to be compressed without losing the identity of
3051 its underlying media type.
3053 Content-Encoding = #content-coding
3055 An example of its use is
3057 Content-Encoding: gzip
3059 If one or more encodings have been applied to a representation, the
3060 sender that applied the encodings MUST generate a Content-Encoding
3061 header field that lists the content codings in the order in which
3062 they were applied. Note that the coding named "identity" is reserved
3063 for its special role in Accept-Encoding and thus SHOULD NOT be
3066 Additional information about the encoding parameters can be provided
3067 by other header fields not defined by this specification.
3069 Unlike Transfer-Encoding (Section 6.1 of [HTTP/1.1]), the codings
3070 listed in Content-Encoding are a characteristic of the
3071 representation; the representation is defined in terms of the coded
3072 form, and all other metadata about the representation is about the
3073 coded form unless otherwise noted in the metadata definition.
3074 Typically, the representation is only decoded just prior to rendering
3077 If the media type includes an inherent encoding, such as a data
3078 format that is always compressed, then that encoding would not be
3079 restated in Content-Encoding even if it happens to be the same
3080 algorithm as one of the content codings. Such a content coding would
3081 only be listed if, for some bizarre reason, it is applied a second
3082 time to form the representation. Likewise, an origin server might
3083 choose to publish the same data as multiple representations that
3084 differ only in whether the coding is defined as part of Content-Type
3085 or Content-Encoding, since some user agents will behave differently
3086 in their handling of each response (e.g., open a "Save as ..." dialog
3087 instead of automatic decompression and rendering of content).
3089 An origin server MAY respond with a status code of 415 (Unsupported
3090 Media Type) if a representation in the request message has a content
3091 coding that is not acceptable.
30938.4.1. Content Codings
3095 Content coding values indicate an encoding transformation that has
3096 been or can be applied to a representation. Content codings are
3097 primarily used to allow a representation to be compressed or
3098 otherwise usefully transformed without losing the identity of its
3099 underlying media type and without loss of information. Frequently,
3100 the representation is stored in coded form, transmitted directly, and
3101 only decoded by the final recipient.
3103 content-coding = token
3105 All content codings are case-insensitive and ought to be registered
3106 within the "HTTP Content Coding Registry", as described in
3109 Content-coding values are used in the Accept-Encoding
3110 (Section 12.5.3) and Content-Encoding (Section 8.4) header fields.
31128.4.1.1. Compress Coding
3114 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding
3115 [Welch] that is commonly produced by the UNIX file compression
3116 program "compress". A recipient SHOULD consider "x-compress" to be
3117 equivalent to "compress".
31198.4.1.2. Deflate Coding
3121 The "deflate" coding is a "zlib" data format [RFC1950] containing a
3122 "deflate" compressed data stream [RFC1951] that uses a combination of
3123 the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
3125 | *Note:* Some non-conformant implementations send the "deflate"
3126 | compressed data without the zlib wrapper.
3130 The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
3131 Check (CRC) that is commonly produced by the gzip file compression
3132 program [RFC1952]. A recipient SHOULD consider "x-gzip" to be
3133 equivalent to "gzip".
31358.5. Content-Language
3137 The "Content-Language" header field describes the natural language(s)
3138 of the intended audience for the representation. Note that this
3139 might not be equivalent to all the languages used within the
3142 Content-Language = #language-tag
3144 Language tags are defined in Section 8.5.1. The primary purpose of
3145 Content-Language is to allow a user to identify and differentiate
3146 representations according to the users' own preferred language.
3147 Thus, if the content is intended only for a Danish-literate audience,
3148 the appropriate field is
3150 Content-Language: da
3152 If no Content-Language is specified, the default is that the content
3153 is intended for all language audiences. This might mean that the
3154 sender does not consider it to be specific to any natural language,
3155 or that the sender does not know for which language it is intended.
3157 Multiple languages MAY be listed for content that is intended for
3158 multiple audiences. For example, a rendition of the "Treaty of
3159 Waitangi", presented simultaneously in the original Maori and English
3160 versions, would call for
3162 Content-Language: mi, en
3164 However, just because multiple languages are present within a
3165 representation does not mean that it is intended for multiple
3166 linguistic audiences. An example would be a beginner's language
3167 primer, such as "A First Lesson in Latin", which is clearly intended
3168 to be used by an English-literate audience. In this case, the
3169 Content-Language would properly only include "en".
3171 Content-Language MAY be applied to any media type -- it is not
3172 limited to textual documents.
3176 A language tag, as defined in [RFC5646], identifies a natural
3177 language spoken, written, or otherwise conveyed by human beings for
3178 communication of information to other human beings. Computer
3179 languages are explicitly excluded.
3181 HTTP uses language tags within the Accept-Language and
3182 Content-Language header fields. Accept-Language uses the broader
3183 language-range production defined in Section 12.5.4, whereas
3184 Content-Language uses the language-tag production defined below.
3186 language-tag = <Language-Tag, see [RFC5646], Section 2.1>
3188 A language tag is a sequence of one or more case-insensitive subtags,
3189 each separated by a hyphen character ("-", %x2D). In most cases, a
3190 language tag consists of a primary language subtag that identifies a
3191 broad family of related languages (e.g., "en" = English), which is
3192 optionally followed by a series of subtags that refine or narrow that
3193 language's range (e.g., "en-CA" = the variety of English as
3194 communicated in Canada). Whitespace is not allowed within a language
3195 tag. Example tags include:
3197 fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
3199 See [RFC5646] for further information.
3203 The "Content-Length" header field indicates the associated
3204 representation's data length as a decimal non-negative integer number
3205 of octets. When transferring a representation as content, Content-
3206 Length refers specifically to the amount of data enclosed so that it
3207 can be used to delimit framing (e.g., Section 6.2 of [HTTP/1.1]). In
3208 other cases, Content-Length indicates the selected representation's
3209 current length, which can be used by recipients to estimate transfer
3210 time or to compare with previously stored representations.
3212 Content-Length = 1*DIGIT
3216 Content-Length: 3495
3218 A user agent SHOULD send Content-Length in a request when the method
3219 defines a meaning for enclosed content and it is not sending
3220 Transfer-Encoding. For example, a user agent normally sends Content-
3221 Length in a POST request even when the value is 0 (indicating empty
3222 content). A user agent SHOULD NOT send a Content-Length header field
3223 when the request message does not contain content and the method
3224 semantics do not anticipate such data.
3226 A server MAY send a Content-Length header field in a response to a
3227 HEAD request (Section 9.3.2); a server MUST NOT send Content-Length
3228 in such a response unless its field value equals the decimal number
3229 of octets that would have been sent in the content of a response if
3230 the same request had used the GET method.
3232 A server MAY send a Content-Length header field in a 304 (Not
3233 Modified) response to a conditional GET request (Section 15.4.5); a
3234 server MUST NOT send Content-Length in such a response unless its
3235 field value equals the decimal number of octets that would have been
3236 sent in the content of a 200 (OK) response to the same request.
3238 A server MUST NOT send a Content-Length header field in any response
3239 with a status code of 1xx (Informational) or 204 (No Content). A
3240 server MUST NOT send a Content-Length header field in any 2xx
3241 (Successful) response to a CONNECT request (Section 9.3.6).
3243 Aside from the cases defined above, in the absence of Transfer-
3244 Encoding, an origin server SHOULD send a Content-Length header field
3245 when the content size is known prior to sending the complete header
3246 section. This will allow downstream recipients to measure transfer
3247 progress, know when a received message is complete, and potentially
3248 reuse the connection for additional requests.
3250 Any Content-Length field value greater than or equal to zero is
3251 valid. Since there is no predefined limit to the length of content,
3252 a recipient MUST anticipate potentially large decimal numerals and
3253 prevent parsing errors due to integer conversion overflows or
3254 precision loss due to integer conversion (Section 17.5).
3256 Because Content-Length is used for message delimitation in HTTP/1.1,
3257 its field value can impact how the message is parsed by downstream
3258 recipients even when the immediate connection is not using HTTP/1.1.
3259 If the message is forwarded by a downstream intermediary, a Content-
3260 Length field value that is inconsistent with the received message
3261 framing might cause a security failure due to request smuggling or
3264 As a result, a sender MUST NOT forward a message with a Content-
3265 Length header field value that is known to be incorrect.
3267 Likewise, a sender MUST NOT forward a message with a Content-Length
3268 header field value that does not match the ABNF above, with one
3269 exception: a recipient of a Content-Length header field value
3270 consisting of the same decimal value repeated as a comma-separated
3271 list (e.g, "Content-Length: 42, 42") MAY either reject the message as
3272 invalid or replace that invalid field value with a single instance of
3273 the decimal value, since this likely indicates that a duplicate was
3274 generated or combined by an upstream message processor.
32768.7. Content-Location
3278 The "Content-Location" header field references a URI that can be used
3279 as an identifier for a specific resource corresponding to the
3280 representation in this message's content. In other words, if one
3281 were to perform a GET request on this URI at the time of this
3282 message's generation, then a 200 (OK) response would contain the same
3283 representation that is enclosed as content in this message.
3285 Content-Location = absolute-URI / partial-URI
3287 The field value is either an absolute-URI or a partial-URI. In the
3288 latter case (Section 4), the referenced URI is relative to the target
3289 URI ([URI], Section 5).
3291 The Content-Location value is not a replacement for the target URI
3292 (Section 7.1). It is representation metadata. It has the same
3293 syntax and semantics as the header field of the same name defined for
3294 MIME body parts in Section 4 of [RFC2557]. However, its appearance
3295 in an HTTP message has some special implications for HTTP recipients.
3297 If Content-Location is included in a 2xx (Successful) response
3298 message and its value refers (after conversion to absolute form) to a
3299 URI that is the same as the target URI, then the recipient MAY
3300 consider the content to be a current representation of that resource
3301 at the time indicated by the message origination date. For a GET
3302 (Section 9.3.1) or HEAD (Section 9.3.2) request, this is the same as
3303 the default semantics when no Content-Location is provided by the
3304 server. For a state-changing request like PUT (Section 9.3.4) or
3305 POST (Section 9.3.3), it implies that the server's response contains
3306 the new representation of that resource, thereby distinguishing it
3307 from representations that might only report about the action (e.g.,
3308 "It worked!"). This allows authoring applications to update their
3309 local copies without the need for a subsequent GET request.
3311 If Content-Location is included in a 2xx (Successful) response
3312 message and its field value refers to a URI that differs from the
3313 target URI, then the origin server claims that the URI is an
3314 identifier for a different resource corresponding to the enclosed
3315 representation. Such a claim can only be trusted if both identifiers
3316 share the same resource owner, which cannot be programmatically
3317 determined via HTTP.
3319 * For a response to a GET or HEAD request, this is an indication
3320 that the target URI refers to a resource that is subject to
3321 content negotiation and the Content-Location field value is a more
3322 specific identifier for the selected representation.
3324 * For a 201 (Created) response to a state-changing method, a
3325 Content-Location field value that is identical to the Location
3326 field value indicates that this content is a current
3327 representation of the newly created resource.
3329 * Otherwise, such a Content-Location indicates that this content is
3330 a representation reporting on the requested action's status and
3331 that the same report is available (for future access with GET) at
3332 the given URI. For example, a purchase transaction made via a
3333 POST request might include a receipt document as the content of
3334 the 200 (OK) response; the Content-Location field value provides
3335 an identifier for retrieving a copy of that same receipt in the
3338 A user agent that sends Content-Location in a request message is
3339 stating that its value refers to where the user agent originally
3340 obtained the content of the enclosed representation (prior to any
3341 modifications made by that user agent). In other words, the user
3342 agent is providing a back link to the source of the original
3345 An origin server that receives a Content-Location field in a request
3346 message MUST treat the information as transitory request context
3347 rather than as metadata to be saved verbatim as part of the
3348 representation. An origin server MAY use that context to guide in
3349 processing the request or to save it for other uses, such as within
3350 source links or versioning metadata. However, an origin server MUST
3351 NOT use such context information to alter the request semantics.
3353 For example, if a client makes a PUT request on a negotiated resource
3354 and the origin server accepts that PUT (without redirection), then
3355 the new state of that resource is expected to be consistent with the
3356 one representation supplied in that PUT; the Content-Location cannot
3357 be used as a form of reverse content selection identifier to update
3358 only one of the negotiated representations. If the user agent had
3359 wanted the latter semantics, it would have applied the PUT directly
3360 to the Content-Location URI.
33628.8. Validator Fields
3364 Resource metadata is referred to as a "validator" if it can be used
3365 within a precondition (Section 13.1) to make a conditional request
3366 (Section 13). Validator fields convey a current validator for the
3367 selected representation (Section 3.2).
3369 In responses to safe requests, validator fields describe the selected
3370 representation chosen by the origin server while handling the
3371 response. Note that, depending on the method and status code
3372 semantics, the selected representation for a given response is not
3373 necessarily the same as the representation enclosed as response
3376 In a successful response to a state-changing request, validator
3377 fields describe the new representation that has replaced the prior
3378 selected representation as a result of processing the request.
3380 For example, an ETag field in a 201 (Created) response communicates
3381 the entity tag of the newly created resource's representation, so
3382 that the entity tag can be used as a validator in later conditional
3383 requests to prevent the "lost update" problem.
3385 This specification defines two forms of metadata that are commonly
3386 used to observe resource state and test for preconditions:
3387 modification dates (Section 8.8.2) and opaque entity tags
3388 (Section 8.8.3). Additional metadata that reflects resource state
3389 has been defined by various extensions of HTTP, such as Web
3390 Distributed Authoring and Versioning [WEBDAV], that are beyond the
3391 scope of this specification.
33938.8.1. Weak versus Strong
3395 Validators come in two flavors: strong or weak. Weak validators are
3396 easy to generate but are far less useful for comparisons. Strong
3397 validators are ideal for comparisons but can be very difficult (and
3398 occasionally impossible) to generate efficiently. Rather than impose
3399 that all forms of resource adhere to the same strength of validator,
3400 HTTP exposes the type of validator in use and imposes restrictions on
3401 when weak validators can be used as preconditions.
3403 A "strong validator" is representation metadata that changes value
3404 whenever a change occurs to the representation data that would be
3405 observable in the content of a 200 (OK) response to GET.
3407 A strong validator might change for reasons other than a change to
3408 the representation data, such as when a semantically significant part
3409 of the representation metadata is changed (e.g., Content-Type), but
3410 it is in the best interests of the origin server to only change the
3411 value when it is necessary to invalidate the stored responses held by
3412 remote caches and authoring tools.
3414 Cache entries might persist for arbitrarily long periods, regardless
3415 of expiration times. Thus, a cache might attempt to validate an
3416 entry using a validator that it obtained in the distant past. A
3417 strong validator is unique across all versions of all representations
3418 associated with a particular resource over time. However, there is
3419 no implication of uniqueness across representations of different
3420 resources (i.e., the same strong validator might be in use for
3421 representations of multiple resources at the same time and does not
3422 imply that those representations are equivalent).
3424 There are a variety of strong validators used in practice. The best
3425 are based on strict revision control, wherein each change to a
3426 representation always results in a unique node name and revision
3427 identifier being assigned before the representation is made
3428 accessible to GET. A collision-resistant hash function applied to
3429 the representation data is also sufficient if the data is available
3430 prior to the response header fields being sent and the digest does
3431 not need to be recalculated every time a validation request is
3432 received. However, if a resource has distinct representations that
3433 differ only in their metadata, such as might occur with content
3434 negotiation over media types that happen to share the same data
3435 format, then the origin server needs to incorporate additional
3436 information in the validator to distinguish those representations.
3438 In contrast, a "weak validator" is representation metadata that might
3439 not change for every change to the representation data. This
3440 weakness might be due to limitations in how the value is calculated
3441 (e.g., clock resolution), an inability to ensure uniqueness for all
3442 possible representations of the resource, or a desire of the resource
3443 owner to group representations by some self-determined set of
3444 equivalency rather than unique sequences of data.
3446 An origin server SHOULD change a weak entity tag whenever it
3447 considers prior representations to be unacceptable as a substitute
3448 for the current representation. In other words, a weak entity tag
3449 ought to change whenever the origin server wants caches to invalidate
3452 For example, the representation of a weather report that changes in
3453 content every second, based on dynamic measurements, might be grouped
3454 into sets of equivalent representations (from the origin server's
3455 perspective) with the same weak validator in order to allow cached
3456 representations to be valid for a reasonable period of time (perhaps
3457 adjusted dynamically based on server load or weather quality).
3458 Likewise, a representation's modification time, if defined with only
3459 one-second resolution, might be a weak validator if it is possible
3460 for the representation to be modified twice during a single second
3461 and retrieved between those modifications.
3463 Likewise, a validator is weak if it is shared by two or more
3464 representations of a given resource at the same time, unless those
3465 representations have identical representation data. For example, if
3466 the origin server sends the same validator for a representation with
3467 a gzip content coding applied as it does for a representation with no
3468 content coding, then that validator is weak. However, two
3469 simultaneous representations might share the same strong validator if
3470 they differ only in the representation metadata, such as when two
3471 different media types are available for the same representation data.
3473 Strong validators are usable for all conditional requests, including
3474 cache validation, partial content ranges, and "lost update"
3475 avoidance. Weak validators are only usable when the client does not
3476 require exact equality with previously obtained representation data,
3477 such as when validating a cache entry or limiting a web traversal to
3482 The "Last-Modified" header field in a response provides a timestamp
3483 indicating the date and time at which the origin server believes the
3484 selected representation was last modified, as determined at the
3485 conclusion of handling the request.
3487 Last-Modified = HTTP-date
3489 An example of its use is
3491 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
3495 An origin server SHOULD send Last-Modified for any selected
3496 representation for which a last modification date can be reasonably
3497 and consistently determined, since its use in conditional requests
3498 and evaluating cache freshness ([CACHING]) can substantially reduce
3499 unnecessary transfers and significantly improve service availability
3502 A representation is typically the sum of many parts behind the
3503 resource interface. The last-modified time would usually be the most
3504 recent time that any of those parts were changed. How that value is
3505 determined for any given resource is an implementation detail beyond
3506 the scope of this specification.
3508 An origin server SHOULD obtain the Last-Modified value of the
3509 representation as close as possible to the time that it generates the
3510 Date field value for its response. This allows a recipient to make
3511 an accurate assessment of the representation's modification time,
3512 especially if the representation changes near the time that the
3513 response is generated.
3515 An origin server with a clock (as defined in Section 5.6.7) MUST NOT
3516 generate a Last-Modified date that is later than the server's time of
3517 message origination (Date, Section 6.6.1). If the last modification
3518 time is derived from implementation-specific metadata that evaluates
3519 to some time in the future, according to the origin server's clock,
3520 then the origin server MUST replace that value with the message
3521 origination date. This prevents a future modification date from
3522 having an adverse impact on cache validation.
3524 An origin server without a clock MUST NOT generate a Last-Modified
3525 date for a response unless that date value was assigned to the
3526 resource by some other system (presumably one with a clock).
3530 A Last-Modified time, when used as a validator in a request, is
3531 implicitly weak unless it is possible to deduce that it is strong,
3532 using the following rules:
3534 * The validator is being compared by an origin server to the actual
3535 current validator for the representation and,
3537 * That origin server reliably knows that the associated
3538 representation did not change twice during the second covered by
3539 the presented validator;
3543 * The validator is about to be used by a client in an
3544 If-Modified-Since, If-Unmodified-Since, or If-Range header field,
3545 because the client has a cache entry for the associated
3548 * That cache entry includes a Date value which is at least one
3549 second after the Last-Modified value and the client has reason to
3550 believe that they were generated by the same clock or that there
3551 is enough difference between the Last-Modified and Date values to
3552 make clock synchronization issues unlikely;
3556 * The validator is being compared by an intermediate cache to the
3557 validator stored in its cache entry for the representation, and
3559 * That cache entry includes a Date value which is at least one
3560 second after the Last-Modified value and the cache has reason to
3561 believe that they were generated by the same clock or that there
3562 is enough difference between the Last-Modified and Date values to
3563 make clock synchronization issues unlikely.
3565 This method relies on the fact that if two different responses were
3566 sent by the origin server during the same second, but both had the
3567 same Last-Modified time, then at least one of those responses would
3568 have a Date value equal to its Last-Modified time.
3572 The "ETag" field in a response provides the current entity tag for
3573 the selected representation, as determined at the conclusion of
3574 handling the request. An entity tag is an opaque validator for
3575 differentiating between multiple representations of the same
3576 resource, regardless of whether those multiple representations are
3577 due to resource state changes over time, content negotiation
3578 resulting in multiple representations being valid at the same time,
3579 or both. An entity tag consists of an opaque quoted string, possibly
3580 prefixed by a weakness indicator.
3584 entity-tag = [ weak ] opaque-tag
3586 opaque-tag = DQUOTE *etagc DQUOTE
3587 etagc = %x21 / %x23-7E / obs-text
3588 ; VCHAR except double quotes, plus obs-text
3590 | *Note:* Previously, opaque-tag was defined to be a quoted-
3591 | string ([RFC2616], Section 3.11); thus, some recipients might
3592 | perform backslash unescaping. Servers therefore ought to avoid
3593 | backslash characters in entity tags.
3595 An entity tag can be more reliable for validation than a modification
3596 date in situations where it is inconvenient to store modification
3597 dates, where the one-second resolution of HTTP-date values is not
3598 sufficient, or where modification dates are not consistently
3607 An entity tag can be either a weak or strong validator, with strong
3608 being the default. If an origin server provides an entity tag for a
3609 representation and the generation of that entity tag does not satisfy
3610 all of the characteristics of a strong validator (Section 8.8.1),
3611 then the origin server MUST mark the entity tag as weak by prefixing
3612 its opaque value with "W/" (case-sensitive).
3614 A sender MAY send the ETag field in a trailer section (see
3615 Section 6.5). However, since trailers are often ignored, it is
3616 preferable to send ETag as a header field unless the entity tag is
3617 generated while sending the content.
3621 The principle behind entity tags is that only the service author
3622 knows the implementation of a resource well enough to select the most
3623 accurate and efficient validation mechanism for that resource, and
3624 that any such mechanism can be mapped to a simple sequence of octets
3625 for easy comparison. Since the value is opaque, there is no need for
3626 the client to be aware of how each entity tag is constructed.
3628 For example, a resource that has implementation-specific versioning
3629 applied to all changes might use an internal revision number, perhaps
3630 combined with a variance identifier for content negotiation, to
3631 accurately differentiate between representations. Other
3632 implementations might use a collision-resistant hash of
3633 representation content, a combination of various file attributes, or
3634 a modification timestamp that has sub-second resolution.
3636 An origin server SHOULD send an ETag for any selected representation
3637 for which detection of changes can be reasonably and consistently
3638 determined, since the entity tag's use in conditional requests and
3639 evaluating cache freshness ([CACHING]) can substantially reduce
3640 unnecessary transfers and significantly improve service availability,
3641 scalability, and reliability.
3645 There are two entity tag comparison functions, depending on whether
3646 or not the comparison context allows the use of weak validators:
3648 "Strong comparison": two entity tags are equivalent if both are not
3649 weak and their opaque-tags match character-by-character.
3651 "Weak comparison": two entity tags are equivalent if their opaque-
3652 tags match character-by-character, regardless of either or both
3653 being tagged as "weak".
3655 The example below shows the results for a set of entity tag pairs and
3656 both the weak and strong comparison function results:
3658 +========+========+===================+=================+
3659 | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
3660 +========+========+===================+=================+
3661 | W/"1" | W/"1" | no match | match |
3662 +--------+--------+-------------------+-----------------+
3663 | W/"1" | W/"2" | no match | no match |
3664 +--------+--------+-------------------+-----------------+
3665 | W/"1" | "1" | no match | match |
3666 +--------+--------+-------------------+-----------------+
3667 | "1" | "1" | match | match |
3668 +--------+--------+-------------------+-----------------+
36728.8.3.3. Example: Entity Tags Varying on Content-Negotiated Resources
3674 Consider a resource that is subject to content negotiation
3675 (Section 12), and where the representations sent in response to a GET
3676 request vary based on the Accept-Encoding request header field
3682 Host: www.example.com
3683 Accept-Encoding: gzip
3685 In this case, the response might or might not use the gzip content
3686 coding. If it does not, the response might look like:
3691 Date: Fri, 26 Mar 2010 00:05:00 GMT
3694 Vary: Accept-Encoding
3695 Content-Type: text/plain
3703 An alternative representation that does use gzip content coding would
3709 Date: Fri, 26 Mar 2010 00:05:00 GMT
3712 Vary: Accept-Encoding
3713 Content-Type: text/plain
3714 Content-Encoding: gzip
3718 | *Note:* Content codings are a property of the representation
3719 | data, so a strong entity tag for a content-encoded
3720 | representation has to be distinct from the entity tag of an
3721 | unencoded representation to prevent potential conflicts during
3722 | cache updates and range requests. In contrast, transfer
3723 | codings (Section 7 of [HTTP/1.1]) apply only during message
3724 | transfer and do not result in distinct entity tags.
3730 The request method token is the primary source of request semantics;
3731 it indicates the purpose for which the client has made this request
3732 and what is expected by the client as a successful result.
3734 The request method's semantics might be further specialized by the
3735 semantics of some header fields when present in a request if those
3736 additional semantics do not conflict with the method. For example, a
3737 client can send conditional request header fields (Section 13.1) to
3738 make the requested action conditional on the current state of the
3741 HTTP is designed to be usable as an interface to distributed object
3742 systems. The request method invokes an action to be applied to a
3743 target resource in much the same way that a remote method invocation
3744 can be sent to an identified object.
3748 The method token is case-sensitive because it might be used as a
3749 gateway to object-based systems with case-sensitive method names. By
3750 convention, standardized methods are defined in all-uppercase US-
3753 Unlike distributed objects, the standardized request methods in HTTP
3754 are not resource-specific, since uniform interfaces provide for
3755 better visibility and reuse in network-based systems [REST]. Once
3756 defined, a standardized method ought to have the same semantics when
3757 applied to any resource, though each resource determines for itself
3758 whether those semantics are implemented or allowed.
3760 This specification defines a number of standardized methods that are
3761 commonly used in HTTP, as outlined by the following table.
3763 +=========+============================================+=========+
3764 | Method | Description | Section |
3766 +=========+============================================+=========+
3767 | GET | Transfer a current representation of the | 9.3.1 |
3768 | | target resource. | |
3769 +---------+--------------------------------------------+---------+
3770 | HEAD | Same as GET, but do not transfer the | 9.3.2 |
3771 | | response content. | |
3772 +---------+--------------------------------------------+---------+
3773 | POST | Perform resource-specific processing on | 9.3.3 |
3774 | | the request content. | |
3775 +---------+--------------------------------------------+---------+
3776 | PUT | Replace all current representations of the | 9.3.4 |
3777 | | target resource with the request content. | |
3778 +---------+--------------------------------------------+---------+
3779 | DELETE | Remove all current representations of the | 9.3.5 |
3780 | | target resource. | |
3781 +---------+--------------------------------------------+---------+
3782 | CONNECT | Establish a tunnel to the server | 9.3.6 |
3783 | | identified by the target resource. | |
3784 +---------+--------------------------------------------+---------+
3785 | OPTIONS | Describe the communication options for the | 9.3.7 |
3786 | | target resource. | |
3787 +---------+--------------------------------------------+---------+
3788 | TRACE | Perform a message loop-back test along the | 9.3.8 |
3789 | | path to the target resource. | |
3790 +---------+--------------------------------------------+---------+
3794 All general-purpose servers MUST support the methods GET and HEAD.
3795 All other methods are OPTIONAL.
3797 The set of methods allowed by a target resource can be listed in an
3798 Allow header field (Section 10.2.1). However, the set of allowed
3799 methods can change dynamically. An origin server that receives a
3800 request method that is unrecognized or not implemented SHOULD respond
3801 with the 501 (Not Implemented) status code. An origin server that
3802 receives a request method that is recognized and implemented, but not
3803 allowed for the target resource, SHOULD respond with the 405 (Method
3804 Not Allowed) status code.
3806 Additional methods, outside the scope of this specification, have
3807 been specified for use in HTTP. All such methods ought to be
3808 registered within the "Hypertext Transfer Protocol (HTTP) Method
3809 Registry", as described in Section 16.1.
38119.2. Common Method Properties
3815 Request methods are considered "safe" if their defined semantics are
3816 essentially read-only; i.e., the client does not request, and does
3817 not expect, any state change on the origin server as a result of
3818 applying a safe method to a target resource. Likewise, reasonable
3819 use of a safe method is not expected to cause any harm, loss of
3820 property, or unusual burden on the origin server.
3822 This definition of safe methods does not prevent an implementation
3823 from including behavior that is potentially harmful, that is not
3824 entirely read-only, or that causes side effects while invoking a safe
3825 method. What is important, however, is that the client did not
3826 request that additional behavior and cannot be held accountable for
3827 it. For example, most servers append request information to access
3828 log files at the completion of every response, regardless of the
3829 method, and that is considered safe even though the log storage might
3830 become full and cause the server to fail. Likewise, a safe request
3831 initiated by selecting an advertisement on the Web will often have
3832 the side effect of charging an advertising account.
3834 Of the request methods defined by this specification, the GET, HEAD,
3835 OPTIONS, and TRACE methods are defined to be safe.
3837 The purpose of distinguishing between safe and unsafe methods is to
3838 allow automated retrieval processes (spiders) and cache performance
3839 optimization (pre-fetching) to work without fear of causing harm. In
3840 addition, it allows a user agent to apply appropriate constraints on
3841 the automated use of unsafe methods when processing potentially
3844 A user agent SHOULD distinguish between safe and unsafe methods when
3845 presenting potential actions to a user, such that the user can be
3846 made aware of an unsafe action before it is requested.
3848 When a resource is constructed such that parameters within the target
3849 URI have the effect of selecting an action, it is the resource
3850 owner's responsibility to ensure that the action is consistent with
3851 the request method semantics. For example, it is common for Web-
3852 based content editing software to use actions within query
3853 parameters, such as "page?do=delete". If the purpose of such a
3854 resource is to perform an unsafe action, then the resource owner MUST
3855 disable or disallow that action when it is accessed using a safe
3856 request method. Failure to do so will result in unfortunate side
3857 effects when automated processes perform a GET on every URI reference
3858 for the sake of link maintenance, pre-fetching, building a search
38619.2.2. Idempotent Methods
3863 A request method is considered "idempotent" if the intended effect on
3864 the server of multiple identical requests with that method is the
3865 same as the effect for a single such request. Of the request methods
3866 defined by this specification, PUT, DELETE, and safe request methods
3869 Like the definition of safe, the idempotent property only applies to
3870 what has been requested by the user; a server is free to log each
3871 request separately, retain a revision control history, or implement
3872 other non-idempotent side effects for each idempotent request.
3874 Idempotent methods are distinguished because the request can be
3875 repeated automatically if a communication failure occurs before the
3876 client is able to read the server's response. For example, if a
3877 client sends a PUT request and the underlying connection is closed
3878 before any response is received, then the client can establish a new
3879 connection and retry the idempotent request. It knows that repeating
3880 the request will have the same intended effect, even if the original
3881 request succeeded, though the response might differ.
3883 A client SHOULD NOT automatically retry a request with a non-
3884 idempotent method unless it has some means to know that the request
3885 semantics are actually idempotent, regardless of the method, or some
3886 means to detect that the original request was never applied.
3888 For example, a user agent can repeat a POST request automatically if
3889 it knows (through design or configuration) that the request is safe
3890 for that resource. Likewise, a user agent designed specifically to
3891 operate on a version control repository might be able to recover from
3892 partial failure conditions by checking the target resource
3893 revision(s) after a failed connection, reverting or fixing any
3894 changes that were partially applied, and then automatically retrying
3895 the requests that failed.
3897 Some clients take a riskier approach and attempt to guess when an
3898 automatic retry is possible. For example, a client might
3899 automatically retry a POST request if the underlying transport
3900 connection closed before any part of a response is received,
3901 particularly if an idle persistent connection was used.
3903 A proxy MUST NOT automatically retry non-idempotent requests. A
3904 client SHOULD NOT automatically retry a failed automatic retry.
39069.2.3. Methods and Caching
3908 For a cache to store and use a response, the associated method needs
3909 to explicitly allow caching and to detail under what conditions a
3910 response can be used to satisfy subsequent requests; a method
3911 definition that does not do so cannot be cached. For additional
3912 requirements see [CACHING].
3914 This specification defines caching semantics for GET, HEAD, and POST,
3915 although the overwhelming majority of cache implementations only
3916 support GET and HEAD.
39189.3. Method Definitions
3922 The GET method requests transfer of a current selected representation
3923 for the target resource. A successful response reflects the quality
3924 of "sameness" identified by the target URI (Section 1.2.2 of [URI]).
3925 Hence, retrieving identifiable information via HTTP is usually
3926 performed by making a GET request on an identifier associated with
3927 the potential for providing that information in a 200 (OK) response.
3929 GET is the primary mechanism of information retrieval and the focus
3930 of almost all performance optimizations. Applications that produce a
3931 URI for each important resource can benefit from those optimizations
3932 while enabling their reuse by other applications, creating a network
3933 effect that promotes further expansion of the Web.
3935 It is tempting to think of resource identifiers as remote file system
3936 pathnames and of representations as being a copy of the contents of
3937 such files. In fact, that is how many resources are implemented (see
3938 Section 17.3 for related security considerations). However, there
3939 are no such limitations in practice.
3941 The HTTP interface for a resource is just as likely to be implemented
3942 as a tree of content objects, a programmatic view on various database
3943 records, or a gateway to other information systems. Even when the
3944 URI mapping mechanism is tied to a file system, an origin server
3945 might be configured to execute the files with the request as input
3946 and send the output as the representation rather than transfer the
3947 files directly. Regardless, only the origin server needs to know how
3948 each resource identifier corresponds to an implementation and how
3949 that implementation manages to select and send a current
3950 representation of the target resource.
3952 A client can alter the semantics of GET to be a "range request",
3953 requesting transfer of only some part(s) of the selected
3954 representation, by sending a Range header field in the request
3957 Although request message framing is independent of the method used,
3958 content received in a GET request has no generally defined semantics,
3959 cannot alter the meaning or target of the request, and might lead
3960 some implementations to reject the request and close the connection
3961 because of its potential as a request smuggling attack (Section 11.2
3962 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET
3963 request unless it is made directly to an origin server that has
3964 previously indicated, in or out of band, that such a request has a
3965 purpose and will be adequately supported. An origin server SHOULD
3966 NOT rely on private agreements to receive content, since participants
3967 in HTTP communication are often unaware of intermediaries along the
3970 The response to a GET request is cacheable; a cache MAY use it to
3971 satisfy subsequent GET and HEAD requests unless otherwise indicated
3972 by the Cache-Control header field (Section 5.2 of [CACHING]).
3974 When information retrieval is performed with a mechanism that
3975 constructs a target URI from user-provided information, such as the
3976 query fields of a form using GET, potentially sensitive data might be
3977 provided that would not be appropriate for disclosure within a URI
3978 (see Section 17.9). In some cases, the data can be filtered or
3979 transformed such that it would not reveal such information. In
3980 others, particularly when there is no benefit from caching a
3981 response, using the POST method (Section 9.3.3) instead of GET can
3982 transmit such information in the request content rather than within
3987 The HEAD method is identical to GET except that the server MUST NOT
3988 send content in the response. HEAD is used to obtain metadata about
3989 the selected representation without transferring its representation
3990 data, often for the sake of testing hypertext links or finding recent
3993 The server SHOULD send the same header fields in response to a HEAD
3994 request as it would have sent if the request method had been GET.
3995 However, a server MAY omit header fields for which a value is
3996 determined only while generating the content. For example, some
3997 servers buffer a dynamic response to GET until a minimum amount of
3998 data is generated so that they can more efficiently delimit small
3999 responses or make late decisions with regard to content selection.
4000 Such a response to GET might contain Content-Length and Vary fields,
4001 for example, that are not generated within a HEAD response. These
4002 minor inconsistencies are considered preferable to generating and
4003 discarding the content for a HEAD request, since HEAD is usually
4004 requested for the sake of efficiency.
4006 Although request message framing is independent of the method used,
4007 content received in a HEAD request has no generally defined
4008 semantics, cannot alter the meaning or target of the request, and
4009 might lead some implementations to reject the request and close the
4010 connection because of its potential as a request smuggling attack
4011 (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content
4012 in a HEAD request unless it is made directly to an origin server that
4013 has previously indicated, in or out of band, that such a request has
4014 a purpose and will be adequately supported. An origin server SHOULD
4015 NOT rely on private agreements to receive content, since participants
4016 in HTTP communication are often unaware of intermediaries along the
4019 The response to a HEAD request is cacheable; a cache MAY use it to
4020 satisfy subsequent HEAD requests unless otherwise indicated by the
4021 Cache-Control header field (Section 5.2 of [CACHING]). A HEAD
4022 response might also affect previously cached responses to GET; see
4023 Section 4.3.5 of [CACHING].
4027 The POST method requests that the target resource process the
4028 representation enclosed in the request according to the resource's
4029 own specific semantics. For example, POST is used for the following
4030 functions (among others):
4032 * Providing a block of data, such as the fields entered into an HTML
4033 form, to a data-handling process;
4035 * Posting a message to a bulletin board, newsgroup, mailing list,
4036 blog, or similar group of articles;
4038 * Creating a new resource that has yet to be identified by the
4041 * Appending data to a resource's existing representation(s).
4043 An origin server indicates response semantics by choosing an
4044 appropriate status code depending on the result of processing the
4045 POST request; almost all of the status codes defined by this
4046 specification could be received in a response to POST (the exceptions
4047 being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
4050 If one or more resources has been created on the origin server as a
4051 result of successfully processing a POST request, the origin server
4052 SHOULD send a 201 (Created) response containing a Location header
4053 field that provides an identifier for the primary resource created
4054 (Section 10.2.2) and a representation that describes the status of
4055 the request while referring to the new resource(s).
4057 Responses to POST requests are only cacheable when they include
4058 explicit freshness information (see Section 4.2.1 of [CACHING]) and a
4059 Content-Location header field that has the same value as the POST's
4060 target URI (Section 8.7). A cached POST response can be reused to
4061 satisfy a later GET or HEAD request. In contrast, a POST request
4062 cannot be satisfied by a cached POST response because POST is
4063 potentially unsafe; see Section 4 of [CACHING].
4065 If the result of processing a POST would be equivalent to a
4066 representation of an existing resource, an origin server MAY redirect
4067 the user agent to that resource by sending a 303 (See Other) response
4068 with the existing resource's identifier in the Location field. This
4069 has the benefits of providing the user agent a resource identifier
4070 and transferring the representation via a method more amenable to
4071 shared caching, though at the cost of an extra request if the user
4072 agent does not already have the representation cached.
4076 The PUT method requests that the state of the target resource be
4077 created or replaced with the state defined by the representation
4078 enclosed in the request message content. A successful PUT of a given
4079 representation would suggest that a subsequent GET on that same
4080 target resource will result in an equivalent representation being
4081 sent in a 200 (OK) response. However, there is no guarantee that
4082 such a state change will be observable, since the target resource
4083 might be acted upon by other user agents in parallel, or might be
4084 subject to dynamic processing by the origin server, before any
4085 subsequent GET is received. A successful response only implies that
4086 the user agent's intent was achieved at the time of its processing by
4089 If the target resource does not have a current representation and the
4090 PUT successfully creates one, then the origin server MUST inform the
4091 user agent by sending a 201 (Created) response. If the target
4092 resource does have a current representation and that representation
4093 is successfully modified in accordance with the state of the enclosed
4094 representation, then the origin server MUST send either a 200 (OK) or
4095 a 204 (No Content) response to indicate successful completion of the
4098 An origin server SHOULD verify that the PUT representation is
4099 consistent with its configured constraints for the target resource.
4100 For example, if an origin server determines a resource's
4101 representation metadata based on the URI, then the origin server
4102 needs to ensure that the content received in a successful PUT request
4103 is consistent with that metadata. When a PUT representation is
4104 inconsistent with the target resource, the origin server SHOULD
4105 either make them consistent, by transforming the representation or
4106 changing the resource configuration, or respond with an appropriate
4107 error message containing sufficient information to explain why the
4108 representation is unsuitable. The 409 (Conflict) or 415 (Unsupported
4109 Media Type) status codes are suggested, with the latter being
4110 specific to constraints on Content-Type values.
4112 For example, if the target resource is configured to always have a
4113 Content-Type of "text/html" and the representation being PUT has a
4114 Content-Type of "image/jpeg", the origin server ought to do one of:
4116 a. reconfigure the target resource to reflect the new media type;
4118 b. transform the PUT representation to a format consistent with that
4119 of the resource before saving it as the new resource state; or,
4121 c. reject the request with a 415 (Unsupported Media Type) response
4122 indicating that the target resource is limited to "text/html",
4123 perhaps including a link to a different resource that would be a
4124 suitable target for the new representation.
4126 HTTP does not define exactly how a PUT method affects the state of an
4127 origin server beyond what can be expressed by the intent of the user
4128 agent request and the semantics of the origin server response. It
4129 does not define what a resource might be, in any sense of that word,
4130 beyond the interface provided via HTTP. It does not define how
4131 resource state is "stored", nor how such storage might change as a
4132 result of a change in resource state, nor how the origin server
4133 translates resource state into representations. Generally speaking,
4134 all implementation details behind the resource interface are
4135 intentionally hidden by the server.
4137 This extends to how header and trailer fields are stored; while
4138 common header fields like Content-Type will typically be stored and
4139 returned upon subsequent GET requests, header and trailer field
4140 handling is specific to the resource that received the request. As a
4141 result, an origin server SHOULD ignore unrecognized header and
4142 trailer fields received in a PUT request (i.e., not save them as part
4143 of the resource state).
4145 An origin server MUST NOT send a validator field (Section 8.8), such
4146 as an ETag or Last-Modified field, in a successful response to PUT
4147 unless the request's representation data was saved without any
4148 transformation applied to the content (i.e., the resource's new
4149 representation data is identical to the content received in the PUT
4150 request) and the validator field value reflects the new
4151 representation. This requirement allows a user agent to know when
4152 the representation it sent (and retains in memory) is the result of
4153 the PUT, and thus it doesn't need to be retrieved again from the
4154 origin server. The new validator(s) received in the response can be
4155 used for future conditional requests in order to prevent accidental
4156 overwrites (Section 13.1).
4158 The fundamental difference between the POST and PUT methods is
4159 highlighted by the different intent for the enclosed representation.
4160 The target resource in a POST request is intended to handle the
4161 enclosed representation according to the resource's own semantics,
4162 whereas the enclosed representation in a PUT request is defined as
4163 replacing the state of the target resource. Hence, the intent of PUT
4164 is idempotent and visible to intermediaries, even though the exact
4165 effect is only known by the origin server.
4167 Proper interpretation of a PUT request presumes that the user agent
4168 knows which target resource is desired. A service that selects a
4169 proper URI on behalf of the client, after receiving a state-changing
4170 request, SHOULD be implemented using the POST method rather than PUT.
4171 If the origin server will not make the requested PUT state change to
4172 the target resource and instead wishes to have it applied to a
4173 different resource, such as when the resource has been moved to a
4174 different URI, then the origin server MUST send an appropriate 3xx
4175 (Redirection) response; the user agent MAY then make its own decision
4176 regarding whether or not to redirect the request.
4178 A PUT request applied to the target resource can have side effects on
4179 other resources. For example, an article might have a URI for
4180 identifying "the current version" (a resource) that is separate from
4181 the URIs identifying each particular version (different resources
4182 that at one point shared the same state as the current version
4183 resource). A successful PUT request on "the current version" URI
4184 might therefore create a new version resource in addition to changing
4185 the state of the target resource, and might also cause links to be
4186 added between the related resources.
4188 Some origin servers support use of the Content-Range header field
4189 (Section 14.4) as a request modifier to perform a partial PUT, as
4190 described in Section 14.5.
4192 Responses to the PUT method are not cacheable. If a successful PUT
4193 request passes through a cache that has one or more stored responses
4194 for the target URI, those stored responses will be invalidated (see
4195 Section 4.4 of [CACHING]).
4199 The DELETE method requests that the origin server remove the
4200 association between the target resource and its current
4201 functionality. In effect, this method is similar to the "rm" command
4202 in UNIX: it expresses a deletion operation on the URI mapping of the
4203 origin server rather than an expectation that the previously
4204 associated information be deleted.
4206 If the target resource has one or more current representations, they
4207 might or might not be destroyed by the origin server, and the
4208 associated storage might or might not be reclaimed, depending
4209 entirely on the nature of the resource and its implementation by the
4210 origin server (which are beyond the scope of this specification).
4211 Likewise, other implementation aspects of a resource might need to be
4212 deactivated or archived as a result of a DELETE, such as database or
4213 gateway connections. In general, it is assumed that the origin
4214 server will only allow DELETE on resources for which it has a
4215 prescribed mechanism for accomplishing the deletion.
4217 Relatively few resources allow the DELETE method -- its primary use
4218 is for remote authoring environments, where the user has some
4219 direction regarding its effect. For example, a resource that was
4220 previously created using a PUT request, or identified via the
4221 Location header field after a 201 (Created) response to a POST
4222 request, might allow a corresponding DELETE request to undo those
4223 actions. Similarly, custom user agent implementations that implement
4224 an authoring function, such as revision control clients using HTTP
4225 for remote operations, might use DELETE based on an assumption that
4226 the server's URI space has been crafted to correspond to a version
4229 If a DELETE method is successfully applied, the origin server SHOULD
4232 * a 202 (Accepted) status code if the action will likely succeed but
4233 has not yet been enacted,
4235 * a 204 (No Content) status code if the action has been enacted and
4236 no further information is to be supplied, or
4238 * a 200 (OK) status code if the action has been enacted and the
4239 response message includes a representation describing the status.
4241 Although request message framing is independent of the method used,
4242 content received in a DELETE request has no generally defined
4243 semantics, cannot alter the meaning or target of the request, and
4244 might lead some implementations to reject the request and close the
4245 connection because of its potential as a request smuggling attack
4246 (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content
4247 in a DELETE request unless it is made directly to an origin server
4248 that has previously indicated, in or out of band, that such a request
4249 has a purpose and will be adequately supported. An origin server
4250 SHOULD NOT rely on private agreements to receive content, since
4251 participants in HTTP communication are often unaware of
4252 intermediaries along the request chain.
4254 Responses to the DELETE method are not cacheable. If a successful
4255 DELETE request passes through a cache that has one or more stored
4256 responses for the target URI, those stored responses will be
4257 invalidated (see Section 4.4 of [CACHING]).
4261 The CONNECT method requests that the recipient establish a tunnel to
4262 the destination origin server identified by the request target and,
4263 if successful, thereafter restrict its behavior to blind forwarding
4264 of data, in both directions, until the tunnel is closed. Tunnels are
4265 commonly used to create an end-to-end virtual connection, through one
4266 or more proxies, which can then be secured using TLS (Transport Layer
4269 CONNECT uses a special form of request target, unique to this method,
4270 consisting of only the host and port number of the tunnel
4271 destination, separated by a colon. There is no default port; a
4272 client MUST send the port number even if the CONNECT request is based
4273 on a URI reference that contains an authority component with an
4274 elided port (Section 4.1). For example,
4276 CONNECT server.example.com:80 HTTP/1.1
4277 Host: server.example.com
4279 A server MUST reject a CONNECT request that targets an empty or
4280 invalid port number, typically by responding with a 400 (Bad Request)
4283 Because CONNECT changes the request/response nature of an HTTP
4284 connection, specific HTTP versions might have different ways of
4285 mapping its semantics into the protocol's wire format.
4287 CONNECT is intended for use in requests to a proxy. The recipient
4288 can establish a tunnel either by directly connecting to the server
4289 identified by the request target or, if configured to use another
4290 proxy, by forwarding the CONNECT request to the next inbound proxy.
4291 An origin server MAY accept a CONNECT request, but most origin
4292 servers do not implement CONNECT.
4294 Any 2xx (Successful) response indicates that the sender (and all
4295 inbound proxies) will switch to tunnel mode immediately after the
4296 response header section; data received after that header section is
4297 from the server identified by the request target. Any response other
4298 than a successful response indicates that the tunnel has not yet been
4301 A tunnel is closed when a tunnel intermediary detects that either
4302 side has closed its connection: the intermediary MUST attempt to send
4303 any outstanding data that came from the closed side to the other
4304 side, close both connections, and then discard any remaining data
4307 Proxy authentication might be used to establish the authority to
4308 create a tunnel. For example,
4310 CONNECT server.example.com:443 HTTP/1.1
4311 Host: server.example.com:443
4312 Proxy-Authorization: basic aGVsbG86d29ybGQ=
4314 There are significant risks in establishing a tunnel to arbitrary
4315 servers, particularly when the destination is a well-known or
4316 reserved TCP port that is not intended for Web traffic. For example,
4317 a CONNECT to "example.com:25" would suggest that the proxy connect to
4318 the reserved port for SMTP traffic; if allowed, that could trick the
4319 proxy into relaying spam email. Proxies that support CONNECT SHOULD
4320 restrict its use to a limited set of known ports or a configurable
4321 list of safe request targets.
4323 A server MUST NOT send any Transfer-Encoding or Content-Length header
4324 fields in a 2xx (Successful) response to CONNECT. A client MUST
4325 ignore any Content-Length or Transfer-Encoding header fields received
4326 in a successful response to CONNECT.
4328 A CONNECT request message does not have content. The interpretation
4329 of data sent after the header section of the CONNECT request message
4330 is specific to the version of HTTP in use.
4332 Responses to the CONNECT method are not cacheable.
4336 The OPTIONS method requests information about the communication
4337 options available for the target resource, at either the origin
4338 server or an intervening intermediary. This method allows a client
4339 to determine the options and/or requirements associated with a
4340 resource, or the capabilities of a server, without implying a
4343 An OPTIONS request with an asterisk ("*") as the request target
4344 (Section 7.1) applies to the server in general rather than to a
4345 specific resource. Since a server's communication options typically
4346 depend on the resource, the "*" request is only useful as a "ping" or
4347 "no-op" type of method; it does nothing beyond allowing the client to
4348 test the capabilities of the server. For example, this can be used
4349 to test a proxy for HTTP/1.1 conformance (or lack thereof).
4351 If the request target is not an asterisk, the OPTIONS request applies
4352 to the options that are available when communicating with the target
4355 A server generating a successful response to OPTIONS SHOULD send any
4356 header that might indicate optional features implemented by the
4357 server and applicable to the target resource (e.g., Allow), including
4358 potential extensions not defined by this specification. The response
4359 content, if any, might also describe the communication options in a
4360 machine or human-readable representation. A standard format for such
4361 a representation is not defined by this specification, but might be
4362 defined by future extensions to HTTP.
4364 A client MAY send a Max-Forwards header field in an OPTIONS request
4365 to target a specific recipient in the request chain (see
4366 Section 7.6.2). A proxy MUST NOT generate a Max-Forwards header
4367 field while forwarding a request unless that request was received
4368 with a Max-Forwards field.
4370 A client that generates an OPTIONS request containing content MUST
4371 send a valid Content-Type header field describing the representation
4372 media type. Note that this specification does not define any use for
4375 Responses to the OPTIONS method are not cacheable.
4379 The TRACE method requests a remote, application-level loop-back of
4380 the request message. The final recipient of the request SHOULD
4381 reflect the message received, excluding some fields described below,
4382 back to the client as the content of a 200 (OK) response. The
4383 "message/http" format (Section 10.1 of [HTTP/1.1]) is one way to do
4384 so. The final recipient is either the origin server or the first
4385 server to receive a Max-Forwards value of zero (0) in the request
4388 A client MUST NOT generate fields in a TRACE request containing
4389 sensitive data that might be disclosed by the response. For example,
4390 it would be foolish for a user agent to send stored user credentials
4391 (Section 11) or cookies [COOKIE] in a TRACE request. The final
4392 recipient of the request SHOULD exclude any request fields that are
4393 likely to contain sensitive data when that recipient generates the
4396 TRACE allows the client to see what is being received at the other
4397 end of the request chain and use that data for testing or diagnostic
4398 information. The value of the Via header field (Section 7.6.3) is of
4399 particular interest, since it acts as a trace of the request chain.
4400 Use of the Max-Forwards header field allows the client to limit the
4401 length of the request chain, which is useful for testing a chain of
4402 proxies forwarding messages in an infinite loop.
4404 A client MUST NOT send content in a TRACE request.
4406 Responses to the TRACE method are not cacheable.
441010.1. Request Context Fields
4412 The request header fields below provide additional information about
4413 the request context, including information about the user, user
4414 agent, and resource behind the request.
4418 The "Expect" header field in a request indicates a certain set of
4419 behaviors (expectations) that need to be supported by the server in
4420 order to properly handle this request.
4422 Expect = #expectation
4423 expectation = token [ "=" ( token / quoted-string ) parameters ]
4425 The Expect field value is case-insensitive.
4427 The only expectation defined by this specification is "100-continue"
4428 (with no defined parameters).
4430 A server that receives an Expect field value containing a member
4431 other than 100-continue MAY respond with a 417 (Expectation Failed)
4432 status code to indicate that the unexpected expectation cannot be
4435 A "100-continue" expectation informs recipients that the client is
4436 about to send (presumably large) content in this request and wishes
4437 to receive a 100 (Continue) interim response if the method, target
4438 URI, and header fields are not sufficient to cause an immediate
4439 success, redirect, or error response. This allows the client to wait
4440 for an indication that it is worthwhile to send the content before
4441 actually doing so, which can improve efficiency when the data is huge
4442 or when the client anticipates that an error is likely (e.g., when
4443 sending a state-changing method, for the first time, without
4444 previously verified authentication credentials).
4446 For example, a request that begins with
4448 PUT /somewhere/fun HTTP/1.1
4449 Host: origin.example.com
4450 Content-Type: video/h264
4451 Content-Length: 1234567890987
4452 Expect: 100-continue
4454 allows the origin server to immediately respond with an error
4455 message, such as 401 (Unauthorized) or 405 (Method Not Allowed),
4456 before the client starts filling the pipes with an unnecessary data
4459 Requirements for clients:
4461 * A client MUST NOT generate a 100-continue expectation in a request
4462 that does not include content.
4464 * A client that will wait for a 100 (Continue) response before
4465 sending the request content MUST send an Expect header field
4466 containing a 100-continue expectation.
4468 * A client that sends a 100-continue expectation is not required to
4469 wait for any specific length of time; such a client MAY proceed to
4470 send the content even if it has not yet received a response.
4471 Furthermore, since 100 (Continue) responses cannot be sent through
4472 an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
4473 indefinite period before sending the content.
4475 * A client that receives a 417 (Expectation Failed) status code in
4476 response to a request containing a 100-continue expectation SHOULD
4477 repeat that request without a 100-continue expectation, since the
4478 417 response merely indicates that the response chain does not
4479 support expectations (e.g., it passes through an HTTP/1.0 server).
4481 Requirements for servers:
4483 * A server that receives a 100-continue expectation in an HTTP/1.0
4484 request MUST ignore that expectation.
4486 * A server MAY omit sending a 100 (Continue) response if it has
4487 already received some or all of the content for the corresponding
4488 request, or if the framing indicates that there is no content.
4490 * A server that sends a 100 (Continue) response MUST ultimately send
4491 a final status code, once it receives and processes the request
4492 content, unless the connection is closed prematurely.
4494 * A server that responds with a final status code before reading the
4495 entire request content SHOULD indicate whether it intends to close
4496 the connection (e.g., see Section 9.6 of [HTTP/1.1]) or continue
4497 reading the request content.
4499 Upon receiving an HTTP/1.1 (or later) request that has a method,
4500 target URI, and complete header section that contains a 100-continue
4501 expectation and an indication that request content will follow, an
4502 origin server MUST send either:
4504 * an immediate response with a final status code, if that status can
4505 be determined by examining just the method, target URI, and header
4508 * an immediate 100 (Continue) response to encourage the client to
4509 send the request content.
4511 The origin server MUST NOT wait for the content before sending the
4512 100 (Continue) response.
4514 Upon receiving an HTTP/1.1 (or later) request that has a method,
4515 target URI, and complete header section that contains a 100-continue
4516 expectation and indicates a request content will follow, a proxy MUST
4519 * send an immediate response with a final status code, if that
4520 status can be determined by examining just the method, target URI,
4521 and header fields, or
4523 * forward the request toward the origin server by sending a
4524 corresponding request-line and header section to the next inbound
4527 If the proxy believes (from configuration or past interaction) that
4528 the next inbound server only supports HTTP/1.0, the proxy MAY
4529 generate an immediate 100 (Continue) response to encourage the client
4530 to begin sending the content.
4534 The "From" header field contains an Internet email address for a
4535 human user who controls the requesting user agent. The address ought
4536 to be machine-usable, as defined by "mailbox" in Section 3.4 of
4541 mailbox = <mailbox, see [RFC5322], Section 3.4>
4545 From: spider-admin@example.org
4547 The From header field is rarely sent by non-robotic user agents. A
4548 user agent SHOULD NOT send a From header field without explicit
4549 configuration by the user, since that might conflict with the user's
4550 privacy interests or their site's security policy.
4552 A robotic user agent SHOULD send a valid From header field so that
4553 the person responsible for running the robot can be contacted if
4554 problems occur on servers, such as if the robot is sending excessive,
4555 unwanted, or invalid requests.
4557 A server SHOULD NOT use the From header field for access control or
4558 authentication, since its value is expected to be visible to anyone
4559 receiving or observing the request and is often recorded within
4560 logfiles and error reports without any expectation of privacy.
4564 The "Referer" [sic] header field allows the user agent to specify a
4565 URI reference for the resource from which the target URI was obtained
4566 (i.e., the "referrer", though the field name is misspelled). A user
4567 agent MUST NOT include the fragment and userinfo components of the
4568 URI reference [URI], if any, when generating the Referer field value.
4570 Referer = absolute-URI / partial-URI
4572 The field value is either an absolute-URI or a partial-URI. In the
4573 latter case (Section 4), the referenced URI is relative to the target
4574 URI ([URI], Section 5).
4576 The Referer header field allows servers to generate back-links to
4577 other resources for simple analytics, logging, optimized caching,
4578 etc. It also allows obsolete or mistyped links to be found for
4579 maintenance. Some servers use the Referer header field as a means of
4580 denying links from other sites (so-called "deep linking") or
4581 restricting cross-site request forgery (CSRF), but not all requests
4586 Referer: http://www.example.org/hypertext/Overview.html
4588 If the target URI was obtained from a source that does not have its
4589 own URI (e.g., input from the user keyboard, or an entry within the
4590 user's bookmarks/favorites), the user agent MUST either exclude the
4591 Referer header field or send it with a value of "about:blank".
4593 The Referer header field value need not convey the full URI of the
4594 referring resource; a user agent MAY truncate parts other than the
4597 The Referer header field has the potential to reveal information
4598 about the request context or browsing history of the user, which is a
4599 privacy concern if the referring resource's identifier reveals
4600 personal information (such as an account name) or a resource that is
4601 supposed to be confidential (such as behind a firewall or internal to
4602 a secured service). Most general-purpose user agents do not send the
4603 Referer header field when the referring resource is a local "file" or
4604 "data" URI. A user agent SHOULD NOT send a Referer header field if
4605 the referring resource was accessed with a secure protocol and the
4606 request target has an origin differing from that of the referring
4607 resource, unless the referring resource explicitly allows Referer to
4608 be sent. A user agent MUST NOT send a Referer header field in an
4609 unsecured HTTP request if the referring resource was accessed with a
4610 secure protocol. See Section 17.9 for additional security
4613 Some intermediaries have been known to indiscriminately remove
4614 Referer header fields from outgoing requests. This has the
4615 unfortunate side effect of interfering with protection against CSRF
4616 attacks, which can be far more harmful to their users.
4617 Intermediaries and user agent extensions that wish to limit
4618 information disclosure in Referer ought to restrict their changes to
4619 specific edits, such as replacing internal domain names with
4620 pseudonyms or truncating the query and/or path components. An
4621 intermediary SHOULD NOT modify or delete the Referer header field
4622 when the field value shares the same scheme and host as the target
4627 The "TE" header field describes capabilities of the client with
4628 regard to transfer codings and trailer sections.
4630 As described in Section 6.5, a TE field with a "trailers" member sent
4631 in a request indicates that the client will not discard trailer
4634 TE is also used within HTTP/1.1 to advise servers about which
4635 transfer codings the client is able to accept in a response. As of
4636 publication, only HTTP/1.1 uses transfer codings (see Section 7 of
4639 The TE field value is a list of members, with each member (aside from
4640 "trailers") consisting of a transfer coding name token with an
4641 optional weight indicating the client's relative preference for that
4642 transfer coding (Section 12.4.2) and optional parameters for that
4646 t-codings = "trailers" / ( transfer-coding [ weight ] )
4647 transfer-coding = token *( OWS ";" OWS transfer-parameter )
4648 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
4650 A sender of TE MUST also send a "TE" connection option within the
4651 Connection header field (Section 7.6.1) to inform intermediaries not
4652 to forward this field.
4656 The "User-Agent" header field contains information about the user
4657 agent originating the request, which is often used by servers to help
4658 identify the scope of reported interoperability problems, to work
4659 around or tailor responses to avoid particular user agent
4660 limitations, and for analytics regarding browser or operating system
4661 use. A user agent SHOULD send a User-Agent header field in each
4662 request unless specifically configured not to do so.
4664 User-Agent = product *( RWS ( product / comment ) )
4666 The User-Agent field value consists of one or more product
4667 identifiers, each followed by zero or more comments (Section 5.6.5),
4668 which together identify the user agent software and its significant
4669 subproducts. By convention, the product identifiers are listed in
4670 decreasing order of their significance for identifying the user agent
4671 software. Each product identifier consists of a name and optional
4674 product = token ["/" product-version]
4675 product-version = token
4677 A sender SHOULD limit generated product identifiers to what is
4678 necessary to identify the product; a sender MUST NOT generate
4679 advertising or other nonessential information within the product
4680 identifier. A sender SHOULD NOT generate information in
4681 product-version that is not a version identifier (i.e., successive
4682 versions of the same product name ought to differ only in the
4683 product-version portion of the product identifier).
4687 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
4689 A user agent SHOULD NOT generate a User-Agent header field containing
4690 needlessly fine-grained detail and SHOULD limit the addition of
4691 subproducts by third parties. Overly long and detailed User-Agent
4692 field values increase request latency and the risk of a user being
4693 identified against their wishes ("fingerprinting").
4695 Likewise, implementations are encouraged not to use the product
4696 tokens of other implementations in order to declare compatibility
4697 with them, as this circumvents the purpose of the field. If a user
4698 agent masquerades as a different user agent, recipients can assume
4699 that the user intentionally desires to see responses tailored for
4700 that identified user agent, even if they might not work as well for
4701 the actual user agent being used.
470310.2. Response Context Fields
4705 The response header fields below provide additional information about
4706 the response, beyond what is implied by the status code, including
4707 information about the server, about the target resource, or about
4712 The "Allow" header field lists the set of methods advertised as
4713 supported by the target resource. The purpose of this field is
4714 strictly to inform the recipient of valid request methods associated
4721 Allow: GET, HEAD, PUT
4723 The actual set of allowed methods is defined by the origin server at
4724 the time of each request. An origin server MUST generate an Allow
4725 header field in a 405 (Method Not Allowed) response and MAY do so in
4726 any other response. An empty Allow field value indicates that the
4727 resource allows no methods, which might occur in a 405 response if
4728 the resource has been temporarily disabled by configuration.
4730 A proxy MUST NOT modify the Allow header field -- it does not need to
4731 understand all of the indicated methods in order to handle them
4732 according to the generic message handling rules.
4736 The "Location" header field is used in some responses to refer to a
4737 specific resource in relation to the response. The type of
4738 relationship is defined by the combination of request method and
4739 status code semantics.
4741 Location = URI-reference
4743 The field value consists of a single URI-reference. When it has the
4744 form of a relative reference ([URI], Section 4.2), the final value is
4745 computed by resolving it against the target URI ([URI], Section 5).
4747 For 201 (Created) responses, the Location value refers to the primary
4748 resource created by the request. For 3xx (Redirection) responses,
4749 the Location value refers to the preferred target resource for
4750 automatically redirecting the request.
4752 If the Location value provided in a 3xx (Redirection) response does
4753 not have a fragment component, a user agent MUST process the
4754 redirection as if the value inherits the fragment component of the
4755 URI reference used to generate the target URI (i.e., the redirection
4756 inherits the original reference's fragment, if any).
4758 For example, a GET request generated for the URI reference
4759 "http://www.example.org/~tim" might result in a 303 (See Other)
4760 response containing the header field:
4762 Location: /People.html#tim
4764 which suggests that the user agent redirect to
4765 "http://www.example.org/People.html#tim"
4767 Likewise, a GET request generated for the URI reference
4768 "http://www.example.org/index.html#larry" might result in a 301
4769 (Moved Permanently) response containing the header field:
4771 Location: http://www.example.net/index.html
4773 which suggests that the user agent redirect to
4774 "http://www.example.net/index.html#larry", preserving the original
4775 fragment identifier.
4777 There are circumstances in which a fragment identifier in a Location
4778 value would not be appropriate. For example, the Location header
4779 field in a 201 (Created) response is supposed to provide a URI that
4780 is specific to the created resource.
4782 | *Note:* Some recipients attempt to recover from Location header
4783 | fields that are not valid URI references. This specification
4784 | does not mandate or define such processing, but does allow it
4785 | for the sake of robustness. A Location field value cannot
4786 | allow a list of members because the comma list separator is a
4787 | valid data character within a URI-reference. If an invalid
4788 | message is sent with multiple Location field lines, a recipient
4789 | along the path might combine those field lines into one value.
4790 | Recovery of a valid Location field value from that situation is
4791 | difficult and not interoperable across implementations.
4793 | *Note:* The Content-Location header field (Section 8.7) differs
4794 | from Location in that the Content-Location refers to the most
4795 | specific resource corresponding to the enclosed representation.
4796 | It is therefore possible for a response to contain both the
4797 | Location and Content-Location header fields.
4801 Servers send the "Retry-After" header field to indicate how long the
4802 user agent ought to wait before making a follow-up request. When
4803 sent with a 503 (Service Unavailable) response, Retry-After indicates
4804 how long the service is expected to be unavailable to the client.
4805 When sent with any 3xx (Redirection) response, Retry-After indicates
4806 the minimum time that the user agent is asked to wait before issuing
4807 the redirected request.
4809 The Retry-After field value can be either an HTTP-date or a number of
4810 seconds to delay after receiving the response.
4812 Retry-After = HTTP-date / delay-seconds
4814 A delay-seconds value is a non-negative decimal integer, representing
4817 delay-seconds = 1*DIGIT
4819 Two examples of its use are
4821 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
4824 In the latter example, the delay is 2 minutes.
4828 The "Server" header field contains information about the software
4829 used by the origin server to handle the request, which is often used
4830 by clients to help identify the scope of reported interoperability
4831 problems, to work around or tailor requests to avoid particular
4832 server limitations, and for analytics regarding server or operating
4833 system use. An origin server MAY generate a Server header field in
4836 Server = product *( RWS ( product / comment ) )
4838 The Server header field value consists of one or more product
4839 identifiers, each followed by zero or more comments (Section 5.6.5),
4840 which together identify the origin server software and its
4841 significant subproducts. By convention, the product identifiers are
4842 listed in decreasing order of their significance for identifying the
4843 origin server software. Each product identifier consists of a name
4844 and optional version, as defined in Section 10.1.5.
4848 Server: CERN/3.0 libwww/2.17
4850 An origin server SHOULD NOT generate a Server header field containing
4851 needlessly fine-grained detail and SHOULD limit the addition of
4852 subproducts by third parties. Overly long and detailed Server field
4853 values increase response latency and potentially reveal internal
4854 implementation details that might make it (slightly) easier for
4855 attackers to find and exploit known security holes.
485711. HTTP Authentication
485911.1. Authentication Scheme
4861 HTTP provides a general framework for access control and
4862 authentication, via an extensible set of challenge-response
4863 authentication schemes, which can be used by a server to challenge a
4864 client request and by a client to provide authentication information.
4865 It uses a case-insensitive token to identify the authentication
4870 Aside from the general framework, this document does not specify any
4871 authentication schemes. New and existing authentication schemes are
4872 specified independently and ought to be registered within the
4873 "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry".
4874 For example, the "basic" and "digest" authentication schemes are
4875 defined by [RFC7617] and [RFC7616], respectively.
487711.2. Authentication Parameters
4879 The authentication scheme is followed by additional information
4880 necessary for achieving authentication via that scheme as either a
4881 comma-separated list of parameters or a single sequence of characters
4882 capable of holding base64-encoded information.
4884 token68 = 1*( ALPHA / DIGIT /
4885 "-" / "." / "_" / "~" / "+" / "/" ) *"="
4887 The token68 syntax allows the 66 unreserved URI characters ([URI]),
4888 plus a few others, so that it can hold a base64, base64url (URL and
4889 filename safe alphabet), base32, or base16 (hex) encoding, with or
4890 without padding, but excluding whitespace ([RFC4648]).
4892 Authentication parameters are name/value pairs, where the name token
4893 is matched case-insensitively and each parameter name MUST only occur
4896 auth-param = token BWS "=" BWS ( token / quoted-string )
4898 Parameter values can be expressed either as "token" or as "quoted-
4899 string" (Section 5.6). Authentication scheme definitions need to
4900 accept both notations, both for senders and recipients, to allow
4901 recipients to use generic parsing components regardless of the
4902 authentication scheme.
4904 For backwards compatibility, authentication scheme definitions can
4905 restrict the format for senders to one of the two variants. This can
4906 be important when it is known that deployed implementations will fail
4907 when encountering one of the two formats.
490911.3. Challenge and Response
4911 A 401 (Unauthorized) response message is used by an origin server to
4912 challenge the authorization of a user agent, including a
4913 WWW-Authenticate header field containing at least one challenge
4914 applicable to the requested resource.
4916 A 407 (Proxy Authentication Required) response message is used by a
4917 proxy to challenge the authorization of a client, including a
4918 Proxy-Authenticate header field containing at least one challenge
4919 applicable to the proxy for the requested resource.
4921 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
4923 | *Note:* Many clients fail to parse a challenge that contains an
4924 | unknown scheme. A workaround for this problem is to list well-
4925 | supported schemes (such as "basic") first.
4927 A user agent that wishes to authenticate itself with an origin server
4928 -- usually, but not necessarily, after receiving a 401 (Unauthorized)
4929 -- can do so by including an Authorization header field with the
4932 A client that wishes to authenticate itself with a proxy -- usually,
4933 but not necessarily, after receiving a 407 (Proxy Authentication
4934 Required) -- can do so by including a Proxy-Authorization header
4935 field with the request.
4939 Both the Authorization field value and the Proxy-Authorization field
4940 value contain the client's credentials for the realm of the resource
4941 being requested, based upon a challenge received in a response
4942 (possibly at some point in the past). When creating their values,
4943 the user agent ought to do so by selecting the challenge with what it
4944 considers to be the most secure auth-scheme that it understands,
4945 obtaining credentials from the user as appropriate. Transmission of
4946 credentials within header field values implies significant security
4947 considerations regarding the confidentiality of the underlying
4948 connection, as described in Section 17.16.1.
4950 credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
4952 Upon receipt of a request for a protected resource that omits
4953 credentials, contains invalid credentials (e.g., a bad password) or
4954 partial credentials (e.g., when the authentication scheme requires
4955 more than one round trip), an origin server SHOULD send a 401
4956 (Unauthorized) response that contains a WWW-Authenticate header field
4957 with at least one (possibly new) challenge applicable to the
4960 Likewise, upon receipt of a request that omits proxy credentials or
4961 contains invalid or partial proxy credentials, a proxy that requires
4962 authentication SHOULD generate a 407 (Proxy Authentication Required)
4963 response that contains a Proxy-Authenticate header field with at
4964 least one (possibly new) challenge applicable to the proxy.
4966 A server that receives valid credentials that are not adequate to
4967 gain access ought to respond with the 403 (Forbidden) status code
4970 HTTP does not restrict applications to this simple challenge-response
4971 framework for access authentication. Additional mechanisms can be
4972 used, such as authentication at the transport level or via message
4973 encapsulation, and with additional header fields specifying
4974 authentication information. However, such additional mechanisms are
4975 not defined by this specification.
4977 Note that various custom mechanisms for user authentication use the
4978 Set-Cookie and Cookie header fields, defined in [COOKIE], for passing
4979 tokens related to authentication.
498111.5. Establishing a Protection Space (Realm)
4983 The "realm" authentication parameter is reserved for use by
4984 authentication schemes that wish to indicate a scope of protection.
4986 A "protection space" is defined by the origin (see Section 4.3.1) of
4987 the server being accessed, in combination with the realm value if
4988 present. These realms allow the protected resources on a server to
4989 be partitioned into a set of protection spaces, each with its own
4990 authentication scheme and/or authorization database. The realm value
4991 is a string, generally assigned by the origin server, that can have
4992 additional semantics specific to the authentication scheme. Note
4993 that a response can have multiple challenges with the same auth-
4994 scheme but with different realms.
4996 The protection space determines the domain over which credentials can
4997 be automatically applied. If a prior request has been authorized,
4998 the user agent MAY reuse the same credentials for all other requests
4999 within that protection space for a period of time determined by the
5000 authentication scheme, parameters, and/or user preferences (such as a
5001 configurable inactivity timeout).
5003 The extent of a protection space, and therefore the requests to which
5004 credentials might be automatically applied, is not necessarily known
5005 to clients without additional information. An authentication scheme
5006 might define parameters that describe the extent of a protection
5007 space. Unless specifically allowed by the authentication scheme, a
5008 single protection space cannot extend outside the scope of its
5011 For historical reasons, a sender MUST only generate the quoted-string
5012 syntax. Recipients might have to support both token and quoted-
5013 string syntax for maximum interoperability with existing clients that
5014 have been accepting both notations for a long time.
501611.6. Authenticating Users to Origin Servers
501811.6.1. WWW-Authenticate
5020 The "WWW-Authenticate" response header field indicates the
5021 authentication scheme(s) and parameters applicable to the target
5024 WWW-Authenticate = #challenge
5026 A server generating a 401 (Unauthorized) response MUST send a WWW-
5027 Authenticate header field containing at least one challenge. A
5028 server MAY generate a WWW-Authenticate header field in other response
5029 messages to indicate that supplying credentials (or different
5030 credentials) might affect the response.
5032 A proxy forwarding a response MUST NOT modify any WWW-Authenticate
5033 header fields in that response.
5035 User agents are advised to take special care in parsing the field
5036 value, as it might contain more than one challenge, and each
5037 challenge can contain a comma-separated list of authentication
5038 parameters. Furthermore, the header field itself can occur multiple
5043 WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
5044 type=1, title="Login to \"apps\""
5046 This header field contains two challenges, one for the "Basic" scheme
5047 with a realm value of "simple" and another for the "Newauth" scheme
5048 with a realm value of "apps". It also contains two additional
5049 parameters, "type" and "title".
5051 Some user agents do not recognize this form, however. As a result,
5052 sending a WWW-Authenticate field value with more than one member on
5053 the same field line might not be interoperable.
5055 | *Note:* The challenge grammar production uses the list syntax
5056 | as well. Therefore, a sequence of comma, whitespace, and comma
5057 | can be considered either as applying to the preceding
5058 | challenge, or to be an empty entry in the list of challenges.
5059 | In practice, this ambiguity does not affect the semantics of
5060 | the header field value and thus is harmless.
506211.6.2. Authorization
5064 The "Authorization" header field allows a user agent to authenticate
5065 itself with an origin server -- usually, but not necessarily, after
5066 receiving a 401 (Unauthorized) response. Its value consists of
5067 credentials containing the authentication information of the user
5068 agent for the realm of the resource being requested.
5070 Authorization = credentials
5072 If a request is authenticated and a realm specified, the same
5073 credentials are presumed to be valid for all other requests within
5074 this realm (assuming that the authentication scheme itself does not
5075 require otherwise, such as credentials that vary according to a
5076 challenge value or using synchronized clocks).
5078 A proxy forwarding a request MUST NOT modify any Authorization header
5079 fields in that request. See Section 3.5 of [CACHING] for details of
5080 and requirements pertaining to handling of the Authorization header
5081 field by HTTP caches.
508311.6.3. Authentication-Info
5085 HTTP authentication schemes can use the "Authentication-Info"
5086 response field to communicate information after the client's
5087 authentication credentials have been accepted. This information can
5088 include a finalization message from the server (e.g., it can contain
5089 the server authentication).
5091 The field value is a list of parameters (name/value pairs), using the
5092 "auth-param" syntax defined in Section 11.3. This specification only
5093 describes the generic format; authentication schemes using
5094 Authentication-Info will define the individual parameters. The
5095 "Digest" Authentication Scheme, for instance, defines multiple
5096 parameters in Section 3.5 of [RFC7616].
5098 Authentication-Info = #auth-param
5100 The Authentication-Info field can be used in any HTTP response,
5101 independently of request method and status code. Its semantics are
5102 defined by the authentication scheme indicated by the Authorization
5103 header field (Section 11.6.2) of the corresponding request.
5105 A proxy forwarding a response is not allowed to modify the field
5108 Authentication-Info can be sent as a trailer field (Section 6.5) when
5109 the authentication scheme explicitly allows this.
511111.7. Authenticating Clients to Proxies
511311.7.1. Proxy-Authenticate
5115 The "Proxy-Authenticate" header field consists of at least one
5116 challenge that indicates the authentication scheme(s) and parameters
5117 applicable to the proxy for this request. A proxy MUST send at least
5118 one Proxy-Authenticate header field in each 407 (Proxy Authentication
5119 Required) response that it generates.
5121 Proxy-Authenticate = #challenge
5123 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
5124 only to the next outbound client on the response chain. This is
5125 because only the client that chose a given proxy is likely to have
5126 the credentials necessary for authentication. However, when multiple
5127 proxies are used within the same administrative domain, such as
5128 office and regional caching proxies within a large corporate network,
5129 it is common for credentials to be generated by the user agent and
5130 passed through the hierarchy until consumed. Hence, in such a
5131 configuration, it will appear as if Proxy-Authenticate is being
5132 forwarded because each proxy will send the same challenge set.
5134 Note that the parsing considerations for WWW-Authenticate apply to
5135 this header field as well; see Section 11.6.1 for details.
513711.7.2. Proxy-Authorization
5139 The "Proxy-Authorization" header field allows the client to identify
5140 itself (or its user) to a proxy that requires authentication. Its
5141 value consists of credentials containing the authentication
5142 information of the client for the proxy and/or realm of the resource
5145 Proxy-Authorization = credentials
5147 Unlike Authorization, the Proxy-Authorization header field applies
5148 only to the next inbound proxy that demanded authentication using the
5149 Proxy-Authenticate header field. When multiple proxies are used in a
5150 chain, the Proxy-Authorization header field is consumed by the first
5151 inbound proxy that was expecting to receive credentials. A proxy MAY
5152 relay the credentials from the client request to the next proxy if
5153 that is the mechanism by which the proxies cooperatively authenticate
515611.7.3. Proxy-Authentication-Info
5158 The "Proxy-Authentication-Info" response header field is equivalent
5159 to Authentication-Info, except that it applies to proxy
5160 authentication (Section 11.3) and its semantics are defined by the
5161 authentication scheme indicated by the Proxy-Authorization header
5162 field (Section 11.7.2) of the corresponding request:
5164 Proxy-Authentication-Info = #auth-param
5166 However, unlike Authentication-Info, the Proxy-Authentication-Info
5167 header field applies only to the next outbound client on the response
5168 chain. This is because only the client that chose a given proxy is
5169 likely to have the credentials necessary for authentication.
5170 However, when multiple proxies are used within the same
5171 administrative domain, such as office and regional caching proxies
5172 within a large corporate network, it is common for credentials to be
5173 generated by the user agent and passed through the hierarchy until
5174 consumed. Hence, in such a configuration, it will appear as if
5175 Proxy-Authentication-Info is being forwarded because each proxy will
5176 send the same field value.
5178 Proxy-Authentication-Info can be sent as a trailer field
5179 (Section 6.5) when the authentication scheme explicitly allows this.
518112. Content Negotiation
5183 When responses convey content, whether indicating a success or an
5184 error, the origin server often has different ways of representing
5185 that information; for example, in different formats, languages, or
5186 encodings. Likewise, different users or user agents might have
5187 differing capabilities, characteristics, or preferences that could
5188 influence which representation, among those available, would be best
5189 to deliver. For this reason, HTTP provides mechanisms for content
5192 This specification defines three patterns of content negotiation that
5193 can be made visible within the protocol: "proactive" negotiation,
5194 where the server selects the representation based upon the user
5195 agent's stated preferences; "reactive" negotiation, where the server
5196 provides a list of representations for the user agent to choose from;
5197 and "request content" negotiation, where the user agent selects the
5198 representation for a future request based upon the server's stated
5199 preferences in past responses.
5201 Other patterns of content negotiation include "conditional content",
5202 where the representation consists of multiple parts that are
5203 selectively rendered based on user agent parameters, "active
5204 content", where the representation contains a script that makes
5205 additional (more specific) requests based on the user agent
5206 characteristics, and "Transparent Content Negotiation" ([RFC2295]),
5207 where content selection is performed by an intermediary. These
5208 patterns are not mutually exclusive, and each has trade-offs in
5209 applicability and practicality.
5211 Note that, in all cases, HTTP is not aware of the resource semantics.
5212 The consistency with which an origin server responds to requests,
5213 over time and over the varying dimensions of content negotiation, and
5214 thus the "sameness" of a resource's observed representations over
5215 time, is determined entirely by whatever entity or algorithm selects
5216 or generates those responses.
521812.1. Proactive Negotiation
5220 When content negotiation preferences are sent by the user agent in a
5221 request to encourage an algorithm located at the server to select the
5222 preferred representation, it is called "proactive negotiation"
5223 (a.k.a., "server-driven negotiation"). Selection is based on the
5224 available representations for a response (the dimensions over which
5225 it might vary, such as language, content coding, etc.) compared to
5226 various information supplied in the request, including both the
5227 explicit negotiation header fields below and implicit
5228 characteristics, such as the client's network address or parts of the
5231 Proactive negotiation is advantageous when the algorithm for
5232 selecting from among the available representations is difficult to
5233 describe to a user agent, or when the server desires to send its
5234 "best guess" to the user agent along with the first response (when
5235 that "best guess" is good enough for the user, this avoids the round-
5236 trip delay of a subsequent request). In order to improve the
5237 server's guess, a user agent MAY send request header fields that
5238 describe its preferences.
5240 Proactive negotiation has serious disadvantages:
5242 * It is impossible for the server to accurately determine what might
5243 be "best" for any given user, since that would require complete
5244 knowledge of both the capabilities of the user agent and the
5245 intended use for the response (e.g., does the user want to view it
5246 on screen or print it on paper?);
5248 * Having the user agent describe its capabilities in every request
5249 can be both very inefficient (given that only a small percentage
5250 of responses have multiple representations) and a potential risk
5251 to the user's privacy;
5253 * It complicates the implementation of an origin server and the
5254 algorithms for generating responses to a request; and,
5256 * It limits the reusability of responses for shared caching.
5258 A user agent cannot rely on proactive negotiation preferences being
5259 consistently honored, since the origin server might not implement
5260 proactive negotiation for the requested resource or might decide that
5261 sending a response that doesn't conform to the user agent's
5262 preferences is better than sending a 406 (Not Acceptable) response.
5264 A Vary header field (Section 12.5.5) is often sent in a response
5265 subject to proactive negotiation to indicate what parts of the
5266 request information were used in the selection algorithm.
5268 The request header fields Accept, Accept-Charset, Accept-Encoding,
5269 and Accept-Language are defined below for a user agent to engage in
5270 proactive negotiation of the response content. The preferences sent
5271 in these fields apply to any content in the response, including
5272 representations of the target resource, representations of error or
5273 processing status, and potentially even the miscellaneous text
5274 strings that might appear within the protocol.
527612.2. Reactive Negotiation
5278 With "reactive negotiation" (a.k.a., "agent-driven negotiation"),
5279 selection of content (regardless of the status code) is performed by
5280 the user agent after receiving an initial response. The mechanism
5281 for reactive negotiation might be as simple as a list of references
5282 to alternative representations.
5284 If the user agent is not satisfied by the initial response content,
5285 it can perform a GET request on one or more of the alternative
5286 resources to obtain a different representation. Selection of such
5287 alternatives might be performed automatically (by the user agent) or
5288 manually (e.g., by the user selecting from a hypertext menu).
5290 A server might choose not to send an initial representation, other
5291 than the list of alternatives, and thereby indicate that reactive
5292 negotiation by the user agent is preferred. For example, the
5293 alternatives listed in responses with the 300 (Multiple Choices) and
5294 406 (Not Acceptable) status codes include information about available
5295 representations so that the user or user agent can react by making a
5298 Reactive negotiation is advantageous when the response would vary
5299 over commonly used dimensions (such as type, language, or encoding),
5300 when the origin server is unable to determine a user agent's
5301 capabilities from examining the request, and generally when public
5302 caches are used to distribute server load and reduce network usage.
5304 Reactive negotiation suffers from the disadvantages of transmitting a
5305 list of alternatives to the user agent, which degrades user-perceived
5306 latency if transmitted in the header section, and needing a second
5307 request to obtain an alternate representation. Furthermore, this
5308 specification does not define a mechanism for supporting automatic
5309 selection, though it does not prevent such a mechanism from being
531212.3. Request Content Negotiation
5314 When content negotiation preferences are sent in a server's response,
5315 the listed preferences are called "request content negotiation"
5316 because they intend to influence selection of an appropriate content
5317 for subsequent requests to that resource. For example, the Accept
5318 (Section 12.5.1) and Accept-Encoding (Section 12.5.3) header fields
5319 can be sent in a response to indicate preferred media types and
5320 content codings for subsequent requests to that resource.
5322 Similarly, Section 3.1 of [RFC5789] defines the "Accept-Patch"
5323 response header field, which allows discovery of which content types
5324 are accepted in PATCH requests.
532612.4. Content Negotiation Field Features
5330 For each of the content negotiation fields, a request that does not
5331 contain the field implies that the sender has no preference on that
5332 dimension of negotiation.
5334 If a content negotiation header field is present in a request and
5335 none of the available representations for the response can be
5336 considered acceptable according to it, the origin server can either
5337 honor the header field by sending a 406 (Not Acceptable) response or
5338 disregard the header field by treating the response as if it is not
5339 subject to content negotiation for that request header field. This
5340 does not imply, however, that the client will be able to use the
5343 | *Note:* A user agent sending these header fields makes it
5344 | easier for a server to identify an individual by virtue of the
5345 | user agent's request characteristics (Section 17.13).
534712.4.2. Quality Values
5349 The content negotiation fields defined by this specification use a
5350 common parameter, named "q" (case-insensitive), to assign a relative
5351 "weight" to the preference for that associated kind of content. This
5352 weight is referred to as a "quality value" (or "qvalue") because the
5353 same parameter name is often used within server configurations to
5354 assign a weight to the relative quality of the various
5355 representations that can be selected for a resource.
5357 The weight is normalized to a real number in the range 0 through 1,
5358 where 0.001 is the least preferred and 1 is the most preferred; a
5359 value of 0 means "not acceptable". If no "q" parameter is present,
5360 the default weight is 1.
5362 weight = OWS ";" OWS "q=" qvalue
5363 qvalue = ( "0" [ "." 0*3DIGIT ] )
5364 / ( "1" [ "." 0*3("0") ] )
5366 A sender of qvalue MUST NOT generate more than three digits after the
5367 decimal point. User configuration of these values ought to be
5368 limited in the same fashion.
537012.4.3. Wildcard Values
5372 Most of these header fields, where indicated, define a wildcard value
5373 ("*") to select unspecified values. If no wildcard is present,
5374 values that are not explicitly mentioned in the field are considered
5375 unacceptable. Within Vary, the wildcard value means that the
5376 variance is unlimited.
5378 | *Note:* In practice, using wildcards in content negotiation has
5379 | limited practical value because it is seldom useful to say, for
5380 | example, "I prefer image/* more or less than (some other
5381 | specific value)". By sending Accept: */*;q=0, clients can
5382 | explicitly request a 406 (Not Acceptable) response if a more
5383 | preferred format is not available, but they still need to be
5384 | able to handle a different response since the server is allowed
5385 | to ignore their preference.
538712.5. Content Negotiation Fields
5391 The "Accept" header field can be used by user agents to specify their
5392 preferences regarding response media types. For example, Accept
5393 header fields can be used to indicate that the request is
5394 specifically limited to a small set of desired types, as in the case
5395 of a request for an in-line image.
5397 When sent by a server in a response, Accept provides information
5398 about which content types are preferred in the content of a
5399 subsequent request to the same resource.
5401 Accept = #( media-range [ weight ] )
5403 media-range = ( "*/*"
5405 / ( type "/" subtype )
5408 The asterisk "*" character is used to group media types into ranges,
5409 with "*/*" indicating all media types and "type/*" indicating all
5410 subtypes of that type. The media-range can include media type
5411 parameters that are applicable to that range.
5413 Each media-range might be followed by optional applicable media type
5414 parameters (e.g., charset), followed by an optional "q" parameter for
5415 indicating a relative weight (Section 12.4.2).
5417 Previous specifications allowed additional extension parameters to
5418 appear after the weight parameter. The accept extension grammar
5419 (accept-params, accept-ext) has been removed because it had a
5420 complicated definition, was not being used in practice, and is more
5421 easily deployed through new header fields. Senders using weights
5422 SHOULD send "q" last (after all media-range parameters). Recipients
5423 SHOULD process any parameter named "q" as weight, regardless of
5426 | *Note:* Use of the "q" parameter name to control content
5427 | negotiation would interfere with any media type parameter
5428 | having the same name. Hence, the media type registry disallows
5429 | parameters named "q".
5433 Accept: audio/*; q=0.2, audio/basic
5435 is interpreted as "I prefer audio/basic, but send me any audio type
5436 if it is the best available after an 80% markdown in quality".
5438 A more elaborate example is
5440 Accept: text/plain; q=0.5, text/html,
5441 text/x-dvi; q=0.8, text/x-c
5443 Verbally, this would be interpreted as "text/html and text/x-c are
5444 the equally preferred media types, but if they do not exist, then
5445 send the text/x-dvi representation, and if that does not exist, send
5446 the text/plain representation".
5448 Media ranges can be overridden by more specific media ranges or
5449 specific media types. If more than one media range applies to a
5450 given type, the most specific reference has precedence. For example,
5452 Accept: text/*, text/plain, text/plain;format=flowed, */*
5454 have the following precedence:
5456 1. text/plain;format=flowed
5464 The media type quality factor associated with a given type is
5465 determined by finding the media range with the highest precedence
5466 that matches the type. For example,
5468 Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
5469 text/plain;format=fixed;q=0.4, */*;q=0.5
5471 would cause the following values to be associated:
5473 +==========================+===============+
5474 | Media Type | Quality Value |
5475 +==========================+===============+
5476 | text/plain;format=flowed | 1 |
5477 +--------------------------+---------------+
5478 | text/plain | 0.7 |
5479 +--------------------------+---------------+
5481 +--------------------------+---------------+
5482 | image/jpeg | 0.5 |
5483 +--------------------------+---------------+
5484 | text/plain;format=fixed | 0.4 |
5485 +--------------------------+---------------+
5486 | text/html;level=3 | 0.7 |
5487 +--------------------------+---------------+
5491 | *Note:* A user agent might be provided with a default set of
5492 | quality values for certain media ranges. However, unless the
5493 | user agent is a closed system that cannot interact with other
5494 | rendering agents, this default set ought to be configurable by
549712.5.2. Accept-Charset
5499 The "Accept-Charset" header field can be sent by a user agent to
5500 indicate its preferences for charsets in textual response content.
5501 For example, this field allows user agents capable of understanding
5502 more comprehensive or special-purpose charsets to signal that
5503 capability to an origin server that is capable of representing
5504 information in those charsets.
5506 Accept-Charset = #( ( token / "*" ) [ weight ] )
5508 Charset names are defined in Section 8.3.2. A user agent MAY
5509 associate a quality value with each charset to indicate the user's
5510 relative preference for that charset, as defined in Section 12.4.2.
5513 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
5515 The special value "*", if present in the Accept-Charset header field,
5516 matches every charset that is not mentioned elsewhere in the field.
5518 | *Note:* Accept-Charset is deprecated because UTF-8 has become
5519 | nearly ubiquitous and sending a detailed list of user-preferred
5520 | charsets wastes bandwidth, increases latency, and makes passive
5521 | fingerprinting far too easy (Section 17.13). Most general-
5522 | purpose user agents do not send Accept-Charset unless
5523 | specifically configured to do so.
552512.5.3. Accept-Encoding
5527 The "Accept-Encoding" header field can be used to indicate
5528 preferences regarding the use of content codings (Section 8.4.1).
5530 When sent by a user agent in a request, Accept-Encoding indicates the
5531 content codings acceptable in a response.
5533 When sent by a server in a response, Accept-Encoding provides
5534 information about which content codings are preferred in the content
5535 of a subsequent request to the same resource.
5537 An "identity" token is used as a synonym for "no encoding" in order
5538 to communicate when no encoding is preferred.
5540 Accept-Encoding = #( codings [ weight ] )
5541 codings = content-coding / "identity" / "*"
5543 Each codings value MAY be given an associated quality value (weight)
5544 representing the preference for that encoding, as defined in
5545 Section 12.4.2. The asterisk "*" symbol in an Accept-Encoding field
5546 matches any available content coding not explicitly listed in the
5551 Accept-Encoding: compress, gzip
5554 Accept-Encoding: compress;q=0.5, gzip;q=1.0
5555 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
5557 A server tests whether a content coding for a given representation is
5558 acceptable using these rules:
5560 1. If no Accept-Encoding header field is in the request, any content
5561 coding is considered acceptable by the user agent.
5563 2. If the representation has no content coding, then it is
5564 acceptable by default unless specifically excluded by the Accept-
5565 Encoding header field stating either "identity;q=0" or "*;q=0"
5566 without a more specific entry for "identity".
5568 3. If the representation's content coding is one of the content
5569 codings listed in the Accept-Encoding field value, then it is
5570 acceptable unless it is accompanied by a qvalue of 0. (As
5571 defined in Section 12.4.2, a qvalue of 0 means "not acceptable".)
5573 A representation could be encoded with multiple content codings.
5574 However, most content codings are alternative ways to accomplish the
5575 same purpose (e.g., data compression). When selecting between
5576 multiple content codings that have the same purpose, the acceptable
5577 content coding with the highest non-zero qvalue is preferred.
5579 An Accept-Encoding header field with a field value that is empty
5580 implies that the user agent does not want any content coding in
5581 response. If a non-empty Accept-Encoding header field is present in
5582 a request and none of the available representations for the response
5583 have a content coding that is listed as acceptable, the origin server
5584 SHOULD send a response without any content coding unless the identity
5585 coding is indicated as unacceptable.
5587 When the Accept-Encoding header field is present in a response, it
5588 indicates what content codings the resource was willing to accept in
5589 the associated request. The field value is evaluated the same way as
5592 Note that this information is specific to the associated request; the
5593 set of supported encodings might be different for other resources on
5594 the same server and could change over time or depend on other aspects
5595 of the request (such as the request method).
5597 Servers that fail a request due to an unsupported content coding
5598 ought to respond with a 415 (Unsupported Media Type) status and
5599 include an Accept-Encoding header field in that response, allowing
5600 clients to distinguish between issues related to content codings and
5601 media types. In order to avoid confusion with issues related to
5602 media types, servers that fail a request with a 415 status for
5603 reasons unrelated to content codings MUST NOT include the Accept-
5604 Encoding header field.
5606 The most common use of Accept-Encoding is in responses with a 415
5607 (Unsupported Media Type) status code, in response to optimistic use
5608 of a content coding by clients. However, the header field can also
5609 be used to indicate to clients that content codings are supported in
5610 order to optimize future interactions. For example, a resource might
5611 include it in a 2xx (Successful) response when the request content
5612 was big enough to justify use of a compression coding but the client
561512.5.4. Accept-Language
5617 The "Accept-Language" header field can be used by user agents to
5618 indicate the set of natural languages that are preferred in the
5619 response. Language tags are defined in Section 8.5.1.
5621 Accept-Language = #( language-range [ weight ] )
5623 <language-range, see [RFC4647], Section 2.1>
5625 Each language-range can be given an associated quality value
5626 representing an estimate of the user's preference for the languages
5627 specified by that range, as defined in Section 12.4.2. For example,
5629 Accept-Language: da, en-gb;q=0.8, en;q=0.7
5631 would mean: "I prefer Danish, but will accept British English and
5632 other types of English".
5634 Note that some recipients treat the order in which language tags are
5635 listed as an indication of descending priority, particularly for tags
5636 that are assigned equal quality values (no value is the same as q=1).
5637 However, this behavior cannot be relied upon. For consistency and to
5638 maximize interoperability, many user agents assign each language tag
5639 a unique quality value while also listing them in order of decreasing
5640 quality. Additional discussion of language priority lists can be
5641 found in Section 2.3 of [RFC4647].
5643 For matching, Section 3 of [RFC4647] defines several matching
5644 schemes. Implementations can offer the most appropriate matching
5645 scheme for their requirements. The "Basic Filtering" scheme
5646 ([RFC4647], Section 3.3.1) is identical to the matching scheme that
5647 was previously defined for HTTP in Section 14.4 of [RFC2616].
5649 It might be contrary to the privacy expectations of the user to send
5650 an Accept-Language header field with the complete linguistic
5651 preferences of the user in every request (Section 17.13).
5653 Since intelligibility is highly dependent on the individual user,
5654 user agents need to allow user control over the linguistic preference
5655 (either through configuration of the user agent itself or by
5656 defaulting to a user controllable system setting). A user agent that
5657 does not provide such control to the user MUST NOT send an Accept-
5658 Language header field.
5660 | *Note:* User agents ought to provide guidance to users when
5661 | setting a preference, since users are rarely familiar with the
5662 | details of language matching as described above. For example,
5663 | users might assume that on selecting "en-gb", they will be
5664 | served any kind of English document if British English is not
5665 | available. A user agent might suggest, in such a case, to add
5666 | "en" to the list for better matching behavior.
5670 The "Vary" header field in a response describes what parts of a
5671 request message, aside from the method and target URI, might have
5672 influenced the origin server's process for selecting the content of
5675 Vary = #( "*" / field-name )
5677 A Vary field value is either the wildcard member "*" or a list of
5678 request field names, known as the selecting header fields, that might
5679 have had a role in selecting the representation for this response.
5680 Potential selecting header fields are not limited to fields defined
5681 by this specification.
5683 A list containing the member "*" signals that other aspects of the
5684 request might have played a role in selecting the response
5685 representation, possibly including aspects outside the message syntax
5686 (e.g., the client's network address). A recipient will not be able
5687 to determine whether this response is appropriate for a later request
5688 without forwarding the request to the origin server. A proxy MUST
5689 NOT generate "*" in a Vary field value.
5691 For example, a response that contains
5693 Vary: accept-encoding, accept-language
5695 indicates that the origin server might have used the request's
5696 Accept-Encoding and Accept-Language header fields (or lack thereof)
5697 as determining factors while choosing the content for this response.
5699 A Vary field containing a list of field names has two purposes:
5701 1. To inform cache recipients that they MUST NOT use this response
5702 to satisfy a later request unless the later request has the same
5703 values for the listed header fields as the original request
5704 (Section 4.1 of [CACHING]) or reuse of the response has been
5705 validated by the origin server. In other words, Vary expands the
5706 cache key required to match a new request to the stored cache
5709 2. To inform user agent recipients that this response was subject to
5710 content negotiation (Section 12) and a different representation
5711 might be sent in a subsequent request if other values are
5712 provided in the listed header fields (proactive negotiation).
5714 An origin server SHOULD generate a Vary header field on a cacheable
5715 response when it wishes that response to be selectively reused for
5716 subsequent requests. Generally, that is the case when the response
5717 content has been tailored to better fit the preferences expressed by
5718 those selecting header fields, such as when an origin server has
5719 selected the response's language based on the request's
5720 Accept-Language header field.
5722 Vary might be elided when an origin server considers variance in
5723 content selection to be less significant than Vary's performance
5724 impact on caching, particularly when reuse is already limited by
5725 cache response directives (Section 5.2 of [CACHING]).
5727 There is no need to send the Authorization field name in Vary because
5728 reuse of that response for a different user is prohibited by the
5729 field definition (Section 11.6.2). Likewise, if the response content
5730 has been selected or influenced by network region, but the origin
5731 server wants the cached response to be reused even if recipients move
5732 from one region to another, then there is no need for the origin
5733 server to indicate such variance in Vary.
573513. Conditional Requests
5737 A conditional request is an HTTP request with one or more request
5738 header fields that indicate a precondition to be tested before
5739 applying the request method to the target resource. Section 13.2
5740 defines when to evaluate preconditions and their order of precedence
5741 when more than one precondition is present.
5743 Conditional GET requests are the most efficient mechanism for HTTP
5744 cache updates [CACHING]. Conditionals can also be applied to state-
5745 changing methods, such as PUT and DELETE, to prevent the "lost
5746 update" problem: one client accidentally overwriting the work of
5747 another client that has been acting in parallel.
5751 Preconditions are usually defined with respect to a state of the
5752 target resource as a whole (its current value set) or the state as
5753 observed in a previously obtained representation (one value in that
5754 set). If a resource has multiple current representations, each with
5755 its own observable state, a precondition will assume that the mapping
5756 of each request to a selected representation (Section 3.2) is
5757 consistent over time. Regardless, if the mapping is inconsistent or
5758 the server is unable to select an appropriate representation, then no
5759 harm will result when the precondition evaluates to false.
5761 Each precondition defined below consists of a comparison between a
5762 set of validators obtained from prior representations of the target
5763 resource to the current state of validators for the selected
5764 representation (Section 8.8). Hence, these preconditions evaluate
5765 whether the state of the target resource has changed since a given
5766 state known by the client. The effect of such an evaluation depends
5767 on the method semantics and choice of conditional, as defined in
5770 Other preconditions, defined by other specifications as extension
5771 fields, might place conditions on all recipients, on the state of the
5772 target resource in general, or on a group of resources. For
5773 instance, the "If" header field in WebDAV can make a request
5774 conditional on various aspects of multiple resources, such as locks,
5775 if the recipient understands and implements that field ([WEBDAV],
5778 Extensibility of preconditions is only possible when the precondition
5779 can be safely ignored if unknown (like If-Modified-Since), when
5780 deployment can be assumed for a given use case, or when
5781 implementation is signaled by some other property of the target
5782 resource. This encourages a focus on mutually agreed deployment of
5787 The "If-Match" header field makes the request method conditional on
5788 the recipient origin server either having at least one current
5789 representation of the target resource, when the field value is "*",
5790 or having a current representation of the target resource that has an
5791 entity tag matching a member of the list of entity tags provided in
5794 An origin server MUST use the strong comparison function when
5795 comparing entity tags for If-Match (Section 8.8.3.2), since the
5796 client intends this precondition to prevent the method from being
5797 applied if there have been any changes to the representation data.
5799 If-Match = "*" / #entity-tag
5804 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
5807 If-Match is most often used with state-changing methods (e.g., POST,
5808 PUT, DELETE) to prevent accidental overwrites when multiple user
5809 agents might be acting in parallel on the same resource (i.e., to
5810 prevent the "lost update" problem). In general, it can be used with
5811 any method that involves the selection or modification of a
5812 representation to abort the request if the selected representation's
5813 current entity tag is not a member within the If-Match field value.
5815 When an origin server receives a request that selects a
5816 representation and that request includes an If-Match header field,
5817 the origin server MUST evaluate the If-Match condition per
5818 Section 13.2 prior to performing the method.
5820 To evaluate a received If-Match header field:
5822 1. If the field value is "*", the condition is true if the origin
5823 server has a current representation for the target resource.
5825 2. If the field value is a list of entity tags, the condition is
5826 true if any of the listed tags match the entity tag of the
5827 selected representation.
5829 3. Otherwise, the condition is false.
5831 An origin server that evaluates an If-Match condition MUST NOT
5832 perform the requested method if the condition evaluates to false.
5833 Instead, the origin server MAY indicate that the conditional request
5834 failed by responding with a 412 (Precondition Failed) status code.
5835 Alternatively, if the request is a state-changing operation that
5836 appears to have already been applied to the selected representation,
5837 the origin server MAY respond with a 2xx (Successful) status code
5838 (i.e., the change requested by the user agent has already succeeded,
5839 but the user agent might not be aware of it, perhaps because the
5840 prior response was lost or an equivalent change was made by some
5843 Allowing an origin server to send a success response when a change
5844 request appears to have already been applied is more efficient for
5845 many authoring use cases, but comes with some risk if multiple user
5846 agents are making change requests that are very similar but not
5847 cooperative. For example, multiple user agents writing to a common
5848 resource as a semaphore (e.g., a nonatomic increment) are likely to
5849 collide and potentially lose important state transitions. For those
5850 kinds of resources, an origin server is better off being stringent in
5851 sending 412 for every failed precondition on an unsafe method. In
5852 other cases, excluding the ETag field from a success response might
5853 encourage the user agent to perform a GET as its next request to
5854 eliminate confusion about the resource's current state.
5856 A client MAY send an If-Match header field in a GET request to
5857 indicate that it would prefer a 412 (Precondition Failed) response if
5858 the selected representation does not match. However, this is only
5859 useful in range requests (Section 14) for completing a previously
5860 received partial representation when there is no desire for a new
5861 representation. If-Range (Section 13.1.5) is better suited for range
5862 requests when the client prefers to receive a new representation.
5864 A cache or intermediary MAY ignore If-Match because its
5865 interoperability features are only necessary for an origin server.
5867 Note that an If-Match header field with a list value containing "*"
5868 and other values (including other instances of "*") is syntactically
5869 invalid (therefore not allowed to be generated) and furthermore is
5870 unlikely to be interoperable.
587213.1.2. If-None-Match
5874 The "If-None-Match" header field makes the request method conditional
5875 on a recipient cache or origin server either not having any current
5876 representation of the target resource, when the field value is "*",
5877 or having a selected representation with an entity tag that does not
5878 match any of those listed in the field value.
5880 A recipient MUST use the weak comparison function when comparing
5881 entity tags for If-None-Match (Section 8.8.3.2), since weak entity
5882 tags can be used for cache validation even if there have been changes
5883 to the representation data.
5885 If-None-Match = "*" / #entity-tag
5889 If-None-Match: "xyzzy"
5890 If-None-Match: W/"xyzzy"
5891 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
5892 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
5895 If-None-Match is primarily used in conditional GET requests to enable
5896 efficient updates of cached information with a minimum amount of
5897 transaction overhead. When a client desires to update one or more
5898 stored responses that have entity tags, the client SHOULD generate an
5899 If-None-Match header field containing a list of those entity tags
5900 when making a GET request; this allows recipient servers to send a
5901 304 (Not Modified) response to indicate when one of those stored
5902 responses matches the selected representation.
5904 If-None-Match can also be used with a value of "*" to prevent an
5905 unsafe request method (e.g., PUT) from inadvertently modifying an
5906 existing representation of the target resource when the client
5907 believes that the resource does not have a current representation
5908 (Section 9.2.1). This is a variation on the "lost update" problem
5909 that might arise if more than one client attempts to create an
5910 initial representation for the target resource.
5912 When an origin server receives a request that selects a
5913 representation and that request includes an If-None-Match header
5914 field, the origin server MUST evaluate the If-None-Match condition
5915 per Section 13.2 prior to performing the method.
5917 To evaluate a received If-None-Match header field:
5919 1. If the field value is "*", the condition is false if the origin
5920 server has a current representation for the target resource.
5922 2. If the field value is a list of entity tags, the condition is
5923 false if one of the listed tags matches the entity tag of the
5924 selected representation.
5926 3. Otherwise, the condition is true.
5928 An origin server that evaluates an If-None-Match condition MUST NOT
5929 perform the requested method if the condition evaluates to false;
5930 instead, the origin server MUST respond with either a) the 304 (Not
5931 Modified) status code if the request method is GET or HEAD or b) the
5932 412 (Precondition Failed) status code for all other request methods.
5934 Requirements on cache handling of a received If-None-Match header
5935 field are defined in Section 4.3.2 of [CACHING].
5937 Note that an If-None-Match header field with a list value containing
5938 "*" and other values (including other instances of "*") is
5939 syntactically invalid (therefore not allowed to be generated) and
5940 furthermore is unlikely to be interoperable.
594213.1.3. If-Modified-Since
5944 The "If-Modified-Since" header field makes a GET or HEAD request
5945 method conditional on the selected representation's modification date
5946 being more recent than the date provided in the field value.
5947 Transfer of the selected representation's data is avoided if that
5948 data has not changed.
5950 If-Modified-Since = HTTP-date
5952 An example of the field is:
5954 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
5956 A recipient MUST ignore If-Modified-Since if the request contains an
5957 If-None-Match header field; the condition in If-None-Match is
5958 considered to be a more accurate replacement for the condition in If-
5959 Modified-Since, and the two are only combined for the sake of
5960 interoperating with older intermediaries that might not implement
5963 A recipient MUST ignore the If-Modified-Since header field if the
5964 received field value is not a valid HTTP-date, the field value has
5965 more than one member, or if the request method is neither GET nor
5968 A recipient MUST ignore the If-Modified-Since header field if the
5969 resource does not have a modification date available.
5971 A recipient MUST interpret an If-Modified-Since field value's
5972 timestamp in terms of the origin server's clock.
5974 If-Modified-Since is typically used for two distinct purposes: 1) to
5975 allow efficient updates of a cached representation that does not have
5976 an entity tag and 2) to limit the scope of a web traversal to
5977 resources that have recently changed.
5979 When used for cache updates, a cache will typically use the value of
5980 the cached message's Last-Modified header field to generate the field
5981 value of If-Modified-Since. This behavior is most interoperable for
5982 cases where clocks are poorly synchronized or when the server has
5983 chosen to only honor exact timestamp matches (due to a problem with
5984 Last-Modified dates that appear to go "back in time" when the origin
5985 server's clock is corrected or a representation is restored from an
5986 archived backup). However, caches occasionally generate the field
5987 value based on other data, such as the Date header field of the
5988 cached message or the clock time at which the message was received,
5989 particularly when the cached message does not contain a Last-Modified
5992 When used for limiting the scope of retrieval to a recent time
5993 window, a user agent will generate an If-Modified-Since field value
5994 based on either its own clock or a Date header field received from
5995 the server in a prior response. Origin servers that choose an exact
5996 timestamp match based on the selected representation's Last-Modified
5997 header field will not be able to help the user agent limit its data
5998 transfers to only those changed during the specified window.
6000 When an origin server receives a request that selects a
6001 representation and that request includes an If-Modified-Since header
6002 field without an If-None-Match header field, the origin server SHOULD
6003 evaluate the If-Modified-Since condition per Section 13.2 prior to
6004 performing the method.
6006 To evaluate a received If-Modified-Since header field:
6008 1. If the selected representation's last modification date is
6009 earlier or equal to the date provided in the field value, the
6012 2. Otherwise, the condition is true.
6014 An origin server that evaluates an If-Modified-Since condition SHOULD
6015 NOT perform the requested method if the condition evaluates to false;
6016 instead, the origin server SHOULD generate a 304 (Not Modified)
6017 response, including only those metadata that are useful for
6018 identifying or updating a previously cached response.
6020 Requirements on cache handling of a received If-Modified-Since header
6021 field are defined in Section 4.3.2 of [CACHING].
602313.1.4. If-Unmodified-Since
6025 The "If-Unmodified-Since" header field makes the request method
6026 conditional on the selected representation's last modification date
6027 being earlier than or equal to the date provided in the field value.
6028 This field accomplishes the same purpose as If-Match for cases where
6029 the user agent does not have an entity tag for the representation.
6031 If-Unmodified-Since = HTTP-date
6033 An example of the field is:
6035 If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
6037 A recipient MUST ignore If-Unmodified-Since if the request contains
6038 an If-Match header field; the condition in If-Match is considered to
6039 be a more accurate replacement for the condition in If-Unmodified-
6040 Since, and the two are only combined for the sake of interoperating
6041 with older intermediaries that might not implement If-Match.
6043 A recipient MUST ignore the If-Unmodified-Since header field if the
6044 received field value is not a valid HTTP-date (including when the
6045 field value appears to be a list of dates).
6047 A recipient MUST ignore the If-Unmodified-Since header field if the
6048 resource does not have a modification date available.
6050 A recipient MUST interpret an If-Unmodified-Since field value's
6051 timestamp in terms of the origin server's clock.
6053 If-Unmodified-Since is most often used with state-changing methods
6054 (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
6055 multiple user agents might be acting in parallel on a resource that
6056 does not supply entity tags with its representations (i.e., to
6057 prevent the "lost update" problem). In general, it can be used with
6058 any method that involves the selection or modification of a
6059 representation to abort the request if the selected representation's
6060 last modification date has changed since the date provided in the If-
6061 Unmodified-Since field value.
6063 When an origin server receives a request that selects a
6064 representation and that request includes an If-Unmodified-Since
6065 header field without an If-Match header field, the origin server MUST
6066 evaluate the If-Unmodified-Since condition per Section 13.2 prior to
6067 performing the method.
6069 To evaluate a received If-Unmodified-Since header field:
6071 1. If the selected representation's last modification date is
6072 earlier than or equal to the date provided in the field value,
6073 the condition is true.
6075 2. Otherwise, the condition is false.
6077 An origin server that evaluates an If-Unmodified-Since condition MUST
6078 NOT perform the requested method if the condition evaluates to false.
6079 Instead, the origin server MAY indicate that the conditional request
6080 failed by responding with a 412 (Precondition Failed) status code.
6081 Alternatively, if the request is a state-changing operation that
6082 appears to have already been applied to the selected representation,
6083 the origin server MAY respond with a 2xx (Successful) status code
6084 (i.e., the change requested by the user agent has already succeeded,
6085 but the user agent might not be aware of it, perhaps because the
6086 prior response was lost or an equivalent change was made by some
6089 Allowing an origin server to send a success response when a change
6090 request appears to have already been applied is more efficient for
6091 many authoring use cases, but comes with some risk if multiple user
6092 agents are making change requests that are very similar but not
6093 cooperative. In those cases, an origin server is better off being
6094 stringent in sending 412 for every failed precondition on an unsafe
6097 A client MAY send an If-Unmodified-Since header field in a GET
6098 request to indicate that it would prefer a 412 (Precondition Failed)
6099 response if the selected representation has been modified. However,
6100 this is only useful in range requests (Section 14) for completing a
6101 previously received partial representation when there is no desire
6102 for a new representation. If-Range (Section 13.1.5) is better suited
6103 for range requests when the client prefers to receive a new
6106 A cache or intermediary MAY ignore If-Unmodified-Since because its
6107 interoperability features are only necessary for an origin server.
6111 The "If-Range" header field provides a special conditional request
6112 mechanism that is similar to the If-Match and If-Unmodified-Since
6113 header fields but that instructs the recipient to ignore the Range
6114 header field if the validator doesn't match, resulting in transfer of
6115 the new selected representation instead of a 412 (Precondition
6118 If a client has a partial copy of a representation and wishes to have
6119 an up-to-date copy of the entire representation, it could use the
6120 Range header field with a conditional GET (using either or both of
6121 If-Unmodified-Since and If-Match.) However, if the precondition
6122 fails because the representation has been modified, the client would
6123 then have to make a second request to obtain the entire current
6126 The "If-Range" header field allows a client to "short-circuit" the
6127 second request. Informally, its meaning is as follows: if the
6128 representation is unchanged, send me the part(s) that I am requesting
6129 in Range; otherwise, send me the entire representation.
6131 If-Range = entity-tag / HTTP-date
6133 A valid entity-tag can be distinguished from a valid HTTP-date by
6134 examining the first three characters for a DQUOTE.
6136 A client MUST NOT generate an If-Range header field in a request that
6137 does not contain a Range header field. A server MUST ignore an If-
6138 Range header field received in a request that does not contain a
6139 Range header field. An origin server MUST ignore an If-Range header
6140 field received in a request for a target resource that does not
6141 support Range requests.
6143 A client MUST NOT generate an If-Range header field containing an
6144 entity tag that is marked as weak. A client MUST NOT generate an If-
6145 Range header field containing an HTTP-date unless the client has no
6146 entity tag for the corresponding representation and the date is a
6147 strong validator in the sense defined by Section 8.8.2.2.
6149 A server that receives an If-Range header field on a Range request
6150 MUST evaluate the condition per Section 13.2 prior to performing the
6153 To evaluate a received If-Range header field containing an HTTP-date:
6155 1. If the HTTP-date validator provided is not a strong validator in
6156 the sense defined by Section 8.8.2.2, the condition is false.
6158 2. If the HTTP-date validator provided exactly matches the
6159 Last-Modified field value for the selected representation, the
6162 3. Otherwise, the condition is false.
6164 To evaluate a received If-Range header field containing an
6167 1. If the entity-tag validator provided exactly matches the ETag
6168 field value for the selected representation using the strong
6169 comparison function (Section 8.8.3.2), the condition is true.
6171 2. Otherwise, the condition is false.
6173 A recipient of an If-Range header field MUST ignore the Range header
6174 field if the If-Range condition evaluates to false. Otherwise, the
6175 recipient SHOULD process the Range header field as requested.
6177 Note that the If-Range comparison is by exact match, including when
6178 the validator is an HTTP-date, and so it differs from the "earlier
6179 than or equal to" comparison used when evaluating an
6180 If-Unmodified-Since conditional.
618213.2. Evaluation of Preconditions
618413.2.1. When to Evaluate
6186 Except when excluded below, a recipient cache or origin server MUST
6187 evaluate received request preconditions after it has successfully
6188 performed its normal request checks and just before it would process
6189 the request content (if any) or perform the action associated with
6190 the request method. A server MUST ignore all received preconditions
6191 if its response to the same request without those conditions, prior
6192 to processing the request content, would have been a status code
6193 other than a 2xx (Successful) or 412 (Precondition Failed). In other
6194 words, redirects and failures that can be detected before significant
6195 processing occurs take precedence over the evaluation of
6198 A server that is not the origin server for the target resource and
6199 cannot act as a cache for requests on the target resource MUST NOT
6200 evaluate the conditional request header fields defined by this
6201 specification, and it MUST forward them if the request is forwarded,
6202 since the generating client intends that they be evaluated by a
6203 server that can provide a current representation. Likewise, a server
6204 MUST ignore the conditional request header fields defined by this
6205 specification when received with a request method that does not
6206 involve the selection or modification of a selected representation,
6207 such as CONNECT, OPTIONS, or TRACE.
6209 Note that protocol extensions can modify the conditions under which
6210 preconditions are evaluated or the consequences of their evaluation.
6211 For example, the immutable cache directive (defined by [RFC8246])
6212 instructs caches to forgo forwarding conditional requests when they
6213 hold a fresh response.
6215 Although conditional request header fields are defined as being
6216 usable with the HEAD method (to keep HEAD's semantics consistent with
6217 those of GET), there is no point in sending a conditional HEAD
6218 because a successful response is around the same size as a 304 (Not
6219 Modified) response and more useful than a 412 (Precondition Failed)
622213.2.2. Precedence of Preconditions
6224 When more than one conditional request header field is present in a
6225 request, the order in which the fields are evaluated becomes
6226 important. In practice, the fields defined in this document are
6227 consistently implemented in a single, logical order, since "lost
6228 update" preconditions have more strict requirements than cache
6229 validation, a validated cache is more efficient than a partial
6230 response, and entity tags are presumed to be more accurate than date
6233 A recipient cache or origin server MUST evaluate the request
6234 preconditions defined by this specification in the following order:
6236 1. When recipient is the origin server and If-Match is present,
6237 evaluate the If-Match precondition:
6239 * if true, continue to step 3
6241 * if false, respond 412 (Precondition Failed) unless it can be
6242 determined that the state-changing request has already
6243 succeeded (see Section 13.1.1)
6245 2. When recipient is the origin server, If-Match is not present, and
6246 If-Unmodified-Since is present, evaluate the If-Unmodified-Since
6249 * if true, continue to step 3
6251 * if false, respond 412 (Precondition Failed) unless it can be
6252 determined that the state-changing request has already
6253 succeeded (see Section 13.1.4)
6255 3. When If-None-Match is present, evaluate the If-None-Match
6258 * if true, continue to step 5
6260 * if false for GET/HEAD, respond 304 (Not Modified)
6262 * if false for other methods, respond 412 (Precondition Failed)
6264 4. When the method is GET or HEAD, If-None-Match is not present, and
6265 If-Modified-Since is present, evaluate the If-Modified-Since
6268 * if true, continue to step 5
6270 * if false, respond 304 (Not Modified)
6272 5. When the method is GET and both Range and If-Range are present,
6273 evaluate the If-Range precondition:
6275 * if true and the Range is applicable to the selected
6276 representation, respond 206 (Partial Content)
6278 * otherwise, ignore the Range header field and respond 200 (OK)
6282 * perform the requested method and respond according to its
6285 Any extension to HTTP that defines additional conditional request
6286 header fields ought to define the order for evaluating such fields in
6287 relation to those defined in this document and other conditionals
6288 that might be found in practice.
6292 Clients often encounter interrupted data transfers as a result of
6293 canceled requests or dropped connections. When a client has stored a
6294 partial representation, it is desirable to request the remainder of
6295 that representation in a subsequent request rather than transfer the
6296 entire representation. Likewise, devices with limited local storage
6297 might benefit from being able to request only a subset of a larger
6298 representation, such as a single page of a very large document, or
6299 the dimensions of an embedded image.
6301 Range requests are an OPTIONAL feature of HTTP, designed so that
6302 recipients not implementing this feature (or not supporting it for
6303 the target resource) can respond as if it is a normal GET request
6304 without impacting interoperability. Partial responses are indicated
6305 by a distinct status code to not be mistaken for full responses by
6306 caches that might not implement the feature.
6310 Representation data can be partitioned into subranges when there are
6311 addressable structural units inherent to that data's content coding
6312 or media type. For example, octet (a.k.a. byte) boundaries are a
6313 structural unit common to all representation data, allowing
6314 partitions of the data to be identified as a range of bytes at some
6315 offset from the start or end of that data.
6317 This general notion of a "range unit" is used in the Accept-Ranges
6318 (Section 14.3) response header field to advertise support for range
6319 requests, the Range (Section 14.2) request header field to delineate
6320 the parts of a representation that are requested, and the
6321 Content-Range (Section 14.4) header field to describe which part of a
6322 representation is being transferred.
6326 All range unit names are case-insensitive and ought to be registered
6327 within the "HTTP Range Unit Registry", as defined in Section 16.5.1.
6329 Range units are intended to be extensible, as described in
633214.1.1. Range Specifiers
6334 Ranges are expressed in terms of a range unit paired with a set of
6335 range specifiers. The range unit name determines what kinds of
6336 range-spec are applicable to its own specifiers. Hence, the
6337 following grammar is generic: each range unit is expected to specify
6338 requirements on when int-range, suffix-range, and other-range are
6341 A range request can specify a single range or a set of ranges within
6342 a single representation.
6344 ranges-specifier = range-unit "=" range-set
6345 range-set = 1#range-spec
6346 range-spec = int-range
6350 An int-range is a range expressed as two non-negative integers or as
6351 one non-negative integer through to the end of the representation
6352 data. The range unit specifies what the integers mean (e.g., they
6353 might indicate unit offsets from the beginning, inclusive numbered
6356 int-range = first-pos "-" [ last-pos ]
6360 An int-range is invalid if the last-pos value is present and less
6363 A suffix-range is a range expressed as a suffix of the representation
6364 data with the provided non-negative integer maximum length (in range
6365 units). In other words, the last N units of the representation data.
6367 suffix-range = "-" suffix-length
6368 suffix-length = 1*DIGIT
6370 To provide for extensibility, the other-range rule is a mostly
6371 unconstrained grammar that allows application-specific or future
6372 range units to define additional range specifiers.
6374 other-range = 1*( %x21-2B / %x2D-7E )
6375 ; 1*(VCHAR excluding comma)
6377 A ranges-specifier is invalid if it contains any range-spec that is
6378 invalid or undefined for the indicated range-unit.
6380 A valid ranges-specifier is "satisfiable" if it contains at least one
6381 range-spec that is satisfiable, as defined by the indicated
6382 range-unit. Otherwise, the ranges-specifier is "unsatisfiable".
6386 The "bytes" range unit is used to express subranges of a
6387 representation data's octet sequence. Each byte range is expressed
6388 as an integer range at some offset, relative to either the beginning
6389 (int-range) or end (suffix-range) of the representation data. Byte
6390 ranges do not use the other-range specifier.
6392 The first-pos value in a bytes int-range gives the offset of the
6393 first byte in a range. The last-pos value gives the offset of the
6394 last byte in the range; that is, the byte positions specified are
6395 inclusive. Byte offsets start at zero.
6397 If the representation data has a content coding applied, each byte
6398 range is calculated with respect to the encoded sequence of bytes,
6399 not the sequence of underlying bytes that would be obtained after
6402 Examples of bytes range specifiers:
6404 * The first 500 bytes (byte offsets 0-499, inclusive):
6408 * The second 500 bytes (byte offsets 500-999, inclusive):
6412 A client can limit the number of bytes requested without knowing the
6413 size of the selected representation. If the last-pos value is
6414 absent, or if the value is greater than or equal to the current
6415 length of the representation data, the byte range is interpreted as
6416 the remainder of the representation (i.e., the server replaces the
6417 value of last-pos with a value that is one less than the current
6418 length of the selected representation).
6420 A client can refer to the last N bytes (N > 0) of the selected
6421 representation using a suffix-range. If the selected representation
6422 is shorter than the specified suffix-length, the entire
6423 representation is used.
6425 Additional examples, assuming a representation of length 10000:
6427 * The final 500 bytes (byte offsets 9500-9999, inclusive):
6435 * The first and last bytes only (bytes 0 and 9999):
6439 * The first, middle, and last 1000 bytes:
6441 bytes= 0-999, 4500-5499, -1000
6443 * Other valid (but not canonical) specifications of the second 500
6444 bytes (byte offsets 500-999, inclusive):
6446 bytes=500-600,601-999
6447 bytes=500-700,601-999
6449 For a GET request, a valid bytes range-spec is satisfiable if it is
6452 * an int-range with a first-pos that is less than the current length
6453 of the selected representation or
6455 * a suffix-range with a non-zero suffix-length.
6457 When a selected representation has zero length, the only satisfiable
6458 form of range-spec in a GET request is a suffix-range with a non-zero
6461 In the byte-range syntax, first-pos, last-pos, and suffix-length are
6462 expressed as decimal number of octets. Since there is no predefined
6463 limit to the length of content, recipients MUST anticipate
6464 potentially large decimal numerals and prevent parsing errors due to
6465 integer conversion overflows.
6469 The "Range" header field on a GET request modifies the method
6470 semantics to request transfer of only one or more subranges of the
6471 selected representation data (Section 8.1), rather than the entire
6472 selected representation.
6474 Range = ranges-specifier
6476 A server MAY ignore the Range header field. However, origin servers
6477 and intermediate caches ought to support byte ranges when possible,
6478 since they support efficient recovery from partially failed transfers
6479 and partial retrieval of large representations.
6481 A server MUST ignore a Range header field received with a request
6482 method that is unrecognized or for which range handling is not
6483 defined. For this specification, GET is the only method for which
6484 range handling is defined.
6486 An origin server MUST ignore a Range header field that contains a
6487 range unit it does not understand. A proxy MAY discard a Range
6488 header field that contains a range unit it does not understand.
6490 A server that supports range requests MAY ignore or reject a Range
6491 header field that contains an invalid ranges-specifier
6492 (Section 14.1.1), a ranges-specifier with more than two overlapping
6493 ranges, or a set of many small ranges that are not listed in
6494 ascending order, since these are indications of either a broken
6495 client or a deliberate denial-of-service attack (Section 17.15). A
6496 client SHOULD NOT request multiple ranges that are inherently less
6497 efficient to process and transfer than a single range that
6498 encompasses the same data.
6500 A server that supports range requests MAY ignore a Range header field
6501 when the selected representation has no content (i.e., the selected
6502 representation's data is of zero length).
6504 A client that is requesting multiple ranges SHOULD list those ranges
6505 in ascending order (the order in which they would typically be
6506 received in a complete representation) unless there is a specific
6507 need to request a later part earlier. For example, a user agent
6508 processing a large representation with an internal catalog of parts
6509 might need to request later parts first, particularly if the
6510 representation consists of pages stored in reverse order and the user
6511 agent wishes to transfer one page at a time.
6513 The Range header field is evaluated after evaluating the precondition
6514 header fields defined in Section 13.1, and only if the result in
6515 absence of the Range header field would be a 200 (OK) response. In
6516 other words, Range is ignored when a conditional GET would result in
6517 a 304 (Not Modified) response.
6519 The If-Range header field (Section 13.1.5) can be used as a
6520 precondition to applying the Range header field.
6522 If all of the preconditions are true, the server supports the Range
6523 header field for the target resource, the received Range field-value
6524 contains a valid ranges-specifier with a range-unit supported for
6525 that target resource, and that ranges-specifier is satisfiable with
6526 respect to the selected representation, the server SHOULD send a 206
6527 (Partial Content) response with content containing one or more
6528 partial representations that correspond to the satisfiable
6529 range-spec(s) requested.
6531 The above does not imply that a server will send all requested
6532 ranges. In some cases, it may only be possible (or efficient) to
6533 send a portion of the requested ranges first, while expecting the
6534 client to re-request the remaining portions later if they are still
6535 desired (see Section 15.3.7).
6537 If all of the preconditions are true, the server supports the Range
6538 header field for the target resource, the received Range field-value
6539 contains a valid ranges-specifier, and either the range-unit is not
6540 supported for that target resource or the ranges-specifier is
6541 unsatisfiable with respect to the selected representation, the server
6542 SHOULD send a 416 (Range Not Satisfiable) response.
6546 The "Accept-Ranges" field in a response indicates whether an upstream
6547 server supports range requests for the target resource.
6549 Accept-Ranges = acceptable-ranges
6550 acceptable-ranges = 1#range-unit
6552 For example, a server that supports byte-range requests
6553 (Section 14.1.2) can send the field
6555 Accept-Ranges: bytes
6557 to indicate that it supports byte range requests for that target
6558 resource, thereby encouraging its use by the client for future
6559 partial requests on the same request path. Range units are defined
6562 A client MAY generate range requests regardless of having received an
6563 Accept-Ranges field. The information only provides advice for the
6564 sake of improving performance and reducing unnecessary network
6567 Conversely, a client MUST NOT assume that receiving an Accept-Ranges
6568 field means that future range requests will return partial responses.
6569 The content might change, the server might only support range
6570 requests at certain times or under certain conditions, or a different
6571 intermediary might process the next request.
6573 A server that does not support any kind of range request for the
6574 target resource MAY send
6578 to advise the client not to attempt a range request on the same
6579 request path. The range unit "none" is reserved for this purpose.
6581 The Accept-Ranges field MAY be sent in a trailer section, but is
6582 preferred to be sent as a header field because the information is
6583 particularly useful for restarting large information transfers that
6584 have failed in mid-content (before the trailer section is received).
6588 The "Content-Range" header field is sent in a single part 206
6589 (Partial Content) response to indicate the partial range of the
6590 selected representation enclosed as the message content, sent in each
6591 part of a multipart 206 response to indicate the range enclosed
6592 within each body part (Section 14.6), and sent in 416 (Range Not
6593 Satisfiable) responses to provide information about the selected
6596 Content-Range = range-unit SP
6597 ( range-resp / unsatisfied-range )
6599 range-resp = incl-range "/" ( complete-length / "*" )
6600 incl-range = first-pos "-" last-pos
6601 unsatisfied-range = "*/" complete-length
6603 complete-length = 1*DIGIT
6605 If a 206 (Partial Content) response contains a Content-Range header
6606 field with a range unit (Section 14.1) that the recipient does not
6607 understand, the recipient MUST NOT attempt to recombine it with a
6608 stored representation. A proxy that receives such a message SHOULD
6609 forward it downstream.
6611 Content-Range might also be sent as a request modifier to request a
6612 partial PUT, as described in Section 14.5, based on private
6613 agreements between client and origin server. A server MUST ignore a
6614 Content-Range header field received in a request with a method for
6615 which Content-Range support is not defined.
6617 For byte ranges, a sender SHOULD indicate the complete length of the
6618 representation from which the range has been extracted, unless the
6619 complete length is unknown or difficult to determine. An asterisk
6620 character ("*") in place of the complete-length indicates that the
6621 representation length was unknown when the header field was
6624 The following example illustrates when the complete length of the
6625 selected representation is known by the sender to be 1234 bytes:
6627 Content-Range: bytes 42-1233/1234
6629 and this second example illustrates when the complete length is
6632 Content-Range: bytes 42-1233/*
6634 A Content-Range field value is invalid if it contains a range-resp
6635 that has a last-pos value less than its first-pos value, or a
6636 complete-length value less than or equal to its last-pos value. The
6637 recipient of an invalid Content-Range MUST NOT attempt to recombine
6638 the received content with a stored representation.
6640 A server generating a 416 (Range Not Satisfiable) response to a byte-
6641 range request SHOULD send a Content-Range header field with an
6642 unsatisfied-range value, as in the following example:
6644 Content-Range: bytes */1234
6646 The complete-length in a 416 response indicates the current length of
6647 the selected representation.
6649 The Content-Range header field has no meaning for status codes that
6650 do not explicitly describe its semantic. For this specification,
6651 only the 206 (Partial Content) and 416 (Range Not Satisfiable) status
6652 codes describe a meaning for Content-Range.
6654 The following are examples of Content-Range values in which the
6655 selected representation contains a total of 1234 bytes:
6657 * The first 500 bytes:
6659 Content-Range: bytes 0-499/1234
6661 * The second 500 bytes:
6663 Content-Range: bytes 500-999/1234
6665 * All except for the first 500 bytes:
6667 Content-Range: bytes 500-1233/1234
6669 * The last 500 bytes:
6671 Content-Range: bytes 734-1233/1234
6675 Some origin servers support PUT of a partial representation when the
6676 user agent sends a Content-Range header field (Section 14.4) in the
6677 request, though such support is inconsistent and depends on private
6678 agreements with user agents. In general, it requests that the state
6679 of the target resource be partly replaced with the enclosed content
6680 at an offset and length indicated by the Content-Range value, where
6681 the offset is relative to the current selected representation.
6683 An origin server SHOULD respond with a 400 (Bad Request) status code
6684 if it receives Content-Range on a PUT for a target resource that does
6685 not support partial PUT requests.
6687 Partial PUT is not backwards compatible with the original definition
6688 of PUT. It may result in the content being written as a complete
6689 replacement for the current representation.
6691 Partial resource updates are also possible by targeting a separately
6692 identified resource with state that overlaps or extends a portion of
6693 the larger resource, or by using a different method that has been
6694 specifically defined for partial updates (for example, the PATCH
6695 method defined in [RFC5789]).
669714.6. Media Type multipart/byteranges
6699 When a 206 (Partial Content) response message includes the content of
6700 multiple ranges, they are transmitted as body parts in a multipart
6701 message body ([RFC2046], Section 5.1) with the media type of
6702 "multipart/byteranges".
6704 The "multipart/byteranges" media type includes one or more body
6705 parts, each with its own Content-Type and Content-Range fields. The
6706 required boundary parameter specifies the boundary string used to
6707 separate each body part.
6709 Implementation Notes:
6711 1. Additional CRLFs might precede the first boundary string in the
6714 2. Although [RFC2046] permits the boundary string to be quoted, some
6715 existing implementations handle a quoted boundary string
6718 3. A number of clients and servers were coded to an early draft of
6719 the byteranges specification that used a media type of
6720 "multipart/x-byteranges", which is almost (but not quite)
6721 compatible with this type.
6723 Despite the name, the "multipart/byteranges" media type is not
6724 limited to byte ranges. The following example uses an "exampleunit"
6727 HTTP/1.1 206 Partial Content
6728 Date: Tue, 14 Nov 1995 06:25:24 GMT
6729 Last-Modified: Tue, 14 July 04:58:08 GMT
6730 Content-Length: 2331785
6731 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
6733 --THIS_STRING_SEPARATES
6734 Content-Type: video/example
6735 Content-Range: exampleunit 1.2-4.3/25
6737 ...the first range...
6738 --THIS_STRING_SEPARATES
6739 Content-Type: video/example
6740 Content-Range: exampleunit 11.2-14.3/25
6743 --THIS_STRING_SEPARATES--
6745 The following information serves as the registration form for the
6746 "multipart/byteranges" media type.
6748 Type name: multipart
6750 Subtype name: byteranges
6752 Required parameters: boundary
6754 Optional parameters: N/A
6756 Encoding considerations: only "7bit", "8bit", or "binary" are
6759 Security considerations: see Section 17
6761 Interoperability considerations: N/A
6763 Published specification: RFC 9110 (see Section 14.6)
6765 Applications that use this media type: HTTP components supporting
6766 multiple ranges in a single request
6768 Fragment identifier considerations: N/A
6770 Additional information: Deprecated alias names for this type: N/A
6772 Magic number(s): N/A
6774 File extension(s): N/A
6776 Macintosh file type code(s): N/A
6778 Person and email address to contact for further information: See Aut
6779 hors' Addresses section.
6781 Intended usage: COMMON
6783 Restrictions on usage: N/A
6785 Author: See Authors' Addresses section.
6787 Change controller: IESG
6791 The status code of a response is a three-digit integer code that
6792 describes the result of the request and the semantics of the
6793 response, including whether the request was successful and what
6794 content is enclosed (if any). All valid status codes are within the
6795 range of 100 to 599, inclusive.
6797 The first digit of the status code defines the class of response.
6798 The last two digits do not have any categorization role. There are
6799 five values for the first digit:
6801 * 1xx (Informational): The request was received, continuing process
6803 * 2xx (Successful): The request was successfully received,
6804 understood, and accepted
6806 * 3xx (Redirection): Further action needs to be taken in order to
6807 complete the request
6809 * 4xx (Client Error): The request contains bad syntax or cannot be
6812 * 5xx (Server Error): The server failed to fulfill an apparently
6815 HTTP status codes are extensible. A client is not required to
6816 understand the meaning of all registered status codes, though such
6817 understanding is obviously desirable. However, a client MUST
6818 understand the class of any status code, as indicated by the first
6819 digit, and treat an unrecognized status code as being equivalent to
6820 the x00 status code of that class.
6822 For example, if a client receives an unrecognized status code of 471,
6823 it can see from the first digit that there was something wrong with
6824 its request and treat the response as if it had received a 400 (Bad
6825 Request) status code. The response message will usually contain a
6826 representation that explains the status.
6828 Values outside the range 100..599 are invalid. Implementations often
6829 use three-digit integer values outside of that range (i.e., 600..999)
6830 for internal communication of non-HTTP status (e.g., library errors).
6831 A client that receives a response with an invalid status code SHOULD
6832 process the response as if it had a 5xx (Server Error) status code.
6834 A single request can have multiple associated responses: zero or more
6835 "interim" (non-final) responses with status codes in the
6836 "informational" (1xx) range, followed by exactly one "final" response
6837 with a status code in one of the other ranges.
683915.1. Overview of Status Codes
6841 The status codes listed below are defined in this specification. The
6842 reason phrases listed here are only recommendations -- they can be
6843 replaced by local equivalents or left out altogether without
6844 affecting the protocol.
6846 Responses with status codes that are defined as heuristically
6847 cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,
6848 414, and 501 in this specification) can be reused by a cache with
6849 heuristic expiration unless otherwise indicated by the method
6850 definition or explicit cache controls [CACHING]; all other status
6851 codes are not heuristically cacheable.
6853 Additional status codes, outside the scope of this specification,
6854 have been specified for use in HTTP. All such status codes ought to
6855 be registered within the "Hypertext Transfer Protocol (HTTP) Status
6856 Code Registry", as described in Section 16.2.
685815.2. Informational 1xx
6860 The 1xx (Informational) class of status code indicates an interim
6861 response for communicating connection status or request progress
6862 prior to completing the requested action and sending a final
6863 response. Since HTTP/1.0 did not define any 1xx status codes, a
6864 server MUST NOT send a 1xx response to an HTTP/1.0 client.
6866 A 1xx response is terminated by the end of the header section; it
6867 cannot contain content or trailers.
6869 A client MUST be able to parse one or more 1xx responses received
6870 prior to a final response, even if the client does not expect one. A
6871 user agent MAY ignore unexpected 1xx responses.
6873 A proxy MUST forward 1xx responses unless the proxy itself requested
6874 the generation of the 1xx response. For example, if a proxy adds an
6875 "Expect: 100-continue" header field when it forwards a request, then
6876 it need not forward the corresponding 100 (Continue) response(s).
6880 The 100 (Continue) status code indicates that the initial part of a
6881 request has been received and has not yet been rejected by the
6882 server. The server intends to send a final response after the
6883 request has been fully received and acted upon.
6885 When the request contains an Expect header field that includes a
6886 100-continue expectation, the 100 response indicates that the server
6887 wishes to receive the request content, as described in
6888 Section 10.1.1. The client ought to continue sending the request and
6889 discard the 100 response.
6891 If the request did not contain an Expect header field containing the
6892 100-continue expectation, the client can simply discard this interim
689515.2.2. 101 Switching Protocols
6897 The 101 (Switching Protocols) status code indicates that the server
6898 understands and is willing to comply with the client's request, via
6899 the Upgrade header field (Section 7.8), for a change in the
6900 application protocol being used on this connection. The server MUST
6901 generate an Upgrade header field in the response that indicates which
6902 protocol(s) will be in effect after this response.
6904 It is assumed that the server will only agree to switch protocols
6905 when it is advantageous to do so. For example, switching to a newer
6906 version of HTTP might be advantageous over older versions, and
6907 switching to a real-time, synchronous protocol might be advantageous
6908 when delivering resources that use such features.
6912 The 2xx (Successful) class of status code indicates that the client's
6913 request was successfully received, understood, and accepted.
6917 The 200 (OK) status code indicates that the request has succeeded.
6918 The content sent in a 200 response depends on the request method.
6919 For the methods defined by this specification, the intended meaning
6920 of the content can be summarized as:
6922 +================+============================================+
6923 | Request Method | Response content is a representation of: |
6924 +================+============================================+
6925 | GET | the target resource |
6926 +----------------+--------------------------------------------+
6927 | HEAD | the target resource, like GET, but without |
6928 | | transferring the representation data |
6929 +----------------+--------------------------------------------+
6930 | POST | the status of, or results obtained from, |
6932 +----------------+--------------------------------------------+
6933 | PUT, DELETE | the status of the action |
6934 +----------------+--------------------------------------------+
6935 | OPTIONS | communication options for the target |
6937 +----------------+--------------------------------------------+
6938 | TRACE | the request message as received by the |
6939 | | server returning the trace |
6940 +----------------+--------------------------------------------+
6944 Aside from responses to CONNECT, a 200 response is expected to
6945 contain message content unless the message framing explicitly
6946 indicates that the content has zero length. If some aspect of the
6947 request indicates a preference for no content upon success, the
6948 origin server ought to send a 204 (No Content) response instead. For
6949 CONNECT, there is no content because the successful result is a
6950 tunnel, which begins immediately after the 200 response header
6953 A 200 response is heuristically cacheable; i.e., unless otherwise
6954 indicated by the method definition or explicit cache controls (see
6955 Section 4.2.2 of [CACHING]).
6957 In 200 responses to GET or HEAD, an origin server SHOULD send any
6958 available validator fields (Section 8.8) for the selected
6959 representation, with both a strong entity tag and a Last-Modified
6960 date being preferred.
6962 In 200 responses to state-changing methods, any validator fields
6963 (Section 8.8) sent in the response convey the current validators for
6964 the new representation formed as a result of successfully applying
6965 the request semantics. Note that the PUT method (Section 9.3.4) has
6966 additional requirements that might preclude sending such validators.
6970 The 201 (Created) status code indicates that the request has been
6971 fulfilled and has resulted in one or more new resources being
6972 created. The primary resource created by the request is identified
6973 by either a Location header field in the response or, if no Location
6974 header field is received, by the target URI.
6976 The 201 response content typically describes and links to the
6977 resource(s) created. Any validator fields (Section 8.8) sent in the
6978 response convey the current validators for a new representation
6979 created by the request. Note that the PUT method (Section 9.3.4) has
6980 additional requirements that might preclude sending such validators.
6984 The 202 (Accepted) status code indicates that the request has been
6985 accepted for processing, but the processing has not been completed.
6986 The request might or might not eventually be acted upon, as it might
6987 be disallowed when processing actually takes place. There is no
6988 facility in HTTP for re-sending a status code from an asynchronous
6991 The 202 response is intentionally noncommittal. Its purpose is to
6992 allow a server to accept a request for some other process (perhaps a
6993 batch-oriented process that is only run once per day) without
6994 requiring that the user agent's connection to the server persist
6995 until the process is completed. The representation sent with this
6996 response ought to describe the request's current status and point to
6997 (or embed) a status monitor that can provide the user with an
6998 estimate of when the request will be fulfilled.
700015.3.4. 203 Non-Authoritative Information
7002 The 203 (Non-Authoritative Information) status code indicates that
7003 the request was successful but the enclosed content has been modified
7004 from that of the origin server's 200 (OK) response by a transforming
7005 proxy (Section 7.7). This status code allows the proxy to notify
7006 recipients when a transformation has been applied, since that
7007 knowledge might impact later decisions regarding the content. For
7008 example, future cache validation requests for the content might only
7009 be applicable along the same request path (through the same proxies).
7011 A 203 response is heuristically cacheable; i.e., unless otherwise
7012 indicated by the method definition or explicit cache controls (see
7013 Section 4.2.2 of [CACHING]).
701515.3.5. 204 No Content
7017 The 204 (No Content) status code indicates that the server has
7018 successfully fulfilled the request and that there is no additional
7019 content to send in the response content. Metadata in the response
7020 header fields refer to the target resource and its selected
7021 representation after the requested action was applied.
7023 For example, if a 204 status code is received in response to a PUT
7024 request and the response contains an ETag field, then the PUT was
7025 successful and the ETag field value contains the entity tag for the
7026 new representation of that target resource.
7028 The 204 response allows a server to indicate that the action has been
7029 successfully applied to the target resource, while implying that the
7030 user agent does not need to traverse away from its current "document
7031 view" (if any). The server assumes that the user agent will provide
7032 some indication of the success to its user, in accord with its own
7033 interface, and apply any new or updated metadata in the response to
7034 its active representation.
7036 For example, a 204 status code is commonly used with document editing
7037 interfaces corresponding to a "save" action, such that the document
7038 being saved remains available to the user for editing. It is also
7039 frequently used with interfaces that expect automated data transfers
7040 to be prevalent, such as within distributed version control systems.
7042 A 204 response is terminated by the end of the header section; it
7043 cannot contain content or trailers.
7045 A 204 response is heuristically cacheable; i.e., unless otherwise
7046 indicated by the method definition or explicit cache controls (see
7047 Section 4.2.2 of [CACHING]).
704915.3.6. 205 Reset Content
7051 The 205 (Reset Content) status code indicates that the server has
7052 fulfilled the request and desires that the user agent reset the
7053 "document view", which caused the request to be sent, to its original
7054 state as received from the origin server.
7056 This response is intended to support a common data entry use case
7057 where the user receives content that supports data entry (a form,
7058 notepad, canvas, etc.), enters or manipulates data in that space,
7059 causes the entered data to be submitted in a request, and then the
7060 data entry mechanism is reset for the next entry so that the user can
7061 easily initiate another input action.
7063 Since the 205 status code implies that no additional content will be
7064 provided, a server MUST NOT generate content in a 205 response.
706615.3.7. 206 Partial Content
7068 The 206 (Partial Content) status code indicates that the server is
7069 successfully fulfilling a range request for the target resource by
7070 transferring one or more parts of the selected representation.
7072 A server that supports range requests (Section 14) will usually
7073 attempt to satisfy all of the requested ranges, since sending less
7074 data will likely result in another client request for the remainder.
7075 However, a server might want to send only a subset of the data
7076 requested for reasons of its own, such as temporary unavailability,
7077 cache efficiency, load balancing, etc. Since a 206 response is self-
7078 descriptive, the client can still understand a response that only
7079 partially satisfies its range request.
7081 A client MUST inspect a 206 response's Content-Type and Content-Range
7082 field(s) to determine what parts are enclosed and whether additional
7083 requests are needed.
7085 A server that generates a 206 response MUST generate the following
7086 header fields, in addition to those required in the subsections
7087 below, if the field would have been sent in a 200 (OK) response to
7088 the same request: Date, Cache-Control, ETag, Expires,
7089 Content-Location, and Vary.
7091 A Content-Length header field present in a 206 response indicates the
7092 number of octets in the content of this message, which is usually not
7093 the complete length of the selected representation. Each
7094 Content-Range header field includes information about the selected
7095 representation's complete length.
7097 A sender that generates a 206 response to a request with an If-Range
7098 header field SHOULD NOT generate other representation header fields
7099 beyond those required because the client already has a prior response
7100 containing those header fields. Otherwise, a sender MUST generate
7101 all of the representation header fields that would have been sent in
7102 a 200 (OK) response to the same request.
7104 A 206 response is heuristically cacheable; i.e., unless otherwise
7105 indicated by explicit cache controls (see Section 4.2.2 of
710815.3.7.1. Single Part
7110 If a single part is being transferred, the server generating the 206
7111 response MUST generate a Content-Range header field, describing what
7112 range of the selected representation is enclosed, and a content
7113 consisting of the range. For example:
7115 HTTP/1.1 206 Partial Content
7116 Date: Wed, 15 Nov 1995 06:25:24 GMT
7117 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
7118 Content-Range: bytes 21010-47021/47022
7119 Content-Length: 26012
7120 Content-Type: image/gif
7122 ... 26012 bytes of partial image data ...
712415.3.7.2. Multiple Parts
7126 If multiple parts are being transferred, the server generating the
7127 206 response MUST generate "multipart/byteranges" content, as defined
7128 in Section 14.6, and a Content-Type header field containing the
7129 "multipart/byteranges" media type and its required boundary
7130 parameter. To avoid confusion with single-part responses, a server
7131 MUST NOT generate a Content-Range header field in the HTTP header
7132 section of a multiple part response (this field will be sent in each
7135 Within the header area of each body part in the multipart content,
7136 the server MUST generate a Content-Range header field corresponding
7137 to the range being enclosed in that body part. If the selected
7138 representation would have had a Content-Type header field in a 200
7139 (OK) response, the server SHOULD generate that same Content-Type
7140 header field in the header area of each body part. For example:
7142 HTTP/1.1 206 Partial Content
7143 Date: Wed, 15 Nov 1995 06:25:24 GMT
7144 Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
7145 Content-Length: 1741
7146 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
7148 --THIS_STRING_SEPARATES
7149 Content-Type: application/pdf
7150 Content-Range: bytes 500-999/8000
7152 ...the first range...
7153 --THIS_STRING_SEPARATES
7154 Content-Type: application/pdf
7155 Content-Range: bytes 7000-7999/8000
7158 --THIS_STRING_SEPARATES--
7160 When multiple ranges are requested, a server MAY coalesce any of the
7161 ranges that overlap, or that are separated by a gap that is smaller
7162 than the overhead of sending multiple parts, regardless of the order
7163 in which the corresponding range-spec appeared in the received Range
7164 header field. Since the typical overhead between each part of a
7165 "multipart/byteranges" is around 80 bytes, depending on the selected
7166 representation's media type and the chosen boundary parameter length,
7167 it can be less efficient to transfer many small disjoint parts than
7168 it is to transfer the entire selected representation.
7170 A server MUST NOT generate a multipart response to a request for a
7171 single range, since a client that does not request multiple parts
7172 might not support multipart responses. However, a server MAY
7173 generate a "multipart/byteranges" response with only a single body
7174 part if multiple ranges were requested and only one range was found
7175 to be satisfiable or only one range remained after coalescing. A
7176 client that cannot process a "multipart/byteranges" response MUST NOT
7177 generate a request that asks for multiple ranges.
7179 A server that generates a multipart response SHOULD send the parts in
7180 the same order that the corresponding range-spec appeared in the
7181 received Range header field, excluding those ranges that were deemed
7182 unsatisfiable or that were coalesced into other ranges. A client
7183 that receives a multipart response MUST inspect the Content-Range
7184 header field present in each body part in order to determine which
7185 range is contained in that body part; a client cannot rely on
7186 receiving the same ranges that it requested, nor the same order that
718915.3.7.3. Combining Parts
7191 A response might transfer only a subrange of a representation if the
7192 connection closed prematurely or if the request used one or more
7193 Range specifications. After several such transfers, a client might
7194 have received several ranges of the same representation. These
7195 ranges can only be safely combined if they all have in common the
7196 same strong validator (Section 8.8.1).
7198 A client that has received multiple partial responses to GET requests
7199 on a target resource MAY combine those responses into a larger
7200 continuous range if they share the same strong validator.
7202 If the most recent response is an incomplete 200 (OK) response, then
7203 the header fields of that response are used for any combined response
7204 and replace those of the matching stored responses.
7206 If the most recent response is a 206 (Partial Content) response and
7207 at least one of the matching stored responses is a 200 (OK), then the
7208 combined response header fields consist of the most recent 200
7209 response's header fields. If all of the matching stored responses
7210 are 206 responses, then the stored response with the most recent
7211 header fields is used as the source of header fields for the combined
7212 response, except that the client MUST use other header fields
7213 provided in the new response, aside from Content-Range, to replace
7214 all instances of the corresponding header fields in the stored
7217 The combined response content consists of the union of partial
7218 content ranges within the new response and all of the matching stored
7219 responses. If the union consists of the entire range of the
7220 representation, then the client MUST process the combined response as
7221 if it were a complete 200 (OK) response, including a Content-Length
7222 header field that reflects the complete length. Otherwise, the
7223 client MUST process the set of continuous ranges as one of the
7224 following: an incomplete 200 (OK) response if the combined response
7225 is a prefix of the representation, a single 206 (Partial Content)
7226 response containing "multipart/byteranges" content, or multiple 206
7227 (Partial Content) responses, each with one continuous range that is
7228 indicated by a Content-Range header field.
723015.4. Redirection 3xx
7232 The 3xx (Redirection) class of status code indicates that further
7233 action needs to be taken by the user agent in order to fulfill the
7234 request. There are several types of redirects:
7236 1. Redirects that indicate this resource might be available at a
7237 different URI, as provided by the Location header field, as in
7238 the status codes 301 (Moved Permanently), 302 (Found), 307
7239 (Temporary Redirect), and 308 (Permanent Redirect).
7241 2. Redirection that offers a choice among matching resources capable
7242 of representing this resource, as in the 300 (Multiple Choices)
7245 3. Redirection to a different resource, identified by the Location
7246 header field, that can represent an indirect response to the
7247 request, as in the 303 (See Other) status code.
7249 4. Redirection to a previously stored result, as in the 304 (Not
7250 Modified) status code.
7252 | *Note:* In HTTP/1.0, the status codes 301 (Moved Permanently)
7253 | and 302 (Found) were originally defined as method-preserving
7254 | ([HTTP/1.0], Section 9.3) to match their implementation at
7255 | CERN; 303 (See Other) was defined for a redirection that
7256 | changed its method to GET. However, early user agents split on
7257 | whether to redirect POST requests as POST (according to then-
7258 | current specification) or as GET (the safer alternative when
7259 | redirected to a different site). Prevailing practice
7260 | eventually converged on changing the method to GET. 307
7261 | (Temporary Redirect) and 308 (Permanent Redirect) [RFC7538]
7262 | were later added to unambiguously indicate method-preserving
7263 | redirects, and status codes 301 and 302 have been adjusted to
7264 | allow a POST request to be redirected as GET.
7266 If a Location header field (Section 10.2.2) is provided, the user
7267 agent MAY automatically redirect its request to the URI referenced by
7268 the Location field value, even if the specific status code is not
7269 understood. Automatic redirection needs to be done with care for
7270 methods not known to be safe, as defined in Section 9.2.1, since the
7271 user might not wish to redirect an unsafe request.
7273 When automatically following a redirected request, the user agent
7274 SHOULD resend the original request message with the following
7277 1. Replace the target URI with the URI referenced by the redirection
7278 response's Location header field value after resolving it
7279 relative to the original request's target URI.
7281 2. Remove header fields that were automatically generated by the
7282 implementation, replacing them with updated values as appropriate
7283 to the new request. This includes:
7285 1. Connection-specific header fields (see Section 7.6.1),
7287 2. Header fields specific to the client's proxy configuration,
7288 including (but not limited to) Proxy-Authorization,
7290 3. Origin-specific header fields (if any), including (but not
7293 4. Validating header fields that were added by the
7294 implementation's cache (e.g., If-None-Match,
7295 If-Modified-Since), and
7297 5. Resource-specific header fields, including (but not limited
7298 to) Referer, Origin, Authorization, and Cookie.
7300 3. Consider removing header fields that were not automatically
7301 generated by the implementation (i.e., those present in the
7302 request because they were added by the calling context) where
7303 there are security implications; this includes but is not limited
7304 to Authorization and Cookie.
7306 4. Change the request method according to the redirecting status
7307 code's semantics, if applicable.
7309 5. If the request method has been changed to GET or HEAD, remove
7310 content-specific header fields, including (but not limited to)
7311 Content-Encoding, Content-Language, Content-Location,
7312 Content-Type, Content-Length, Digest, Last-Modified.
7314 A client SHOULD detect and intervene in cyclical redirections (i.e.,
7315 "infinite" redirection loops).
7317 | *Note:* An earlier version of this specification recommended a
7318 | maximum of five redirections ([RFC2068], Section 10.3).
7319 | Content developers need to be aware that some clients might
7320 | implement such a fixed limitation.
732215.4.1. 300 Multiple Choices
7324 The 300 (Multiple Choices) status code indicates that the target
7325 resource has more than one representation, each with its own more
7326 specific identifier, and information about the alternatives is being
7327 provided so that the user (or user agent) can select a preferred
7328 representation by redirecting its request to one or more of those
7329 identifiers. In other words, the server desires that the user agent
7330 engage in reactive negotiation to select the most appropriate
7331 representation(s) for its needs (Section 12).
7333 If the server has a preferred choice, the server SHOULD generate a
7334 Location header field containing a preferred choice's URI reference.
7335 The user agent MAY use the Location field value for automatic
7338 For request methods other than HEAD, the server SHOULD generate
7339 content in the 300 response containing a list of representation
7340 metadata and URI reference(s) from which the user or user agent can
7341 choose the one most preferred. The user agent MAY make a selection
7342 from that list automatically if it understands the provided media
7343 type. A specific format for automatic selection is not defined by
7344 this specification because HTTP tries to remain orthogonal to the
7345 definition of its content. In practice, the representation is
7346 provided in some easily parsed format believed to be acceptable to
7347 the user agent, as determined by shared design or content
7348 negotiation, or in some commonly accepted hypertext format.
7350 A 300 response is heuristically cacheable; i.e., unless otherwise
7351 indicated by the method definition or explicit cache controls (see
7352 Section 4.2.2 of [CACHING]).
7354 | *Note:* The original proposal for the 300 status code defined
7355 | the URI header field as providing a list of alternative
7356 | representations, such that it would be usable for 200, 300, and
7357 | 406 responses and be transferred in responses to the HEAD
7358 | method. However, lack of deployment and disagreement over
7359 | syntax led to both URI and Alternates (a subsequent proposal)
7360 | being dropped from this specification. It is possible to
7361 | communicate the list as a Link header field value [RFC8288]
7362 | whose members have a relationship of "alternate", though
7363 | deployment is a chicken-and-egg problem.
736515.4.2. 301 Moved Permanently
7367 The 301 (Moved Permanently) status code indicates that the target
7368 resource has been assigned a new permanent URI and any future
7369 references to this resource ought to use one of the enclosed URIs.
7370 The server is suggesting that a user agent with link-editing
7371 capability can permanently replace references to the target URI with
7372 one of the new references sent by the server. However, this
7373 suggestion is usually ignored unless the user agent is actively
7374 editing references (e.g., engaged in authoring content), the
7375 connection is secured, and the origin server is a trusted authority
7376 for the content being edited.
7378 The server SHOULD generate a Location header field in the response
7379 containing a preferred URI reference for the new permanent URI. The
7380 user agent MAY use the Location field value for automatic
7381 redirection. The server's response content usually contains a short
7382 hypertext note with a hyperlink to the new URI(s).
7384 | *Note:* For historical reasons, a user agent MAY change the
7385 | request method from POST to GET for the subsequent request. If
7386 | this behavior is undesired, the 308 (Permanent Redirect) status
7387 | code can be used instead.
7389 A 301 response is heuristically cacheable; i.e., unless otherwise
7390 indicated by the method definition or explicit cache controls (see
7391 Section 4.2.2 of [CACHING]).
7395 The 302 (Found) status code indicates that the target resource
7396 resides temporarily under a different URI. Since the redirection
7397 might be altered on occasion, the client ought to continue to use the
7398 target URI for future requests.
7400 The server SHOULD generate a Location header field in the response
7401 containing a URI reference for the different URI. The user agent MAY
7402 use the Location field value for automatic redirection. The server's
7403 response content usually contains a short hypertext note with a
7404 hyperlink to the different URI(s).
7406 | *Note:* For historical reasons, a user agent MAY change the
7407 | request method from POST to GET for the subsequent request. If
7408 | this behavior is undesired, the 307 (Temporary Redirect) status
7409 | code can be used instead.
741115.4.4. 303 See Other
7413 The 303 (See Other) status code indicates that the server is
7414 redirecting the user agent to a different resource, as indicated by a
7415 URI in the Location header field, which is intended to provide an
7416 indirect response to the original request. A user agent can perform
7417 a retrieval request targeting that URI (a GET or HEAD request if
7418 using HTTP), which might also be redirected, and present the eventual
7419 result as an answer to the original request. Note that the new URI
7420 in the Location header field is not considered equivalent to the
7423 This status code is applicable to any HTTP method. It is primarily
7424 used to allow the output of a POST action to redirect the user agent
7425 to a different resource, since doing so provides the information
7426 corresponding to the POST response as a resource that can be
7427 separately identified, bookmarked, and cached.
7429 A 303 response to a GET request indicates that the origin server does
7430 not have a representation of the target resource that can be
7431 transferred by the server over HTTP. However, the Location field
7432 value refers to a resource that is descriptive of the target
7433 resource, such that making a retrieval request on that other resource
7434 might result in a representation that is useful to recipients without
7435 implying that it represents the original target resource. Note that
7436 answers to the questions of what can be represented, what
7437 representations are adequate, and what might be a useful description
7438 are outside the scope of HTTP.
7440 Except for responses to a HEAD request, the representation of a 303
7441 response ought to contain a short hypertext note with a hyperlink to
7442 the same URI reference provided in the Location header field.
744415.4.5. 304 Not Modified
7446 The 304 (Not Modified) status code indicates that a conditional GET
7447 or HEAD request has been received and would have resulted in a 200
7448 (OK) response if it were not for the fact that the condition
7449 evaluated to false. In other words, there is no need for the server
7450 to transfer a representation of the target resource because the
7451 request indicates that the client, which made the request
7452 conditional, already has a valid representation; the server is
7453 therefore redirecting the client to make use of that stored
7454 representation as if it were the content of a 200 (OK) response.
7456 The server generating a 304 response MUST generate any of the
7457 following header fields that would have been sent in a 200 (OK)
7458 response to the same request:
7460 * Content-Location, Date, ETag, and Vary
7462 * Cache-Control and Expires (see [CACHING])
7464 Since the goal of a 304 response is to minimize information transfer
7465 when the recipient already has one or more cached representations, a
7466 sender SHOULD NOT generate representation metadata other than the
7467 above listed fields unless said metadata exists for the purpose of
7468 guiding cache updates (e.g., Last-Modified might be useful if the
7469 response does not have an ETag field).
7471 Requirements on a cache that receives a 304 response are defined in
7472 Section 4.3.4 of [CACHING]. If the conditional request originated
7473 with an outbound client, such as a user agent with its own cache
7474 sending a conditional GET to a shared proxy, then the proxy SHOULD
7475 forward the 304 response to that client.
7477 A 304 response is terminated by the end of the header section; it
7478 cannot contain content or trailers.
748015.4.6. 305 Use Proxy
7482 The 305 (Use Proxy) status code was defined in a previous version of
7483 this specification and is now deprecated (Appendix B of [RFC7231]).
7487 The 306 status code was defined in a previous version of this
7488 specification, is no longer used, and the code is reserved.
749015.4.8. 307 Temporary Redirect
7492 The 307 (Temporary Redirect) status code indicates that the target
7493 resource resides temporarily under a different URI and the user agent
7494 MUST NOT change the request method if it performs an automatic
7495 redirection to that URI. Since the redirection can change over time,
7496 the client ought to continue using the original target URI for future
7499 The server SHOULD generate a Location header field in the response
7500 containing a URI reference for the different URI. The user agent MAY
7501 use the Location field value for automatic redirection. The server's
7502 response content usually contains a short hypertext note with a
7503 hyperlink to the different URI(s).
750515.4.9. 308 Permanent Redirect
7507 The 308 (Permanent Redirect) status code indicates that the target
7508 resource has been assigned a new permanent URI and any future
7509 references to this resource ought to use one of the enclosed URIs.
7510 The server is suggesting that a user agent with link-editing
7511 capability can permanently replace references to the target URI with
7512 one of the new references sent by the server. However, this
7513 suggestion is usually ignored unless the user agent is actively
7514 editing references (e.g., engaged in authoring content), the
7515 connection is secured, and the origin server is a trusted authority
7516 for the content being edited.
7518 The server SHOULD generate a Location header field in the response
7519 containing a preferred URI reference for the new permanent URI. The
7520 user agent MAY use the Location field value for automatic
7521 redirection. The server's response content usually contains a short
7522 hypertext note with a hyperlink to the new URI(s).
7524 A 308 response is heuristically cacheable; i.e., unless otherwise
7525 indicated by the method definition or explicit cache controls (see
7526 Section 4.2.2 of [CACHING]).
7528 | *Note:* This status code is much younger (June 2014) than its
7529 | sibling codes and thus might not be recognized everywhere. See
7530 | Section 4 of [RFC7538] for deployment considerations.
753215.5. Client Error 4xx
7534 The 4xx (Client Error) class of status code indicates that the client
7535 seems to have erred. Except when responding to a HEAD request, the
7536 server SHOULD send a representation containing an explanation of the
7537 error situation, and whether it is a temporary or permanent
7538 condition. These status codes are applicable to any request method.
7539 User agents SHOULD display any included representation to the user.
754115.5.1. 400 Bad Request
7543 The 400 (Bad Request) status code indicates that the server cannot or
7544 will not process the request due to something that is perceived to be
7545 a client error (e.g., malformed request syntax, invalid request
7546 message framing, or deceptive request routing).
754815.5.2. 401 Unauthorized
7550 The 401 (Unauthorized) status code indicates that the request has not
7551 been applied because it lacks valid authentication credentials for
7552 the target resource. The server generating a 401 response MUST send
7553 a WWW-Authenticate header field (Section 11.6.1) containing at least
7554 one challenge applicable to the target resource.
7556 If the request included authentication credentials, then the 401
7557 response indicates that authorization has been refused for those
7558 credentials. The user agent MAY repeat the request with a new or
7559 replaced Authorization header field (Section 11.6.2). If the 401
7560 response contains the same challenge as the prior response, and the
7561 user agent has already attempted authentication at least once, then
7562 the user agent SHOULD present the enclosed representation to the
7563 user, since it usually contains relevant diagnostic information.
756515.5.3. 402 Payment Required
7567 The 402 (Payment Required) status code is reserved for future use.
756915.5.4. 403 Forbidden
7571 The 403 (Forbidden) status code indicates that the server understood
7572 the request but refuses to fulfill it. A server that wishes to make
7573 public why the request has been forbidden can describe that reason in
7574 the response content (if any).
7576 If authentication credentials were provided in the request, the
7577 server considers them insufficient to grant access. The client
7578 SHOULD NOT automatically repeat the request with the same
7579 credentials. The client MAY repeat the request with new or different
7580 credentials. However, a request might be forbidden for reasons
7581 unrelated to the credentials.
7583 An origin server that wishes to "hide" the current existence of a
7584 forbidden target resource MAY instead respond with a status code of
758715.5.5. 404 Not Found
7589 The 404 (Not Found) status code indicates that the origin server did
7590 not find a current representation for the target resource or is not
7591 willing to disclose that one exists. A 404 status code does not
7592 indicate whether this lack of representation is temporary or
7593 permanent; the 410 (Gone) status code is preferred over 404 if the
7594 origin server knows, presumably through some configurable means, that
7595 the condition is likely to be permanent.
7597 A 404 response is heuristically cacheable; i.e., unless otherwise
7598 indicated by the method definition or explicit cache controls (see
7599 Section 4.2.2 of [CACHING]).
760115.5.6. 405 Method Not Allowed
7603 The 405 (Method Not Allowed) status code indicates that the method
7604 received in the request-line is known by the origin server but not
7605 supported by the target resource. The origin server MUST generate an
7606 Allow header field in a 405 response containing a list of the target
7607 resource's currently supported methods.
7609 A 405 response is heuristically cacheable; i.e., unless otherwise
7610 indicated by the method definition or explicit cache controls (see
7611 Section 4.2.2 of [CACHING]).
761315.5.7. 406 Not Acceptable
7615 The 406 (Not Acceptable) status code indicates that the target
7616 resource does not have a current representation that would be
7617 acceptable to the user agent, according to the proactive negotiation
7618 header fields received in the request (Section 12.1), and the server
7619 is unwilling to supply a default representation.
7621 The server SHOULD generate content containing a list of available
7622 representation characteristics and corresponding resource identifiers
7623 from which the user or user agent can choose the one most
7624 appropriate. A user agent MAY automatically select the most
7625 appropriate choice from that list. However, this specification does
7626 not define any standard for such automatic selection, as described in
762915.5.8. 407 Proxy Authentication Required
7631 The 407 (Proxy Authentication Required) status code is similar to 401
7632 (Unauthorized), but it indicates that the client needs to
7633 authenticate itself in order to use a proxy for this request. The
7634 proxy MUST send a Proxy-Authenticate header field (Section 11.7.1)
7635 containing a challenge applicable to that proxy for the request. The
7636 client MAY repeat the request with a new or replaced
7637 Proxy-Authorization header field (Section 11.7.2).
763915.5.9. 408 Request Timeout
7641 The 408 (Request Timeout) status code indicates that the server did
7642 not receive a complete request message within the time that it was
7645 If the client has an outstanding request in transit, it MAY repeat
7646 that request. If the current connection is not usable (e.g., as it
7647 would be in HTTP/1.1 because request delimitation is lost), a new
7648 connection will be used.
765015.5.10. 409 Conflict
7652 The 409 (Conflict) status code indicates that the request could not
7653 be completed due to a conflict with the current state of the target
7654 resource. This code is used in situations where the user might be
7655 able to resolve the conflict and resubmit the request. The server
7656 SHOULD generate content that includes enough information for a user
7657 to recognize the source of the conflict.
7659 Conflicts are most likely to occur in response to a PUT request. For
7660 example, if versioning were being used and the representation being
7661 PUT included changes to a resource that conflict with those made by
7662 an earlier (third-party) request, the origin server might use a 409
7663 response to indicate that it can't complete the request. In this
7664 case, the response representation would likely contain information
7665 useful for merging the differences based on the revision history.
7669 The 410 (Gone) status code indicates that access to the target
7670 resource is no longer available at the origin server and that this
7671 condition is likely to be permanent. If the origin server does not
7672 know, or has no facility to determine, whether or not the condition
7673 is permanent, the status code 404 (Not Found) ought to be used
7676 The 410 response is primarily intended to assist the task of web
7677 maintenance by notifying the recipient that the resource is
7678 intentionally unavailable and that the server owners desire that
7679 remote links to that resource be removed. Such an event is common
7680 for limited-time, promotional services and for resources belonging to
7681 individuals no longer associated with the origin server's site. It
7682 is not necessary to mark all permanently unavailable resources as
7683 "gone" or to keep the mark for any length of time -- that is left to
7684 the discretion of the server owner.
7686 A 410 response is heuristically cacheable; i.e., unless otherwise
7687 indicated by the method definition or explicit cache controls (see
7688 Section 4.2.2 of [CACHING]).
769015.5.12. 411 Length Required
7692 The 411 (Length Required) status code indicates that the server
7693 refuses to accept the request without a defined Content-Length
7694 (Section 8.6). The client MAY repeat the request if it adds a valid
7695 Content-Length header field containing the length of the request
769815.5.13. 412 Precondition Failed
7700 The 412 (Precondition Failed) status code indicates that one or more
7701 conditions given in the request header fields evaluated to false when
7702 tested on the server (Section 13). This response status code allows
7703 the client to place preconditions on the current resource state (its
7704 current representations and metadata) and, thus, prevent the request
7705 method from being applied if the target resource is in an unexpected
770815.5.14. 413 Content Too Large
7710 The 413 (Content Too Large) status code indicates that the server is
7711 refusing to process a request because the request content is larger
7712 than the server is willing or able to process. The server MAY
7713 terminate the request, if the protocol version in use allows it;
7714 otherwise, the server MAY close the connection.
7716 If the condition is temporary, the server SHOULD generate a
7717 Retry-After header field to indicate that it is temporary and after
7718 what time the client MAY try again.
772015.5.15. 414 URI Too Long
7722 The 414 (URI Too Long) status code indicates that the server is
7723 refusing to service the request because the target URI is longer than
7724 the server is willing to interpret. This rare condition is only
7725 likely to occur when a client has improperly converted a POST request
7726 to a GET request with long query information, when the client has
7727 descended into an infinite loop of redirection (e.g., a redirected
7728 URI prefix that points to a suffix of itself) or when the server is
7729 under attack by a client attempting to exploit potential security
7732 A 414 response is heuristically cacheable; i.e., unless otherwise
7733 indicated by the method definition or explicit cache controls (see
7734 Section 4.2.2 of [CACHING]).
773615.5.16. 415 Unsupported Media Type
7738 The 415 (Unsupported Media Type) status code indicates that the
7739 origin server is refusing to service the request because the content
7740 is in a format not supported by this method on the target resource.
7742 The format problem might be due to the request's indicated
7743 Content-Type or Content-Encoding, or as a result of inspecting the
7746 If the problem was caused by an unsupported content coding, the
7747 Accept-Encoding response header field (Section 12.5.3) ought to be
7748 used to indicate which (if any) content codings would have been
7749 accepted in the request.
7751 On the other hand, if the cause was an unsupported media type, the
7752 Accept response header field (Section 12.5.1) can be used to indicate
7753 which media types would have been accepted in the request.
775515.5.17. 416 Range Not Satisfiable
7757 The 416 (Range Not Satisfiable) status code indicates that the set of
7758 ranges in the request's Range header field (Section 14.2) has been
7759 rejected either because none of the requested ranges are satisfiable
7760 or because the client has requested an excessive number of small or
7761 overlapping ranges (a potential denial of service attack).
7763 Each range unit defines what is required for its own range sets to be
7764 satisfiable. For example, Section 14.1.2 defines what makes a bytes
7765 range set satisfiable.
7767 A server that generates a 416 response to a byte-range request SHOULD
7768 generate a Content-Range header field specifying the current length
7769 of the selected representation (Section 14.4).
7773 HTTP/1.1 416 Range Not Satisfiable
7774 Date: Fri, 20 Jan 2012 15:41:54 GMT
7775 Content-Range: bytes */47022
7777 | *Note:* Because servers are free to ignore Range, many
7778 | implementations will respond with the entire selected
7779 | representation in a 200 (OK) response. That is partly because
7780 | most clients are prepared to receive a 200 (OK) to complete the
7781 | task (albeit less efficiently) and partly because clients might
7782 | not stop making an invalid range request until they have
7783 | received a complete representation. Thus, clients cannot
7784 | depend on receiving a 416 (Range Not Satisfiable) response even
7785 | when it is most appropriate.
778715.5.18. 417 Expectation Failed
7789 The 417 (Expectation Failed) status code indicates that the
7790 expectation given in the request's Expect header field
7791 (Section 10.1.1) could not be met by at least one of the inbound
779415.5.19. 418 (Unused)
7796 [RFC2324] was an April 1 RFC that lampooned the various ways HTTP was
7797 abused; one such abuse was the definition of an application-specific
7798 418 status code, which has been deployed as a joke often enough for
7799 the code to be unusable for any future use.
7801 Therefore, the 418 status code is reserved in the IANA HTTP Status
7802 Code Registry. This indicates that the status code cannot be
7803 assigned to other applications currently. If future circumstances
7804 require its use (e.g., exhaustion of 4NN status codes), it can be re-
7805 assigned to another use.
780715.5.20. 421 Misdirected Request
7809 The 421 (Misdirected Request) status code indicates that the request
7810 was directed at a server that is unable or unwilling to produce an
7811 authoritative response for the target URI. An origin server (or
7812 gateway acting on behalf of the origin server) sends 421 to reject a
7813 target URI that does not match an origin for which the server has
7814 been configured (Section 4.3.1) or does not match the connection
7815 context over which the request was received (Section 7.4).
7817 A client that receives a 421 (Misdirected Request) response MAY retry
7818 the request, whether or not the request method is idempotent, over a
7819 different connection, such as a fresh connection specific to the
7820 target resource's origin, or via an alternative service [ALTSVC].
7822 A proxy MUST NOT generate a 421 response.
782415.5.21. 422 Unprocessable Content
7826 The 422 (Unprocessable Content) status code indicates that the server
7827 understands the content type of the request content (hence a 415
7828 (Unsupported Media Type) status code is inappropriate), and the
7829 syntax of the request content is correct, but it was unable to
7830 process the contained instructions. For example, this status code
7831 can be sent if an XML request content contains well-formed (i.e.,
7832 syntactically correct), but semantically erroneous XML instructions.
783415.5.22. 426 Upgrade Required
7836 The 426 (Upgrade Required) status code indicates that the server
7837 refuses to perform the request using the current protocol but might
7838 be willing to do so after the client upgrades to a different
7839 protocol. The server MUST send an Upgrade header field in a 426
7840 response to indicate the required protocol(s) (Section 7.8).
7844 HTTP/1.1 426 Upgrade Required
7848 Content-Type: text/plain
7850 This service requires use of the HTTP/3.0 protocol.
785215.6. Server Error 5xx
7854 The 5xx (Server Error) class of status code indicates that the server
7855 is aware that it has erred or is incapable of performing the
7856 requested method. Except when responding to a HEAD request, the
7857 server SHOULD send a representation containing an explanation of the
7858 error situation, and whether it is a temporary or permanent
7859 condition. A user agent SHOULD display any included representation
7860 to the user. These status codes are applicable to any request
786315.6.1. 500 Internal Server Error
7865 The 500 (Internal Server Error) status code indicates that the server
7866 encountered an unexpected condition that prevented it from fulfilling
786915.6.2. 501 Not Implemented
7871 The 501 (Not Implemented) status code indicates that the server does
7872 not support the functionality required to fulfill the request. This
7873 is the appropriate response when the server does not recognize the
7874 request method and is not capable of supporting it for any resource.
7876 A 501 response is heuristically cacheable; i.e., unless otherwise
7877 indicated by the method definition or explicit cache controls (see
7878 Section 4.2.2 of [CACHING]).
788015.6.3. 502 Bad Gateway
7882 The 502 (Bad Gateway) status code indicates that the server, while
7883 acting as a gateway or proxy, received an invalid response from an
7884 inbound server it accessed while attempting to fulfill the request.
788615.6.4. 503 Service Unavailable
7888 The 503 (Service Unavailable) status code indicates that the server
7889 is currently unable to handle the request due to a temporary overload
7890 or scheduled maintenance, which will likely be alleviated after some
7891 delay. The server MAY send a Retry-After header field
7892 (Section 10.2.3) to suggest an appropriate amount of time for the
7893 client to wait before retrying the request.
7895 | *Note:* The existence of the 503 status code does not imply
7896 | that a server has to use it when becoming overloaded. Some
7897 | servers might simply refuse the connection.
789915.6.5. 504 Gateway Timeout
7901 The 504 (Gateway Timeout) status code indicates that the server,
7902 while acting as a gateway or proxy, did not receive a timely response
7903 from an upstream server it needed to access in order to complete the
790615.6.6. 505 HTTP Version Not Supported
7908 The 505 (HTTP Version Not Supported) status code indicates that the
7909 server does not support, or refuses to support, the major version of
7910 HTTP that was used in the request message. The server is indicating
7911 that it is unable or unwilling to complete the request using the same
7912 major version as the client, as described in Section 2.5, other than
7913 with this error message. The server SHOULD generate a representation
7914 for the 505 response that describes why that version is not supported
7915 and what other protocols are supported by that server.
7919 HTTP defines a number of generic extension points that can be used to
7920 introduce capabilities to the protocol without introducing a new
7921 version, including methods, status codes, field names, and further
7922 extensibility points within defined fields, such as authentication
7923 schemes and cache directives (see Cache-Control extensions in
7924 Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not
7925 versioned, these extension points are persistent; the version of the
7926 protocol in use does not affect their semantics.
7928 Version-independent extensions are discouraged from depending on or
7929 interacting with the specific version of the protocol in use. When
7930 this is unavoidable, careful consideration needs to be given to how
7931 the extension can interoperate across versions.
7933 Additionally, specific versions of HTTP might have their own
7934 extensibility points, such as transfer codings in HTTP/1.1
7935 (Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types
7936 ([HTTP/2]). These extension points are specific to the version of
7937 the protocol they occur within.
7939 Version-specific extensions cannot override or modify the semantics
7940 of a version-independent mechanism or extension point (like a method
7941 or header field) without explicitly being allowed by that protocol
7942 element. For example, the CONNECT method (Section 9.3.6) allows
7945 These guidelines assure that the protocol operates correctly and
7946 predictably, even when parts of the path implement different versions
794916.1. Method Extensibility
795116.1.1. Method Registry
7953 The "Hypertext Transfer Protocol (HTTP) Method Registry", maintained
7954 by IANA at <https://www.iana.org/assignments/http-methods>, registers
7957 HTTP method registrations MUST include the following fields:
7959 * Method Name (see Section 9)
7961 * Safe ("yes" or "no", see Section 9.2.1)
7963 * Idempotent ("yes" or "no", see Section 9.2.2)
7965 * Pointer to specification text
7967 Values to be added to this namespace require IETF Review (see
7968 [RFC8126], Section 4.8).
797016.1.2. Considerations for New Methods
7972 Standardized methods are generic; that is, they are potentially
7973 applicable to any resource, not just one particular media type, kind
7974 of resource, or application. As such, it is preferred that new
7975 methods be registered in a document that isn't specific to a single
7976 application or data format, since orthogonal technologies deserve
7977 orthogonal specification.
7979 Since message parsing (Section 6) needs to be independent of method
7980 semantics (aside from responses to HEAD), definitions of new methods
7981 cannot change the parsing algorithm or prohibit the presence of
7982 content on either the request or the response message. Definitions
7983 of new methods can specify that only a zero-length content is allowed
7984 by requiring a Content-Length header field with a value of "0".
7986 Likewise, new methods cannot use the special host:port and asterisk
7987 forms of request target that are allowed for CONNECT and OPTIONS,
7988 respectively (Section 7.1). A full URI in absolute form is needed
7989 for the target URI, which means either the request target needs to be
7990 sent in absolute form or the target URI will be reconstructed from
7991 the request context in the same way it is for other methods.
7993 A new method definition needs to indicate whether it is safe
7994 (Section 9.2.1), idempotent (Section 9.2.2), cacheable
7995 (Section 9.2.3), what semantics are to be associated with the request
7996 content (if any), and what refinements the method makes to header
7997 field or status code semantics. If the new method is cacheable, its
7998 definition ought to describe how, and under what conditions, a cache
7999 can store a response and use it to satisfy a subsequent request. The
8000 new method ought to describe whether it can be made conditional
8001 (Section 13.1) and, if so, how a server responds when the condition
8002 is false. Likewise, if the new method might have some use for
8003 partial response semantics (Section 14.2), it ought to document this,
8006 | *Note:* Avoid defining a method name that starts with "M-",
8007 | since that prefix might be misinterpreted as having the
8008 | semantics assigned to it by [RFC2774].
801016.2. Status Code Extensibility
801216.2.1. Status Code Registry
8014 The "Hypertext Transfer Protocol (HTTP) Status Code Registry",
8015 maintained by IANA at <https://www.iana.org/assignments/http-status-
8016 codes>, registers status code numbers.
8018 A registration MUST include the following fields:
8020 * Status Code (3 digits)
8024 * Pointer to specification text
8026 Values to be added to the HTTP status code namespace require IETF
8027 Review (see [RFC8126], Section 4.8).
802916.2.2. Considerations for New Status Codes
8031 When it is necessary to express semantics for a response that are not
8032 defined by current status codes, a new status code can be registered.
8033 Status codes are generic; they are potentially applicable to any
8034 resource, not just one particular media type, kind of resource, or
8035 application of HTTP. As such, it is preferred that new status codes
8036 be registered in a document that isn't specific to a single
8039 New status codes are required to fall under one of the categories
8040 defined in Section 15. To allow existing parsers to process the
8041 response message, new status codes cannot disallow content, although
8042 they can mandate a zero-length content.
8044 Proposals for new status codes that are not yet widely deployed ought
8045 to avoid allocating a specific number for the code until there is
8046 clear consensus that it will be registered; instead, early drafts can
8047 use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
8048 class of the proposed status code(s) without consuming a number
8051 The definition of a new status code ought to explain the request
8052 conditions that would cause a response containing that status code
8053 (e.g., combinations of request header fields and/or method(s)) along
8054 with any dependencies on response header fields (e.g., what fields
8055 are required, what fields can modify the semantics, and what field
8056 semantics are further refined when used with the new status code).
8058 By default, a status code applies only to the request corresponding
8059 to the response it occurs within. If a status code applies to a
8060 larger scope of applicability -- for example, all requests to the
8061 resource in question or all requests to a server -- this must be
8062 explicitly specified. When doing so, it should be noted that not all
8063 clients can be expected to consistently apply a larger scope because
8064 they might not understand the new status code.
8066 The definition of a new final status code ought to specify whether or
8067 not it is heuristically cacheable. Note that any response with a
8068 final status code can be cached if the response has explicit
8069 freshness information. A status code defined as heuristically
8070 cacheable is allowed to be cached without explicit freshness
8071 information. Likewise, the definition of a status code can place
8072 constraints upon cache behavior if the must-understand cache
8073 directive is used. See [CACHING] for more information.
8075 Finally, the definition of a new status code ought to indicate
8076 whether the content has any implied association with an identified
8077 resource (Section 6.4.2).
807916.3. Field Extensibility
8081 HTTP's most widely used extensibility point is the definition of new
8082 header and trailer fields.
8084 New fields can be defined such that, when they are understood by a
8085 recipient, they override or enhance the interpretation of previously
8086 defined fields, define preconditions on request evaluation, or refine
8087 the meaning of responses.
8089 However, defining a field doesn't guarantee its deployment or
8090 recognition by recipients. Most fields are designed with the
8091 expectation that a recipient can safely ignore (but forward
8092 downstream) any field not recognized. In other cases, the sender's
8093 ability to understand a given field might be indicated by its prior
8094 communication, perhaps in the protocol version or fields that it sent
8095 in prior messages, or its use of a specific media type. Likewise,
8096 direct inspection of support might be possible through an OPTIONS
8097 request or by interacting with a defined well-known URI [RFC8615] if
8098 such inspection is defined along with the field being introduced.
810016.3.1. Field Name Registry
8102 The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines
8103 the namespace for HTTP field names.
8105 Any party can request registration of an HTTP field. See
8106 Section 16.3.2 for considerations to take into account when creating
8109 The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is
8110 located at <https://www.iana.org/assignments/http-fields/>.
8111 Registration requests can be made by following the instructions
8112 located there or by sending an email to the "ietf-http-wg@w3.org"
8115 Field names are registered on the advice of a designated expert
8116 (appointed by the IESG or their delegate). Fields with the status
8117 'permanent' are Specification Required ([RFC8126], Section 4.6).
8119 Registration requests consist of the following information:
8122 The requested field name. It MUST conform to the field-name
8123 syntax defined in Section 5.1, and it SHOULD be restricted to just
8124 letters, digits, and hyphen ('-') characters, with the first
8125 character being a letter.
8128 "permanent", "provisional", "deprecated", or "obsoleted".
8130 Specification document(s):
8131 Reference to the document that specifies the field, preferably
8132 including a URI that can be used to retrieve a copy of the
8133 document. Optional but encouraged for provisional registrations.
8134 An indication of the relevant section(s) can also be included, but
8139 Comments: Additional information, such as about reserved entries.
8141 The expert(s) can define additional fields to be collected in the
8142 registry, in consultation with the community.
8144 Standards-defined names have a status of "permanent". Other names
8145 can also be registered as permanent if the expert(s) finds that they
8146 are in use, in consultation with the community. Other names should
8147 be registered as "provisional".
8149 Provisional entries can be removed by the expert(s) if -- in
8150 consultation with the community -- the expert(s) find that they are
8151 not in use. The expert(s) can change a provisional entry's status to
8152 permanent at any time.
8154 Note that names can be registered by third parties (including the
8155 expert(s)) if the expert(s) determines that an unregistered name is
8156 widely deployed and not likely to be registered in a timely manner
815916.3.2. Considerations for New Fields
8161 HTTP header and trailer fields are a widely used extension point for
8162 the protocol. While they can be used in an ad hoc fashion, fields
8163 that are intended for wider use need to be carefully documented to
8164 ensure interoperability.
8166 In particular, authors of specifications defining new fields are
8167 advised to consider and, where appropriate, document the following
8170 * Under what conditions the field can be used; e.g., only in
8171 responses or requests, in all messages, only on responses to a
8172 particular request method, etc.
8174 * Whether the field semantics are further refined by their context,
8175 such as their use with certain request methods or status codes.
8177 * The scope of applicability for the information conveyed. By
8178 default, fields apply only to the message they are associated
8179 with, but some response fields are designed to apply to all
8180 representations of a resource, the resource itself, or an even
8181 broader scope. Specifications that expand the scope of a response
8182 field will need to carefully consider issues such as content
8183 negotiation, the time period of applicability, and (in some cases)
8184 multi-tenant server deployments.
8186 * Under what conditions intermediaries are allowed to insert,
8187 delete, or modify the field's value.
8189 * If the field is allowable in trailers; by default, it will not be
8190 (see Section 6.5.1).
8192 * Whether it is appropriate or even required to list the field name
8193 in the Connection header field (i.e., if the field is to be hop-
8194 by-hop; see Section 7.6.1).
8196 * Whether the field introduces any additional security
8197 considerations, such as disclosure of privacy-related data.
8199 Request header fields have additional considerations that need to be
8200 documented if the default behavior is not appropriate:
8202 * If it is appropriate to list the field name in a Vary response
8203 header field (e.g., when the request header field is used by an
8204 origin server's content selection algorithm; see Section 12.5.5).
8206 * If the field is intended to be stored when received in a PUT
8207 request (see Section 9.3.4).
8209 * If the field ought to be removed when automatically redirecting a
8210 request due to security concerns (see Section 15.4).
821216.3.2.1. Considerations for New Field Names
8214 Authors of specifications defining new fields are advised to choose a
8215 short but descriptive field name. Short names avoid needless data
8216 transmission; descriptive names avoid confusion and "squatting" on
8217 names that might have broader uses.
8219 To that end, limited-use fields (such as a header confined to a
8220 single application or use case) are encouraged to use a name that
8221 includes that use (or an abbreviation) as a prefix; for example, if
8222 the Foo Application needs a Description field, it might use "Foo-
8223 Desc"; "Description" is too generic, and "Foo-Description" is
8226 While the field-name syntax is defined to allow any token character,
8227 in practice some implementations place limits on the characters they
8228 accept in field-names. To be interoperable, new field names SHOULD
8229 constrain themselves to alphanumeric characters, "-", and ".", and
8230 SHOULD begin with a letter. For example, the underscore ("_")
8231 character can be problematic when passed through non-HTTP gateway
8232 interfaces (see Section 17.10).
8234 Field names ought not be prefixed with "X-"; see [BCP178] for further
8237 Other prefixes are sometimes used in HTTP field names; for example,
8238 "Accept-" is used in many content negotiation headers, and "Content-"
8239 is used as explained in Section 6.4. These prefixes are only an aid
8240 to recognizing the purpose of a field and do not trigger automatic
824316.3.2.2. Considerations for New Field Values
8245 A major task in the definition of a new HTTP field is the
8246 specification of the field value syntax: what senders should
8247 generate, and how recipients should infer semantics from what is
8250 Authors are encouraged (but not required) to use either the ABNF
8251 rules in this specification or those in [RFC8941] to define the
8252 syntax of new field values.
8254 Authors are advised to carefully consider how the combination of
8255 multiple field lines will impact them (see Section 5.3). Because
8256 senders might erroneously send multiple values, and both
8257 intermediaries and HTTP libraries can perform combination
8258 automatically, this applies to all field values -- even when only a
8259 single value is anticipated.
8261 Therefore, authors are advised to delimit or encode values that
8262 contain commas (e.g., with the quoted-string rule of Section 5.6.4,
8263 the String data type of [RFC8941], or a field-specific encoding).
8264 This ensures that commas within field data are not confused with the
8265 commas that delimit a list value.
8267 For example, the Content-Type field value only allows commas inside
8268 quoted strings, which can be reliably parsed even when multiple
8269 values are present. The Location field value provides a counter-
8270 example that should not be emulated: because URIs can include commas,
8271 it is not possible to reliably distinguish between a single value
8272 that includes a comma from two values.
8274 Authors of fields with a singleton value (see Section 5.5) are
8275 additionally advised to document how to treat messages where the
8276 multiple members are present (a sensible default would be to ignore
8277 the field, but this might not always be the right choice).
827916.4. Authentication Scheme Extensibility
828116.4.1. Authentication Scheme Registry
8283 The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
8284 Registry" defines the namespace for the authentication schemes in
8285 challenges and credentials. It is maintained at
8286 <https://www.iana.org/assignments/http-authschemes>.
8288 Registrations MUST include the following fields:
8290 * Authentication Scheme Name
8292 * Pointer to specification text
8296 Values to be added to this namespace require IETF Review (see
8297 [RFC8126], Section 4.8).
829916.4.2. Considerations for New Authentication Schemes
8301 There are certain aspects of the HTTP Authentication framework that
8302 put constraints on how new authentication schemes can work:
8304 * HTTP authentication is presumed to be stateless: all of the
8305 information necessary to authenticate a request MUST be provided
8306 in the request, rather than be dependent on the server remembering
8307 prior requests. Authentication based on, or bound to, the
8308 underlying connection is outside the scope of this specification
8309 and inherently flawed unless steps are taken to ensure that the
8310 connection cannot be used by any party other than the
8311 authenticated user (see Section 3.3).
8313 * The authentication parameter "realm" is reserved for defining
8314 protection spaces as described in Section 11.5. New schemes MUST
8315 NOT use it in a way incompatible with that definition.
8317 * The "token68" notation was introduced for compatibility with
8318 existing authentication schemes and can only be used once per
8319 challenge or credential. Thus, new schemes ought to use the auth-
8320 param syntax instead, because otherwise future extensions will be
8323 * The parsing of challenges and credentials is defined by this
8324 specification and cannot be modified by new authentication
8325 schemes. When the auth-param syntax is used, all parameters ought
8326 to support both token and quoted-string syntax, and syntactical
8327 constraints ought to be defined on the field value after parsing
8328 (i.e., quoted-string processing). This is necessary so that
8329 recipients can use a generic parser that applies to all
8330 authentication schemes.
8332 *Note:* The fact that the value syntax for the "realm" parameter
8333 is restricted to quoted-string was a bad design choice not to be
8334 repeated for new parameters.
8336 * Definitions of new schemes ought to define the treatment of
8337 unknown extension parameters. In general, a "must-ignore" rule is
8338 preferable to a "must-understand" rule, because otherwise it will
8339 be hard to introduce new parameters in the presence of legacy
8340 recipients. Furthermore, it's good to describe the policy for
8341 defining new parameters (such as "update the specification" or
8342 "use this registry").
8344 * Authentication schemes need to document whether they are usable in
8345 origin-server authentication (i.e., using WWW-Authenticate), and/
8346 or proxy authentication (i.e., using Proxy-Authenticate).
8348 * The credentials carried in an Authorization header field are
8349 specific to the user agent and, therefore, have the same effect on
8350 HTTP caches as the "private" cache response directive
8351 (Section 5.2.2.7 of [CACHING]), within the scope of the request in
8354 Therefore, new authentication schemes that choose not to carry
8355 credentials in the Authorization header field (e.g., using a newly
8356 defined header field) will need to explicitly disallow caching, by
8357 mandating the use of cache response directives (e.g., "private").
8359 * Schemes using Authentication-Info, Proxy-Authentication-Info, or
8360 any other authentication related response header field need to
8361 consider and document the related security considerations (see
836416.5. Range Unit Extensibility
836616.5.1. Range Unit Registry
8368 The "HTTP Range Unit Registry" defines the namespace for the range
8369 unit names and refers to their corresponding specifications. It is
8370 maintained at <https://www.iana.org/assignments/http-parameters>.
8372 Registration of an HTTP Range Unit MUST include the following fields:
8378 * Pointer to specification text
8380 Values to be added to this namespace require IETF Review (see
8381 [RFC8126], Section 4.8).
838316.5.2. Considerations for New Range Units
8385 Other range units, such as format-specific boundaries like pages,
8386 sections, records, rows, or time, are potentially usable in HTTP for
8387 application-specific purposes, but are not commonly used in practice.
8388 Implementors of alternative range units ought to consider how they
8389 would work with content codings and general-purpose intermediaries.
839116.6. Content Coding Extensibility
839316.6.1. Content Coding Registry
8395 The "HTTP Content Coding Registry", maintained by IANA at
8396 <https://www.iana.org/assignments/http-parameters/>, registers
8397 content-coding names.
8399 Content coding registrations MUST include the following fields:
8405 * Pointer to specification text
8407 Names of content codings MUST NOT overlap with names of transfer
8408 codings (per the "HTTP Transfer Coding Registry" located at
8409 <https://www.iana.org/assignments/http-parameters/>) unless the
8410 encoding transformation is identical (as is the case for the
8411 compression codings defined in Section 8.4.1).
8413 Values to be added to this namespace require IETF Review (see
8414 Section 4.8 of [RFC8126]) and MUST conform to the purpose of content
8415 coding defined in Section 8.4.1.
841716.6.2. Considerations for New Content Codings
8419 New content codings ought to be self-descriptive whenever possible,
8420 with optional parameters discoverable within the coding format
8421 itself, rather than rely on external metadata that might be lost
842416.7. Upgrade Token Registry
8426 The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
8427 defines the namespace for protocol-name tokens used to identify
8428 protocols in the Upgrade header field. The registry is maintained at
8429 <https://www.iana.org/assignments/http-upgrade-tokens>.
8431 Each registered protocol name is associated with contact information
8432 and an optional set of specifications that details how the connection
8433 will be processed after it has been upgraded.
8435 Registrations happen on a "First Come First Served" basis (see
8436 Section 4.4 of [RFC8126]) and are subject to the following rules:
8438 1. A protocol-name token, once registered, stays registered forever.
8440 2. A protocol-name token is case-insensitive and registered with the
8441 preferred case to be generated by senders.
8443 3. The registration MUST name a responsible party for the
8446 4. The registration MUST name a point of contact.
8448 5. The registration MAY name a set of specifications associated with
8449 that token. Such specifications need not be publicly available.
8451 6. The registration SHOULD name a set of expected "protocol-version"
8452 tokens associated with that token at the time of registration.
8454 7. The responsible party MAY change the registration at any time.
8455 The IANA will keep a record of all such changes, and make them
8456 available upon request.
8458 8. The IESG MAY reassign responsibility for a protocol token. This
8459 will normally only be used in the case when a responsible party
8460 cannot be contacted.
846217. Security Considerations
8464 This section is meant to inform developers, information providers,
8465 and users of known security concerns relevant to HTTP semantics and
8466 its use for transferring information over the Internet.
8467 Considerations related to caching are discussed in Section 7 of
8468 [CACHING], and considerations related to HTTP/1.1 message syntax and
8469 parsing are discussed in Section 11 of [HTTP/1.1].
8471 The list of considerations below is not exhaustive. Most security
8472 concerns related to HTTP semantics are about securing server-side
8473 applications (code behind the HTTP interface), securing user agent
8474 processing of content received via HTTP, or secure use of the
8475 Internet in general, rather than security of the protocol. The
8476 security considerations for URIs, which are fundamental to HTTP
8477 operation, are discussed in Section 7 of [URI]. Various
8478 organizations maintain topical information and links to current
8479 research on Web application security (e.g., [OWASP]).
848117.1. Establishing Authority
8483 HTTP relies on the notion of an "authoritative response": a response
8484 that has been determined by (or at the direction of) the origin
8485 server identified within the target URI to be the most appropriate
8486 response for that request given the state of the target resource at
8487 the time of response message origination.
8489 When a registered name is used in the authority component, the "http"
8490 URI scheme (Section 4.2.1) relies on the user's local name resolution
8491 service to determine where it can find authoritative responses. This
8492 means that any attack on a user's network host table, cached names,
8493 or name resolution libraries becomes an avenue for attack on
8494 establishing authority for "http" URIs. Likewise, the user's choice
8495 of server for Domain Name Service (DNS), and the hierarchy of servers
8496 from which it obtains resolution results, could impact the
8497 authenticity of address mappings; DNS Security Extensions (DNSSEC,
8498 [RFC4033]) are one way to improve authenticity, as are the various
8499 mechanisms for making DNS requests over more secure transfer
8502 Furthermore, after an IP address is obtained, establishing authority
8503 for an "http" URI is vulnerable to attacks on Internet Protocol
8506 The "https" scheme (Section 4.2.2) is intended to prevent (or at
8507 least reveal) many of these potential attacks on establishing
8508 authority, provided that the negotiated connection is secured and the
8509 client properly verifies that the communicating server's identity
8510 matches the target URI's authority component (Section 4.3.4).
8511 Correctly implementing such verification can be difficult (see
8514 Authority for a given origin server can be delegated through protocol
8515 extensions; for example, [ALTSVC]. Likewise, the set of servers for
8516 which a connection is considered authoritative can be changed with a
8517 protocol extension like [RFC8336].
8519 Providing a response from a non-authoritative source, such as a
8520 shared proxy cache, is often useful to improve performance and
8521 availability, but only to the extent that the source can be trusted
8522 or the distrusted response can be safely used.
8524 Unfortunately, communicating authority to users can be difficult.
8525 For example, "phishing" is an attack on the user's perception of
8526 authority, where that perception can be misled by presenting similar
8527 branding in hypertext, possibly aided by userinfo obfuscating the
8528 authority component (see Section 4.2.1). User agents can reduce the
8529 impact of phishing attacks by enabling users to easily inspect a
8530 target URI prior to making an action, by prominently distinguishing
8531 (or rejecting) userinfo when present, and by not sending stored
8532 credentials and cookies when the referring document is from an
8533 unknown or untrusted source.
853517.2. Risks of Intermediaries
8537 HTTP intermediaries are inherently situated for on-path attacks.
8538 Compromise of the systems on which the intermediaries run can result
8539 in serious security and privacy problems. Intermediaries might have
8540 access to security-related information, personal information about
8541 individual users and organizations, and proprietary information
8542 belonging to users and content providers. A compromised
8543 intermediary, or an intermediary implemented or configured without
8544 regard to security and privacy considerations, might be used in the
8545 commission of a wide range of potential attacks.
8547 Intermediaries that contain a shared cache are especially vulnerable
8548 to cache poisoning attacks, as described in Section 7 of [CACHING].
8550 Implementers need to consider the privacy and security implications
8551 of their design and coding decisions, and of the configuration
8552 options they provide to operators (especially the default
8555 Intermediaries are no more trustworthy than the people and policies
8556 under which they operate; HTTP cannot solve this problem.
855817.3. Attacks Based on File and Path Names
8560 Origin servers frequently make use of their local file system to
8561 manage the mapping from target URI to resource representations. Most
8562 file systems are not designed to protect against malicious file or
8563 path names. Therefore, an origin server needs to avoid accessing
8564 names that have a special significance to the system when mapping the
8565 target resource to files, folders, or directories.
8567 For example, UNIX, Microsoft Windows, and other operating systems use
8568 ".." as a path component to indicate a directory level above the
8569 current one, and they use specially named paths or file names to send
8570 data to system devices. Similar naming conventions might exist
8571 within other types of storage systems. Likewise, local storage
8572 systems have an annoying tendency to prefer user-friendliness over
8573 security when handling invalid or unexpected characters,
8574 recomposition of decomposed characters, and case-normalization of
8575 case-insensitive names.
8577 Attacks based on such special names tend to focus on either denial-
8578 of-service (e.g., telling the server to read from a COM port) or
8579 disclosure of configuration and source files that are not meant to be
858217.4. Attacks Based on Command, Code, or Query Injection
8584 Origin servers often use parameters within the URI as a means of
8585 identifying system services, selecting database entries, or choosing
8586 a data source. However, data received in a request cannot be
8587 trusted. An attacker could construct any of the request data
8588 elements (method, target URI, header fields, or content) to contain
8589 data that might be misinterpreted as a command, code, or query when
8590 passed through a command invocation, language interpreter, or
8593 For example, SQL injection is a common attack wherein additional
8594 query language is inserted within some part of the target URI or
8595 header fields (e.g., Host, Referer, etc.). If the received data is
8596 used directly within a SELECT statement, the query language might be
8597 interpreted as a database command instead of a simple string value.
8598 This type of implementation vulnerability is extremely common, in
8599 spite of being easy to prevent.
8601 In general, resource implementations ought to avoid use of request
8602 data in contexts that are processed or interpreted as instructions.
8603 Parameters ought to be compared to fixed strings and acted upon as a
8604 result of that comparison, rather than passed through an interface
8605 that is not prepared for untrusted data. Received data that isn't
8606 based on fixed parameters ought to be carefully filtered or encoded
8607 to avoid being misinterpreted.
8609 Similar considerations apply to request data when it is stored and
8610 later processed, such as within log files, monitoring tools, or when
8611 included within a data format that allows embedded scripts.
861317.5. Attacks via Protocol Element Length
8615 Because HTTP uses mostly textual, character-delimited fields, parsers
8616 are often vulnerable to attacks based on sending very long (or very
8617 slow) streams of data, particularly where an implementation is
8618 expecting a protocol element with no predefined length (Section 2.3).
8620 To promote interoperability, specific recommendations are made for
8621 minimum size limits on fields (Section 5.4). These are minimum
8622 recommendations, chosen to be supportable even by implementations
8623 with limited resources; it is expected that most implementations will
8624 choose substantially higher limits.
8626 A server can reject a message that has a target URI that is too long
8627 (Section 15.5.15) or request content that is too large
8628 (Section 15.5.14). Additional status codes related to capacity
8629 limits have been defined by extensions to HTTP [RFC6585].
8631 Recipients ought to carefully limit the extent to which they process
8632 other protocol elements, including (but not limited to) request
8633 methods, response status phrases, field names, numeric values, and
8634 chunk lengths. Failure to limit such processing can result in
8635 arbitrary code execution due to buffer or arithmetic overflows, and
8636 increased vulnerability to denial-of-service attacks.
863817.6. Attacks Using Shared-Dictionary Compression
8640 Some attacks on encrypted protocols use the differences in size
8641 created by dynamic compression to reveal confidential information;
8642 for example, [BREACH]. These attacks rely on creating a redundancy
8643 between attacker-controlled content and the confidential information,
8644 such that a dynamic compression algorithm using the same dictionary
8645 for both content will compress more efficiently when the attacker-
8646 controlled content matches parts of the confidential content.
8648 HTTP messages can be compressed in a number of ways, including using
8649 TLS compression, content codings, transfer codings, and other
8650 extension or version-specific mechanisms.
8652 The most effective mitigation for this risk is to disable compression
8653 on sensitive data, or to strictly separate sensitive data from
8654 attacker-controlled data so that they cannot share the same
8655 compression dictionary. With careful design, a compression scheme
8656 can be designed in a way that is not considered exploitable in
8657 limited use cases, such as HPACK ([HPACK]).
865917.7. Disclosure of Personal Information
8661 Clients are often privy to large amounts of personal information,
8662 including both information provided by the user to interact with
8663 resources (e.g., the user's name, location, mail address, passwords,
8664 encryption keys, etc.) and information about the user's browsing
8665 activity over time (e.g., history, bookmarks, etc.). Implementations
8666 need to prevent unintentional disclosure of personal information.
866817.8. Privacy of Server Log Information
8670 A server is in the position to save personal data about a user's
8671 requests over time, which might identify their reading patterns or
8672 subjects of interest. In particular, log information gathered at an
8673 intermediary often contains a history of user agent interaction,
8674 across a multitude of sites, that can be traced to individual users.
8676 HTTP log information is confidential in nature; its handling is often
8677 constrained by laws and regulations. Log information needs to be
8678 securely stored and appropriate guidelines followed for its analysis.
8679 Anonymization of personal information within individual entries
8680 helps, but it is generally not sufficient to prevent real log traces
8681 from being re-identified based on correlation with other access
8682 characteristics. As such, access traces that are keyed to a specific
8683 client are unsafe to publish even if the key is pseudonymous.
8685 To minimize the risk of theft or accidental publication, log
8686 information ought to be purged of personally identifiable
8687 information, including user identifiers, IP addresses, and user-
8688 provided query parameters, as soon as that information is no longer
8689 necessary to support operational needs for security, auditing, or
869217.9. Disclosure of Sensitive Information in URIs
8694 URIs are intended to be shared, not secured, even when they identify
8695 secure resources. URIs are often shown on displays, added to
8696 templates when a page is printed, and stored in a variety of
8697 unprotected bookmark lists. Many servers, proxies, and user agents
8698 log or display the target URI in places where it might be visible to
8699 third parties. It is therefore unwise to include information within
8700 a URI that is sensitive, personally identifiable, or a risk to
8703 When an application uses client-side mechanisms to construct a target
8704 URI out of user-provided information, such as the query fields of a
8705 form using GET, potentially sensitive data might be provided that
8706 would not be appropriate for disclosure within a URI. POST is often
8707 preferred in such cases because it usually doesn't construct a URI;
8708 instead, POST of a form transmits the potentially sensitive data in
8709 the request content. However, this hinders caching and uses an
8710 unsafe method for what would otherwise be a safe request.
8711 Alternative workarounds include transforming the user-provided data
8712 prior to constructing the URI or filtering the data to only include
8713 common values that are not sensitive. Likewise, redirecting the
8714 result of a query to a different (server-generated) URI can remove
8715 potentially sensitive data from later links and provide a cacheable
8716 response for later reuse.
8718 Since the Referer header field tells a target site about the context
8719 that resulted in a request, it has the potential to reveal
8720 information about the user's immediate browsing history and any
8721 personal information that might be found in the referring resource's
8722 URI. Limitations on the Referer header field are described in
8723 Section 10.1.3 to address some of its security considerations.
872517.10. Application Handling of Field Names
8727 Servers often use non-HTTP gateway interfaces and frameworks to
8728 process a received request and produce content for the response. For
8729 historical reasons, such interfaces often pass received field names
8730 as external variable names, using a name mapping suitable for
8731 environment variables.
8733 For example, the Common Gateway Interface (CGI) mapping of protocol-
8734 specific meta-variables, defined by Section 4.1.18 of [RFC3875], is
8735 applied to received header fields that do not correspond to one of
8736 CGI's standard variables; the mapping consists of prepending "HTTP_"
8737 to each name and changing all instances of hyphen ("-") to underscore
8738 ("_"). This same mapping has been inherited by many other
8739 application frameworks in order to simplify moving applications from
8740 one platform to the next.
8742 In CGI, a received Content-Length field would be passed as the meta-
8743 variable "CONTENT_LENGTH" with a string value matching the received
8744 field's value. In contrast, a received "Content_Length" header field
8745 would be passed as the protocol-specific meta-variable
8746 "HTTP_CONTENT_LENGTH", which might lead to some confusion if an
8747 application mistakenly reads the protocol-specific meta-variable
8748 instead of the default one. (This historical practice is why
8749 Section 16.3.2.1 discourages the creation of new field names that
8750 contain an underscore.)
8752 Unfortunately, mapping field names to different interface names can
8753 lead to security vulnerabilities if the mapping is incomplete or
8754 ambiguous. For example, if an attacker were to send a field named
8755 "Transfer_Encoding", a naive interface might map that to the same
8756 variable name as the "Transfer-Encoding" field, resulting in a
8757 potential request smuggling vulnerability (Section 11.2 of
8760 To mitigate the associated risks, implementations that perform such
8761 mappings are advised to make the mapping unambiguous and complete for
8762 the full range of potential octets received as a name (including
8763 those that are discouraged or forbidden by the HTTP grammar). For
8764 example, a field with an unusual name character might result in the
8765 request being blocked, the specific field being removed, or the name
8766 being passed with a different prefix to distinguish it from other
876917.11. Disclosure of Fragment after Redirects
8771 Although fragment identifiers used within URI references are not sent
8772 in requests, implementers ought to be aware that they will be visible
8773 to the user agent and any extensions or scripts running as a result
8774 of the response. In particular, when a redirect occurs and the
8775 original request's fragment identifier is inherited by the new
8776 reference in Location (Section 10.2.2), this might have the effect of
8777 disclosing one site's fragment to another site. If the first site
8778 uses personal information in fragments, it ought to ensure that
8779 redirects to other sites include a (possibly empty) fragment
8780 component in order to block that inheritance.
878217.12. Disclosure of Product Information
8784 The User-Agent (Section 10.1.5), Via (Section 7.6.3), and Server
8785 (Section 10.2.4) header fields often reveal information about the
8786 respective sender's software systems. In theory, this can make it
8787 easier for an attacker to exploit known security holes; in practice,
8788 attackers tend to try all potential holes regardless of the apparent
8789 software versions being used.
8791 Proxies that serve as a portal through a network firewall ought to
8792 take special precautions regarding the transfer of header information
8793 that might identify hosts behind the firewall. The Via header field
8794 allows intermediaries to replace sensitive machine names with
879717.13. Browser Fingerprinting
8799 Browser fingerprinting is a set of techniques for identifying a
8800 specific user agent over time through its unique set of
8801 characteristics. These characteristics might include information
8802 related to how it uses the underlying transport protocol, feature
8803 capabilities, and scripting environment, though of particular
8804 interest here is the set of unique characteristics that might be
8805 communicated via HTTP. Fingerprinting is considered a privacy
8806 concern because it enables tracking of a user agent's behavior over
8807 time ([Bujlow]) without the corresponding controls that the user
8808 might have over other forms of data collection (e.g., cookies). Many
8809 general-purpose user agents (i.e., Web browsers) have taken steps to
8810 reduce their fingerprints.
8812 There are a number of request header fields that might reveal
8813 information to servers that is sufficiently unique to enable
8814 fingerprinting. The From header field is the most obvious, though it
8815 is expected that From will only be sent when self-identification is
8816 desired by the user. Likewise, Cookie header fields are deliberately
8817 designed to enable re-identification, so fingerprinting concerns only
8818 apply to situations where cookies are disabled or restricted by the
8819 user agent's configuration.
8821 The User-Agent header field might contain enough information to
8822 uniquely identify a specific device, usually when combined with other
8823 characteristics, particularly if the user agent sends excessive
8824 details about the user's system or extensions. However, the source
8825 of unique information that is least expected by users is proactive
8826 negotiation (Section 12.1), including the Accept, Accept-Charset,
8827 Accept-Encoding, and Accept-Language header fields.
8829 In addition to the fingerprinting concern, detailed use of the
8830 Accept-Language header field can reveal information the user might
8831 consider to be of a private nature. For example, understanding a
8832 given language set might be strongly correlated to membership in a
8833 particular ethnic group. An approach that limits such loss of
8834 privacy would be for a user agent to omit the sending of Accept-
8835 Language except for sites that have been explicitly permitted,
8836 perhaps via interaction after detecting a Vary header field that
8837 indicates language negotiation might be useful.
8839 In environments where proxies are used to enhance privacy, user
8840 agents ought to be conservative in sending proactive negotiation
8841 header fields. General-purpose user agents that provide a high
8842 degree of header field configurability ought to inform users about
8843 the loss of privacy that might result if too much detail is provided.
8844 As an extreme privacy measure, proxies could filter the proactive
8845 negotiation header fields in relayed requests.
884717.14. Validator Retention
8849 The validators defined by this specification are not intended to
8850 ensure the validity of a representation, guard against malicious
8851 changes, or detect on-path attacks. At best, they enable more
8852 efficient cache updates and optimistic concurrent writes when all
8853 participants are behaving nicely. At worst, the conditions will fail
8854 and the client will receive a response that is no more harmful than
8855 an HTTP exchange without conditional requests.
8857 An entity tag can be abused in ways that create privacy risks. For
8858 example, a site might deliberately construct a semantically invalid
8859 entity tag that is unique to the user or user agent, send it in a
8860 cacheable response with a long freshness time, and then read that
8861 entity tag in later conditional requests as a means of re-identifying
8862 that user or user agent. Such an identifying tag would become a
8863 persistent identifier for as long as the user agent retained the
8864 original cache entry. User agents that cache representations ought
8865 to ensure that the cache is cleared or replaced whenever the user
8866 performs privacy-maintaining actions, such as clearing stored cookies
8867 or changing to a private browsing mode.
886917.15. Denial-of-Service Attacks Using Range
8871 Unconstrained multiple range requests are susceptible to denial-of-
8872 service attacks because the effort required to request many
8873 overlapping ranges of the same data is tiny compared to the time,
8874 memory, and bandwidth consumed by attempting to serve the requested
8875 data in many parts. Servers ought to ignore, coalesce, or reject
8876 egregious range requests, such as requests for more than two
8877 overlapping ranges or for many small ranges in a single set,
8878 particularly when the ranges are requested out of order for no
8879 apparent reason. Multipart range requests are not designed to
8880 support random access.
888217.16. Authentication Considerations
8884 Everything about the topic of HTTP authentication is a security
8885 consideration, so the list of considerations below is not exhaustive.
8886 Furthermore, it is limited to security considerations regarding the
8887 authentication framework, in general, rather than discussing all of
8888 the potential considerations for specific authentication schemes
8889 (which ought to be documented in the specifications that define those
8890 schemes). Various organizations maintain topical information and
8891 links to current research on Web application security (e.g.,
8892 [OWASP]), including common pitfalls for implementing and using the
8893 authentication schemes found in practice.
889517.16.1. Confidentiality of Credentials
8897 The HTTP authentication framework does not define a single mechanism
8898 for maintaining the confidentiality of credentials; instead, each
8899 authentication scheme defines how the credentials are encoded prior
8900 to transmission. While this provides flexibility for the development
8901 of future authentication schemes, it is inadequate for the protection
8902 of existing schemes that provide no confidentiality on their own, or
8903 that do not sufficiently protect against replay attacks.
8904 Furthermore, if the server expects credentials that are specific to
8905 each individual user, the exchange of those credentials will have the
8906 effect of identifying that user even if the content within
8907 credentials remains confidential.
8909 HTTP depends on the security properties of the underlying transport-
8910 or session-level connection to provide confidential transmission of
8911 fields. Services that depend on individual user authentication
8912 require a secured connection prior to exchanging credentials
891517.16.2. Credentials and Idle Clients
8917 Existing HTTP clients and user agents typically retain authentication
8918 information indefinitely. HTTP does not provide a mechanism for the
8919 origin server to direct clients to discard these cached credentials,
8920 since the protocol has no awareness of how credentials are obtained
8921 or managed by the user agent. The mechanisms for expiring or
8922 revoking credentials can be specified as part of an authentication
8925 Circumstances under which credential caching can interfere with the
8926 application's security model include but are not limited to:
8928 * Clients that have been idle for an extended period, following
8929 which the server might wish to cause the client to re-prompt the
8930 user for credentials.
8932 * Applications that include a session termination indication (such
8933 as a "logout" or "commit" button on a page) after which the server
8934 side of the application "knows" that there is no further reason
8935 for the client to retain the credentials.
8937 User agents that cache credentials are encouraged to provide a
8938 readily accessible mechanism for discarding cached credentials under
894117.16.3. Protection Spaces
8943 Authentication schemes that solely rely on the "realm" mechanism for
8944 establishing a protection space will expose credentials to all
8945 resources on an origin server. Clients that have successfully made
8946 authenticated requests with a resource can use the same
8947 authentication credentials for other resources on the same origin
8948 server. This makes it possible for a different resource to harvest
8949 authentication credentials for other resources.
8951 This is of particular concern when an origin server hosts resources
8952 for multiple parties under the same origin (Section 11.5). Possible
8953 mitigation strategies include restricting direct access to
8954 authentication credentials (i.e., not making the content of the
8955 Authorization request header field available), and separating
8956 protection spaces by using a different host name (or port number) for
895917.16.4. Additional Response Fields
8961 Adding information to responses that are sent over an unencrypted
8962 channel can affect security and privacy. The presence of the
8963 Authentication-Info and Proxy-Authentication-Info header fields alone
8964 indicates that HTTP authentication is in use. Additional information
8965 could be exposed by the contents of the authentication-scheme
8966 specific parameters; this will have to be considered in the
8967 definitions of these schemes.
896918. IANA Considerations
8971 The change controller for the following registrations is: "IETF
8972 (iesg@ietf.org) - Internet Engineering Task Force".
897418.1. URI Scheme Registration
8976 IANA has updated the "Uniform Resource Identifier (URI) Schemes"
8977 registry [BCP35] at <https://www.iana.org/assignments/uri-schemes/>
8978 with the permanent schemes listed in Table 2 in Section 4.2.
898018.2. Method Registration
8982 IANA has updated the "Hypertext Transfer Protocol (HTTP) Method
8983 Registry" at <https://www.iana.org/assignments/http-methods> with the
8984 registration procedure of Section 16.1.1 and the method names
8985 summarized in the following table.
8987 +=========+======+============+=========+
8988 | Method | Safe | Idempotent | Section |
8989 +=========+======+============+=========+
8990 | CONNECT | no | no | 9.3.6 |
8991 +---------+------+------------+---------+
8992 | DELETE | no | yes | 9.3.5 |
8993 +---------+------+------------+---------+
8994 | GET | yes | yes | 9.3.1 |
8995 +---------+------+------------+---------+
8996 | HEAD | yes | yes | 9.3.2 |
8997 +---------+------+------------+---------+
8998 | OPTIONS | yes | yes | 9.3.7 |
8999 +---------+------+------------+---------+
9000 | POST | no | no | 9.3.3 |
9001 +---------+------+------------+---------+
9002 | PUT | no | yes | 9.3.4 |
9003 +---------+------+------------+---------+
9004 | TRACE | yes | yes | 9.3.8 |
9005 +---------+------+------------+---------+
9006 | * | no | no | 18.2 |
9007 +---------+------+------------+---------+
9011 The method name "*" is reserved because using "*" as a method name
9012 would conflict with its usage as a wildcard in some fields (e.g.,
9013 "Access-Control-Request-Method").
901518.3. Status Code Registration
9017 IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code
9018 Registry" at <https://www.iana.org/assignments/http-status-codes>
9019 with the registration procedure of Section 16.2.1 and the status code
9020 values summarized in the following table.
9022 +=======+===============================+=========+
9023 | Value | Description | Section |
9024 +=======+===============================+=========+
9025 | 100 | Continue | 15.2.1 |
9026 +-------+-------------------------------+---------+
9027 | 101 | Switching Protocols | 15.2.2 |
9028 +-------+-------------------------------+---------+
9029 | 200 | OK | 15.3.1 |
9030 +-------+-------------------------------+---------+
9031 | 201 | Created | 15.3.2 |
9032 +-------+-------------------------------+---------+
9033 | 202 | Accepted | 15.3.3 |
9034 +-------+-------------------------------+---------+
9035 | 203 | Non-Authoritative Information | 15.3.4 |
9036 +-------+-------------------------------+---------+
9037 | 204 | No Content | 15.3.5 |
9038 +-------+-------------------------------+---------+
9039 | 205 | Reset Content | 15.3.6 |
9040 +-------+-------------------------------+---------+
9041 | 206 | Partial Content | 15.3.7 |
9042 +-------+-------------------------------+---------+
9043 | 300 | Multiple Choices | 15.4.1 |
9044 +-------+-------------------------------+---------+
9045 | 301 | Moved Permanently | 15.4.2 |
9046 +-------+-------------------------------+---------+
9047 | 302 | Found | 15.4.3 |
9048 +-------+-------------------------------+---------+
9049 | 303 | See Other | 15.4.4 |
9050 +-------+-------------------------------+---------+
9051 | 304 | Not Modified | 15.4.5 |
9052 +-------+-------------------------------+---------+
9053 | 305 | Use Proxy | 15.4.6 |
9054 +-------+-------------------------------+---------+
9055 | 306 | (Unused) | 15.4.7 |
9056 +-------+-------------------------------+---------+
9057 | 307 | Temporary Redirect | 15.4.8 |
9058 +-------+-------------------------------+---------+
9059 | 308 | Permanent Redirect | 15.4.9 |
9060 +-------+-------------------------------+---------+
9061 | 400 | Bad Request | 15.5.1 |
9062 +-------+-------------------------------+---------+
9063 | 401 | Unauthorized | 15.5.2 |
9064 +-------+-------------------------------+---------+
9065 | 402 | Payment Required | 15.5.3 |
9066 +-------+-------------------------------+---------+
9067 | 403 | Forbidden | 15.5.4 |
9068 +-------+-------------------------------+---------+
9069 | 404 | Not Found | 15.5.5 |
9070 +-------+-------------------------------+---------+
9071 | 405 | Method Not Allowed | 15.5.6 |
9072 +-------+-------------------------------+---------+
9073 | 406 | Not Acceptable | 15.5.7 |
9074 +-------+-------------------------------+---------+
9075 | 407 | Proxy Authentication Required | 15.5.8 |
9076 +-------+-------------------------------+---------+
9077 | 408 | Request Timeout | 15.5.9 |
9078 +-------+-------------------------------+---------+
9079 | 409 | Conflict | 15.5.10 |
9080 +-------+-------------------------------+---------+
9081 | 410 | Gone | 15.5.11 |
9082 +-------+-------------------------------+---------+
9083 | 411 | Length Required | 15.5.12 |
9084 +-------+-------------------------------+---------+
9085 | 412 | Precondition Failed | 15.5.13 |
9086 +-------+-------------------------------+---------+
9087 | 413 | Content Too Large | 15.5.14 |
9088 +-------+-------------------------------+---------+
9089 | 414 | URI Too Long | 15.5.15 |
9090 +-------+-------------------------------+---------+
9091 | 415 | Unsupported Media Type | 15.5.16 |
9092 +-------+-------------------------------+---------+
9093 | 416 | Range Not Satisfiable | 15.5.17 |
9094 +-------+-------------------------------+---------+
9095 | 417 | Expectation Failed | 15.5.18 |
9096 +-------+-------------------------------+---------+
9097 | 418 | (Unused) | 15.5.19 |
9098 +-------+-------------------------------+---------+
9099 | 421 | Misdirected Request | 15.5.20 |
9100 +-------+-------------------------------+---------+
9101 | 422 | Unprocessable Content | 15.5.21 |
9102 +-------+-------------------------------+---------+
9103 | 426 | Upgrade Required | 15.5.22 |
9104 +-------+-------------------------------+---------+
9105 | 500 | Internal Server Error | 15.6.1 |
9106 +-------+-------------------------------+---------+
9107 | 501 | Not Implemented | 15.6.2 |
9108 +-------+-------------------------------+---------+
9109 | 502 | Bad Gateway | 15.6.3 |
9110 +-------+-------------------------------+---------+
9111 | 503 | Service Unavailable | 15.6.4 |
9112 +-------+-------------------------------+---------+
9113 | 504 | Gateway Timeout | 15.6.5 |
9114 +-------+-------------------------------+---------+
9115 | 505 | HTTP Version Not Supported | 15.6.6 |
9116 +-------+-------------------------------+---------+
912018.4. Field Name Registration
9122 This specification updates the HTTP-related aspects of the existing
9123 registration procedures for message header fields defined in
9124 [RFC3864]. It replaces the old procedures as they relate to HTTP by
9125 defining a new registration procedure and moving HTTP field
9126 definitions into a separate registry.
9128 IANA has created a new registry titled "Hypertext Transfer Protocol
9129 (HTTP) Field Name Registry" as outlined in Section 16.3.1.
9131 IANA has moved all entries in the "Permanent Message Header Field
9132 Names" and "Provisional Message Header Field Names" registries (see
9133 <https://www.iana.org/assignments/message-headers/>) with the
9134 protocol 'http' to this registry and has applied the following
9137 1. The 'Applicable Protocol' field has been omitted.
9139 2. Entries that had a status of 'standard', 'experimental',
9140 'reserved', or 'informational' have been made to have a status of
9143 3. Provisional entries without a status have been made to have a
9144 status of 'provisional'.
9146 4. Permanent entries without a status (after confirmation that the
9147 registration document did not define one) have been made to have
9148 a status of 'provisional'. The expert(s) can choose to update
9149 the entries' status if there is evidence that another is more
9152 IANA has annotated the "Permanent Message Header Field Names" and
9153 "Provisional Message Header Field Names" registries with the
9154 following note to indicate that HTTP field name registrations have
9159 | HTTP field name registrations have been moved to
9160 | [https://www.iana.org/assignments/http-fields] per [RFC9110].
9162 IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name
9163 Registry" with the field names listed in the following table.
9165 +===========================+============+=========+============+
9166 | Field Name | Status | Section | Comments |
9167 +===========================+============+=========+============+
9168 | Accept | permanent | 12.5.1 | |
9169 +---------------------------+------------+---------+------------+
9170 | Accept-Charset | deprecated | 12.5.2 | |
9171 +---------------------------+------------+---------+------------+
9172 | Accept-Encoding | permanent | 12.5.3 | |
9173 +---------------------------+------------+---------+------------+
9174 | Accept-Language | permanent | 12.5.4 | |
9175 +---------------------------+------------+---------+------------+
9176 | Accept-Ranges | permanent | 14.3 | |
9177 +---------------------------+------------+---------+------------+
9178 | Allow | permanent | 10.2.1 | |
9179 +---------------------------+------------+---------+------------+
9180 | Authentication-Info | permanent | 11.6.3 | |
9181 +---------------------------+------------+---------+------------+
9182 | Authorization | permanent | 11.6.2 | |
9183 +---------------------------+------------+---------+------------+
9184 | Connection | permanent | 7.6.1 | |
9185 +---------------------------+------------+---------+------------+
9186 | Content-Encoding | permanent | 8.4 | |
9187 +---------------------------+------------+---------+------------+
9188 | Content-Language | permanent | 8.5 | |
9189 +---------------------------+------------+---------+------------+
9190 | Content-Length | permanent | 8.6 | |
9191 +---------------------------+------------+---------+------------+
9192 | Content-Location | permanent | 8.7 | |
9193 +---------------------------+------------+---------+------------+
9194 | Content-Range | permanent | 14.4 | |
9195 +---------------------------+------------+---------+------------+
9196 | Content-Type | permanent | 8.3 | |
9197 +---------------------------+------------+---------+------------+
9198 | Date | permanent | 6.6.1 | |
9199 +---------------------------+------------+---------+------------+
9200 | ETag | permanent | 8.8.3 | |
9201 +---------------------------+------------+---------+------------+
9202 | Expect | permanent | 10.1.1 | |
9203 +---------------------------+------------+---------+------------+
9204 | From | permanent | 10.1.2 | |
9205 +---------------------------+------------+---------+------------+
9206 | Host | permanent | 7.2 | |
9207 +---------------------------+------------+---------+------------+
9208 | If-Match | permanent | 13.1.1 | |
9209 +---------------------------+------------+---------+------------+
9210 | If-Modified-Since | permanent | 13.1.3 | |
9211 +---------------------------+------------+---------+------------+
9212 | If-None-Match | permanent | 13.1.2 | |
9213 +---------------------------+------------+---------+------------+
9214 | If-Range | permanent | 13.1.5 | |
9215 +---------------------------+------------+---------+------------+
9216 | If-Unmodified-Since | permanent | 13.1.4 | |
9217 +---------------------------+------------+---------+------------+
9218 | Last-Modified | permanent | 8.8.2 | |
9219 +---------------------------+------------+---------+------------+
9220 | Location | permanent | 10.2.2 | |
9221 +---------------------------+------------+---------+------------+
9222 | Max-Forwards | permanent | 7.6.2 | |
9223 +---------------------------+------------+---------+------------+
9224 | Proxy-Authenticate | permanent | 11.7.1 | |
9225 +---------------------------+------------+---------+------------+
9226 | Proxy-Authentication-Info | permanent | 11.7.3 | |
9227 +---------------------------+------------+---------+------------+
9228 | Proxy-Authorization | permanent | 11.7.2 | |
9229 +---------------------------+------------+---------+------------+
9230 | Range | permanent | 14.2 | |
9231 +---------------------------+------------+---------+------------+
9232 | Referer | permanent | 10.1.3 | |
9233 +---------------------------+------------+---------+------------+
9234 | Retry-After | permanent | 10.2.3 | |
9235 +---------------------------+------------+---------+------------+
9236 | Server | permanent | 10.2.4 | |
9237 +---------------------------+------------+---------+------------+
9238 | TE | permanent | 10.1.4 | |
9239 +---------------------------+------------+---------+------------+
9240 | Trailer | permanent | 6.6.2 | |
9241 +---------------------------+------------+---------+------------+
9242 | Upgrade | permanent | 7.8 | |
9243 +---------------------------+------------+---------+------------+
9244 | User-Agent | permanent | 10.1.5 | |
9245 +---------------------------+------------+---------+------------+
9246 | Vary | permanent | 12.5.5 | |
9247 +---------------------------+------------+---------+------------+
9248 | Via | permanent | 7.6.3 | |
9249 +---------------------------+------------+---------+------------+
9250 | WWW-Authenticate | permanent | 11.6.1 | |
9251 +---------------------------+------------+---------+------------+
9252 | * | permanent | 12.5.5 | (reserved) |
9253 +---------------------------+------------+---------+------------+
9257 The field name "*" is reserved because using that name as an HTTP
9258 header field might conflict with its special semantics in the Vary
9259 header field (Section 12.5.5).
9261 IANA has updated the "Content-MD5" entry in the new registry to have
9262 a status of 'obsoleted' with references to Section 14.15 of [RFC2616]
9263 (for the definition of the header field) and Appendix B of [RFC7231]
9264 (which removed the field definition from the updated specification).
926618.5. Authentication Scheme Registration
9268 IANA has updated the "Hypertext Transfer Protocol (HTTP)
9269 Authentication Scheme Registry" at <https://www.iana.org/assignments/
9270 http-authschemes> with the registration procedure of Section 16.4.1.
9271 No authentication schemes are defined in this document.
927318.6. Content Coding Registration
9275 IANA has updated the "HTTP Content Coding Registry" at
9276 <https://www.iana.org/assignments/http-parameters/> with the
9277 registration procedure of Section 16.6.1 and the content coding names
9278 summarized in the table below.
9280 +============+===========================================+=========+
9281 | Name | Description | Section |
9282 +============+===========================================+=========+
9283 | compress | UNIX "compress" data format [Welch] | 8.4.1.1 |
9284 +------------+-------------------------------------------+---------+
9285 | deflate | "deflate" compressed data ([RFC1951]) | 8.4.1.2 |
9286 | | inside the "zlib" data format ([RFC1950]) | |
9287 +------------+-------------------------------------------+---------+
9288 | gzip | GZIP file format [RFC1952] | 8.4.1.3 |
9289 +------------+-------------------------------------------+---------+
9290 | identity | Reserved | 12.5.3 |
9291 +------------+-------------------------------------------+---------+
9292 | x-compress | Deprecated (alias for compress) | 8.4.1.1 |
9293 +------------+-------------------------------------------+---------+
9294 | x-gzip | Deprecated (alias for gzip) | 8.4.1.3 |
9295 +------------+-------------------------------------------+---------+
929918.7. Range Unit Registration
9301 IANA has updated the "HTTP Range Unit Registry" at
9302 <https://www.iana.org/assignments/http-parameters/> with the
9303 registration procedure of Section 16.5.1 and the range unit names
9304 summarized in the table below.
9306 +=================+==================================+=========+
9307 | Range Unit Name | Description | Section |
9308 +=================+==================================+=========+
9309 | bytes | a range of octets | 14.1.2 |
9310 +-----------------+----------------------------------+---------+
9311 | none | reserved as keyword to indicate | 14.3 |
9312 | | range requests are not supported | |
9313 +-----------------+----------------------------------+---------+
931718.8. Media Type Registration
9319 IANA has updated the "Media Types" registry at
9320 <https://www.iana.org/assignments/media-types> with the registration
9321 information in Section 14.6 for the media type "multipart/
9324 IANA has updated the registry note about "q" parameters with a link
9325 to Section 12.5.1 of this document.
932718.9. Port Registration
9329 IANA has updated the "Service Name and Transport Protocol Port Number
9330 Registry" at <https://www.iana.org/assignments/service-names-port-
9331 numbers/> for the services on ports 80 and 443 that use UDP or TCP
9334 1. use this document as "Reference", and
9336 2. when currently unspecified, set "Assignee" to "IESG" and
9337 "Contact" to "IETF_Chair".
933918.10. Upgrade Token Registration
9341 IANA has updated the "Hypertext Transfer Protocol (HTTP) Upgrade
9342 Token Registry" at <https://www.iana.org/assignments/http-upgrade-
9343 tokens> with the registration procedure described in Section 16.7 and
9344 the upgrade token names summarized in the following table.
9346 +======+===================+=========================+=========+
9347 | Name | Description | Expected Version Tokens | Section |
9348 +======+===================+=========================+=========+
9349 | HTTP | Hypertext | any DIGIT.DIGIT (e.g., | 2.5 |
9350 | | Transfer Protocol | "2.0") | |
9351 +------+-------------------+-------------------------+---------+
935719.1. Normative References
9359 [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
9360 Ed., "HTTP Caching", STD 98, RFC 9111,
9361 DOI 10.17487/RFC9111, June 2022,
9362 <https://www.rfc-editor.org/info/rfc9111>.
9364 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
9365 Specification version 3.3", RFC 1950,
9366 DOI 10.17487/RFC1950, May 1996,
9367 <https://www.rfc-editor.org/info/rfc1950>.
9369 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
9370 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
9371 <https://www.rfc-editor.org/info/rfc1951>.
9373 [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
9374 RFC 1952, DOI 10.17487/RFC1952, May 1996,
9375 <https://www.rfc-editor.org/info/rfc1952>.
9377 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
9378 Extensions (MIME) Part Two: Media Types", RFC 2046,
9379 DOI 10.17487/RFC2046, November 1996,
9380 <https://www.rfc-editor.org/info/rfc2046>.
9382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
9383 Requirement Levels", BCP 14, RFC 2119,
9384 DOI 10.17487/RFC2119, March 1997,
9385 <https://www.rfc-editor.org/info/rfc2119>.
9387 [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
9388 Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
9389 2006, <https://www.rfc-editor.org/info/rfc4647>.
9391 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
9392 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
9393 <https://www.rfc-editor.org/info/rfc4648>.
9395 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
9396 Specifications: ABNF", STD 68, RFC 5234,
9397 DOI 10.17487/RFC5234, January 2008,
9398 <https://www.rfc-editor.org/info/rfc5234>.
9400 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
9401 Housley, R., and W. Polk, "Internet X.509 Public Key
9402 Infrastructure Certificate and Certificate Revocation List
9403 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
9404 <https://www.rfc-editor.org/info/rfc5280>.
9406 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
9407 DOI 10.17487/RFC5322, October 2008,
9408 <https://www.rfc-editor.org/info/rfc5322>.
9410 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
9411 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
9412 September 2009, <https://www.rfc-editor.org/info/rfc5646>.
9414 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
9415 Verification of Domain-Based Application Service Identity
9416 within Internet Public Key Infrastructure Using X.509
9417 (PKIX) Certificates in the Context of Transport Layer
9418 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
9419 2011, <https://www.rfc-editor.org/info/rfc6125>.
9421 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
9422 Internationalization in the IETF", BCP 166, RFC 6365,
9423 DOI 10.17487/RFC6365, September 2011,
9424 <https://www.rfc-editor.org/info/rfc6365>.
9426 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
9427 RFC 7405, DOI 10.17487/RFC7405, December 2014,
9428 <https://www.rfc-editor.org/info/rfc7405>.
9430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
9431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
9432 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9434 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
9435 RFC 793, DOI 10.17487/RFC0793, September 1981,
9436 <https://www.rfc-editor.org/info/rfc793>.
9438 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
9439 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
9440 <https://www.rfc-editor.org/info/rfc8446>.
9442 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
9443 Resource Identifier (URI): Generic Syntax", STD 66,
9444 RFC 3986, DOI 10.17487/RFC3986, January 2005,
9445 <https://www.rfc-editor.org/info/rfc3986>.
9447 [USASCII] American National Standards Institute, "Coded Character
9448 Set -- 7-bit American Standard Code for Information
9449 Interchange", ANSI X3.4, 1986.
9451 [Welch] Welch, T., "A Technique for High-Performance Data
9452 Compression", IEEE Computer 17(6),
9453 DOI 10.1109/MC.1984.1659158, June 1984,
9454 <https://ieeexplore.ieee.org/document/1659158/>.
945619.2. Informative References
9458 [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
9459 Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
9460 April 2016, <https://www.rfc-editor.org/info/rfc7838>.
9462 [BCP13] Freed, N. and J. Klensin, "Multipurpose Internet Mail
9463 Extensions (MIME) Part Four: Registration Procedures",
9464 BCP 13, RFC 4289, December 2005.
9466 Freed, N., Klensin, J., and T. Hansen, "Media Type
9467 Specifications and Registration Procedures", BCP 13,
9468 RFC 6838, January 2013.
9470 <https://www.rfc-editor.org/info/bcp13>
9472 [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
9473 "Deprecating the "X-" Prefix and Similar Constructs in
9474 Application Protocols", BCP 178, RFC 6648, June 2012.
9476 <https://www.rfc-editor.org/info/bcp178>
9478 [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
9479 and Registration Procedures for URI Schemes", BCP 35,
9480 RFC 7595, June 2015.
9482 <https://www.rfc-editor.org/info/bcp35>
9484 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
9485 CRIME Attack", July 2013,
9486 <http://breachattack.com/resources/
9487 BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
9489 [Bujlow] Bujlow, T., Carela-Español, V., Solé-Pareta, J., and P.
9490 Barlet-Ros, "A Survey on Web Tracking: Mechanisms,
9491 Implications, and Defenses", In Proceedings of the IEEE
9492 105(8), DOI 10.1109/JPROC.2016.2637878, August 2017,
9493 <https://doi.org/10.1109/JPROC.2016.2637878>.
9495 [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
9496 DOI 10.17487/RFC6265, April 2011,
9497 <https://www.rfc-editor.org/info/rfc6265>.
9499 [Err1912] RFC Errata, Erratum ID 1912, RFC 2978,
9500 <https://www.rfc-editor.org/errata/eid1912>.
9502 [Err5433] RFC Errata, Erratum ID 5433, RFC 2978,
9503 <https://www.rfc-editor.org/errata/eid5433>.
9505 [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
9506 D., and V. Shmatikov, "The Most Dangerous Code in the
9507 World: Validating SSL Certificates in Non-Browser
9508 Software", In Proceedings of the 2012 ACM Conference on
9509 Computer and Communications Security (CCS '12), pp. 38-49,
9510 DOI 10.1145/2382196.2382204, October 2012,
9511 <https://doi.org/10.1145/2382196.2382204>.
9513 [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
9514 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
9515 <https://www.rfc-editor.org/info/rfc7541>.
9517 [HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
9518 Transfer Protocol -- HTTP/1.0", RFC 1945,
9519 DOI 10.17487/RFC1945, May 1996,
9520 <https://www.rfc-editor.org/info/rfc1945>.
9522 [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
9523 Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
9524 June 2022, <https://www.rfc-editor.org/info/rfc9112>.
9526 [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
9527 DOI 10.17487/RFC9113, June 2022,
9528 <https://www.rfc-editor.org/info/rfc9113>.
9530 [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
9531 June 2022, <https://www.rfc-editor.org/info/rfc9114>.
9534 International Organization for Standardization,
9535 "Information technology -- 8-bit single-byte coded graphic
9536 character sets -- Part 1: Latin alphabet No. 1", ISO/
9537 IEC 8859-1:1998, 1998.
9539 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
9540 Politics", ACM Transactions on Internet Technology 1(2),
9541 November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
9543 [OWASP] The Open Web Application Security Project,
9544 <https://www.owasp.org/>.
9546 [REST] Fielding, R.T., "Architectural Styles and the Design of
9547 Network-based Software Architectures", Doctoral
9548 Dissertation, University of California, Irvine, September
9549 2000, <https://roy.gbiv.com/pubs/dissertation/top.htm>.
9551 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
9552 RFC 1919, DOI 10.17487/RFC1919, March 1996,
9553 <https://www.rfc-editor.org/info/rfc1919>.
9555 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
9556 Part Three: Message Header Extensions for Non-ASCII Text",
9557 RFC 2047, DOI 10.17487/RFC2047, November 1996,
9558 <https://www.rfc-editor.org/info/rfc2047>.
9560 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
9561 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
9562 RFC 2068, DOI 10.17487/RFC2068, January 1997,
9563 <https://www.rfc-editor.org/info/rfc2068>.
9565 [RFC2145] Mogul, J. C., Fielding, R., Gettys, J., and H. Frystyk,
9566 "Use and Interpretation of HTTP Version Numbers",
9567 RFC 2145, DOI 10.17487/RFC2145, May 1997,
9568 <https://www.rfc-editor.org/info/rfc2145>.
9570 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
9571 in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
9572 <https://www.rfc-editor.org/info/rfc2295>.
9574 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
9575 (HTCPCP/1.0)", RFC 2324, DOI 10.17487/RFC2324, 1 April
9576 1998, <https://www.rfc-editor.org/info/rfc2324>.
9578 [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
9579 Encapsulation of Aggregate Documents, such as HTML
9580 (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
9581 <https://www.rfc-editor.org/info/rfc2557>.
9583 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
9584 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
9585 Transfer Protocol -- HTTP/1.1", RFC 2616,
9586 DOI 10.17487/RFC2616, June 1999,
9587 <https://www.rfc-editor.org/info/rfc2616>.
9589 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
9590 Leach, P., Luotonen, A., and L. Stewart, "HTTP
9591 Authentication: Basic and Digest Access Authentication",
9592 RFC 2617, DOI 10.17487/RFC2617, June 1999,
9593 <https://www.rfc-editor.org/info/rfc2617>.
9595 [RFC2774] Nielsen, H., Leach, P., and S. Lawrence, "An HTTP
9596 Extension Framework", RFC 2774, DOI 10.17487/RFC2774,
9597 February 2000, <https://www.rfc-editor.org/info/rfc2774>.
9599 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
9600 DOI 10.17487/RFC2818, May 2000,
9601 <https://www.rfc-editor.org/info/rfc2818>.
9603 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
9604 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
9605 October 2000, <https://www.rfc-editor.org/info/rfc2978>.
9607 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
9608 Replication and Caching Taxonomy", RFC 3040,
9609 DOI 10.17487/RFC3040, January 2001,
9610 <https://www.rfc-editor.org/info/rfc3040>.
9612 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
9613 Procedures for Message Header Fields", BCP 90, RFC 3864,
9614 DOI 10.17487/RFC3864, September 2004,
9615 <https://www.rfc-editor.org/info/rfc3864>.
9617 [RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface
9618 (CGI) Version 1.1", RFC 3875, DOI 10.17487/RFC3875,
9619 October 2004, <https://www.rfc-editor.org/info/rfc3875>.
9621 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
9622 Rose, "DNS Security Introduction and Requirements",
9623 RFC 4033, DOI 10.17487/RFC4033, March 2005,
9624 <https://www.rfc-editor.org/info/rfc4033>.
9626 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
9627 Kerberos and NTLM HTTP Authentication in Microsoft
9628 Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
9629 <https://www.rfc-editor.org/info/rfc4559>.
9631 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
9632 RFC 5789, DOI 10.17487/RFC5789, March 2010,
9633 <https://www.rfc-editor.org/info/rfc5789>.
9635 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
9636 "Network Time Protocol Version 4: Protocol and Algorithms
9637 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
9638 <https://www.rfc-editor.org/info/rfc5905>.
9640 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
9641 DOI 10.17487/RFC6454, December 2011,
9642 <https://www.rfc-editor.org/info/rfc6454>.
9644 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
9645 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
9646 <https://www.rfc-editor.org/info/rfc6585>.
9648 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
9649 Protocol (HTTP/1.1): Message Syntax and Routing",
9650 RFC 7230, DOI 10.17487/RFC7230, June 2014,
9651 <https://www.rfc-editor.org/info/rfc7230>.
9653 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
9654 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
9655 DOI 10.17487/RFC7231, June 2014,
9656 <https://www.rfc-editor.org/info/rfc7231>.
9658 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
9659 Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
9660 DOI 10.17487/RFC7232, June 2014,
9661 <https://www.rfc-editor.org/info/rfc7232>.
9663 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
9664 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
9665 RFC 7233, DOI 10.17487/RFC7233, June 2014,
9666 <https://www.rfc-editor.org/info/rfc7233>.
9668 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
9669 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
9670 RFC 7234, DOI 10.17487/RFC7234, June 2014,
9671 <https://www.rfc-editor.org/info/rfc7234>.
9673 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
9674 Protocol (HTTP/1.1): Authentication", RFC 7235,
9675 DOI 10.17487/RFC7235, June 2014,
9676 <https://www.rfc-editor.org/info/rfc7235>.
9678 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
9679 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
9680 April 2015, <https://www.rfc-editor.org/info/rfc7538>.
9682 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
9683 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
9684 DOI 10.17487/RFC7540, May 2015,
9685 <https://www.rfc-editor.org/info/rfc7540>.
9687 [RFC7578] Masinter, L., "Returning Values from Forms: multipart/
9688 form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
9689 <https://www.rfc-editor.org/info/rfc7578>.
9691 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
9692 Authentication-Info Response Header Fields", RFC 7615,
9693 DOI 10.17487/RFC7615, September 2015,
9694 <https://www.rfc-editor.org/info/rfc7615>.
9696 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
9697 Digest Access Authentication", RFC 7616,
9698 DOI 10.17487/RFC7616, September 2015,
9699 <https://www.rfc-editor.org/info/rfc7616>.
9701 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
9702 RFC 7617, DOI 10.17487/RFC7617, September 2015,
9703 <https://www.rfc-editor.org/info/rfc7617>.
9705 [RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-
9706 Initiated Content-Encoding", RFC 7694,
9707 DOI 10.17487/RFC7694, November 2015,
9708 <https://www.rfc-editor.org/info/rfc7694>.
9710 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
9711 Writing an IANA Considerations Section in RFCs", BCP 26,
9712 RFC 8126, DOI 10.17487/RFC8126, June 2017,
9713 <https://www.rfc-editor.org/info/rfc8126>.
9715 [RFC8187] Reschke, J., "Indicating Character Encoding and Language
9716 for HTTP Header Field Parameters", RFC 8187,
9717 DOI 10.17487/RFC8187, September 2017,
9718 <https://www.rfc-editor.org/info/rfc8187>.
9720 [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246,
9721 DOI 10.17487/RFC8246, September 2017,
9722 <https://www.rfc-editor.org/info/rfc8246>.
9724 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
9725 DOI 10.17487/RFC8288, October 2017,
9726 <https://www.rfc-editor.org/info/rfc8288>.
9728 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
9729 RFC 8336, DOI 10.17487/RFC8336, March 2018,
9730 <https://www.rfc-editor.org/info/rfc8336>.
9732 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
9733 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
9734 <https://www.rfc-editor.org/info/rfc8615>.
9736 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for
9737 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
9738 <https://www.rfc-editor.org/info/rfc8941>.
9740 [Sniffing] WHATWG, "MIME Sniffing",
9741 <https://mimesniff.spec.whatwg.org>.
9743 [WEBDAV] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
9744 Authoring and Versioning (WebDAV)", RFC 4918,
9745 DOI 10.17487/RFC4918, June 2007,
9746 <https://www.rfc-editor.org/info/rfc4918>.
9748Appendix A. Collected ABNF
9750 In the collected ABNF below, list rules are expanded per
9753 Accept = [ ( media-range [ weight ] ) *( OWS "," OWS ( media-range [
9755 Accept-Charset = [ ( ( token / "*" ) [ weight ] ) *( OWS "," OWS ( (
9756 token / "*" ) [ weight ] ) ) ]
9757 Accept-Encoding = [ ( codings [ weight ] ) *( OWS "," OWS ( codings [
9759 Accept-Language = [ ( language-range [ weight ] ) *( OWS "," OWS (
9760 language-range [ weight ] ) ) ]
9761 Accept-Ranges = acceptable-ranges
9762 Allow = [ method *( OWS "," OWS method ) ]
9763 Authentication-Info = [ auth-param *( OWS "," OWS auth-param ) ]
9764 Authorization = credentials
9768 Connection = [ connection-option *( OWS "," OWS connection-option )
9770 Content-Encoding = [ content-coding *( OWS "," OWS content-coding )
9772 Content-Language = [ language-tag *( OWS "," OWS language-tag ) ]
9773 Content-Length = 1*DIGIT
9774 Content-Location = absolute-URI / partial-URI
9775 Content-Range = range-unit SP ( range-resp / unsatisfied-range )
9776 Content-Type = media-type
9781 Expect = [ expectation *( OWS "," OWS expectation ) ]
9785 GMT = %x47.4D.54 ; GMT
9787 HTTP-date = IMF-fixdate / obs-date
9788 Host = uri-host [ ":" port ]
9790 IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
9791 If-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
9792 If-Modified-Since = HTTP-date
9793 If-None-Match = "*" / [ entity-tag *( OWS "," OWS entity-tag ) ]
9794 If-Range = entity-tag / HTTP-date
9795 If-Unmodified-Since = HTTP-date
9797 Last-Modified = HTTP-date
9798 Location = URI-reference
9800 Max-Forwards = 1*DIGIT
9802 OWS = *( SP / HTAB )
9804 Proxy-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
9805 Proxy-Authentication-Info = [ auth-param *( OWS "," OWS auth-param )
9807 Proxy-Authorization = credentials
9809 RWS = 1*( SP / HTAB )
9810 Range = ranges-specifier
9811 Referer = absolute-URI / partial-URI
9812 Retry-After = HTTP-date / delay-seconds
9814 Server = product *( RWS ( product / comment ) )
9816 TE = [ t-codings *( OWS "," OWS t-codings ) ]
9817 Trailer = [ field-name *( OWS "," OWS field-name ) ]
9819 URI-reference = <URI-reference, see [URI], Section 4.1>
9820 Upgrade = [ protocol *( OWS "," OWS protocol ) ]
9821 User-Agent = product *( RWS ( product / comment ) )
9823 Vary = [ ( "*" / field-name ) *( OWS "," OWS ( "*" / field-name ) )
9825 Via = [ ( received-protocol RWS received-by [ RWS comment ] ) *( OWS
9826 "," OWS ( received-protocol RWS received-by [ RWS comment ] ) ) ]
9828 WWW-Authenticate = [ challenge *( OWS "," OWS challenge ) ]
9830 absolute-URI = <absolute-URI, see [URI], Section 4.3>
9831 absolute-path = 1*( "/" segment )
9832 acceptable-ranges = range-unit *( OWS "," OWS range-unit )
9833 asctime-date = day-name SP date3 SP time-of-day SP year
9834 auth-param = token BWS "=" BWS ( token / quoted-string )
9836 authority = <authority, see [URI], Section 3.2>
9838 challenge = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
9839 OWS auth-param ) ] ) ]
9840 codings = content-coding / "identity" / "*"
9841 comment = "(" *( ctext / quoted-pair / comment ) ")"
9842 complete-length = 1*DIGIT
9843 connection-option = token
9844 content-coding = token
9845 credentials = auth-scheme [ 1*SP ( token68 / [ auth-param *( OWS ","
9846 OWS auth-param ) ] ) ]
9847 ctext = HTAB / SP / %x21-27 ; '!'-'''
9852 date1 = day SP month SP year
9853 date2 = day "-" month "-" 2DIGIT
9854 date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
9856 day-name = %x4D.6F.6E ; Mon
9863 day-name-l = %x4D.6F.6E.64.61.79 ; Monday
9864 / %x54.75.65.73.64.61.79 ; Tuesday
9865 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
9866 / %x54.68.75.72.73.64.61.79 ; Thursday
9867 / %x46.72.69.64.61.79 ; Friday
9868 / %x53.61.74.75.72.64.61.79 ; Saturday
9869 / %x53.75.6E.64.61.79 ; Sunday
9870 delay-seconds = 1*DIGIT
9872 entity-tag = [ weak ] opaque-tag
9873 etagc = "!" / %x23-7E ; '#'-'~'
9875 expectation = token [ "=" ( token / quoted-string ) parameters ]
9877 field-content = field-vchar [ 1*( SP / HTAB / field-vchar )
9880 field-value = *field-content
9881 field-vchar = VCHAR / obs-text
9885 http-URI = "http://" authority path-abempty [ "?" query ]
9886 https-URI = "https://" authority path-abempty [ "?" query ]
9888 incl-range = first-pos "-" last-pos
9889 int-range = first-pos "-" [ last-pos ]
9891 language-range = <language-range, see [RFC4647], Section 2.1>
9892 language-tag = <Language-Tag, see [RFC5646], Section 2.1>
9895 mailbox = <mailbox, see [RFC5322], Section 3.4>
9896 media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) )
9898 media-type = type "/" subtype parameters
9901 month = %x4A.61.6E ; Jan
9914 obs-date = rfc850-date / asctime-date
9916 opaque-tag = DQUOTE *etagc DQUOTE
9917 other-range = 1*( %x21-2B ; '!'-'+'
9921 parameter = parameter-name "=" parameter-value
9922 parameter-name = token
9923 parameter-value = ( token / quoted-string )
9924 parameters = *( OWS ";" OWS [ parameter ] )
9925 partial-URI = relative-part [ "?" query ]
9926 path-abempty = <path-abempty, see [URI], Section 3.3>
9927 port = <port, see [URI], Section 3.2.3>
9928 product = token [ "/" product-version ]
9929 product-version = token
9930 protocol = protocol-name [ "/" protocol-version ]
9931 protocol-name = token
9932 protocol-version = token
9935 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
9938 query = <query, see [URI], Section 3.4>
9939 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
9940 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
9941 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
9943 range-resp = incl-range "/" ( complete-length / "*" )
9944 range-set = range-spec *( OWS "," OWS range-spec )
9945 range-spec = int-range / suffix-range / other-range
9947 ranges-specifier = range-unit "=" range-set
9948 received-by = pseudonym [ ":" port ]
9949 received-protocol = [ protocol-name "/" ] protocol-version
9950 relative-part = <relative-part, see [URI], Section 4.2>
9951 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
9954 segment = <segment, see [URI], Section 3.3>
9956 suffix-length = 1*DIGIT
9957 suffix-range = "-" suffix-length
9959 t-codings = "trailers" / ( transfer-coding [ weight ] )
9960 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
9961 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
9962 time-of-day = hour ":" minute ":" second
9964 token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
9966 transfer-coding = token *( OWS ";" OWS transfer-parameter )
9967 transfer-parameter = token BWS "=" BWS ( token / quoted-string )
9970 unsatisfied-range = "*/" complete-length
9971 uri-host = <host, see [URI], Section 3.2.2>
9974 weight = OWS ";" OWS "q=" qvalue
9978Appendix B. Changes from Previous RFCs
9980B.1. Changes from RFC 2818
9984B.2. Changes from RFC 7230
9986 The sections introducing HTTP's design goals, history, architecture,
9987 conformance criteria, protocol versioning, URIs, message routing, and
9988 header fields have been moved here.
9990 The requirement on semantic conformance has been replaced with
9991 permission to ignore or work around implementation-specific failures.
9994 The description of an origin and authoritative access to origin
9995 servers has been extended for both "http" and "https" URIs to account
9996 for alternative services and secured connections that are not
9997 necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)
9999 Explicit requirements have been added to check the target URI
10000 scheme's semantics and reject requests that don't meet any associated
10001 requirements. (Section 7.4)
10003 Parameters in media type, media range, and expectation can be empty
10004 via one or more trailing semicolons. (Section 5.6.6)
10006 "Field value" now refers to the value after multiple field lines are
10007 combined with commas -- by far the most common use. To refer to a
10008 single header line's value, use "field line value". (Section 6.3)
10010 Trailer field semantics now transcend the specifics of chunked
10011 transfer coding. The use of trailer fields has been further limited
10012 to allow generation as a trailer field only when the sender knows the
10013 field defines that usage and to allow merging into the header section
10014 only if the recipient knows the corresponding field definition
10015 permits and defines how to merge. In all other cases,
10016 implementations are encouraged either to store the trailer fields
10017 separately or to discard them instead of merging. (Section 6.5.1)
10019 The priority of the absolute form of the request URI over the Host
10020 header field by origin servers has been made explicit to align with
10021 proxy handling. (Section 7.2)
10023 The grammar definition for the Via field's "received-by" was expanded
10024 in RFC 7230 due to changes in the URI grammar for host [URI] that are
10025 not desirable for Via. For simplicity, we have removed uri-host from
10026 the received-by production because it can be encompassed by the
10027 existing grammar for pseudonym. In particular, this change removed
10028 comma from the allowed set of characters for a host name in received-
10029 by. (Section 7.6.3)
10031B.3. Changes from RFC 7231
10033 Minimum URI lengths to be supported by implementations are now
10034 recommended. (Section 4.1)
10036 The following have been clarified: CR and NUL in field values are to
10037 be rejected or mapped to SP, and leading and trailing whitespace
10038 needs to be stripped from field values before they are consumed.
10041 Parameters in media type, media range, and expectation can be empty
10042 via one or more trailing semicolons. (Section 5.6.6)
10044 An abstract data type for HTTP messages has been introduced to define
10045 the components of a message and their semantics as an abstraction
10046 across multiple HTTP versions, rather than in terms of the specific
10047 syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after
10048 the message is parsed. This makes it easier to distinguish between
10049 requirements on the content (what is conveyed) versus requirements on
10050 the messaging syntax (how it is conveyed) and avoids baking
10051 limitations of early protocol versions into the future of HTTP.
10054 The terms "payload" and "payload body" have been replaced with
10055 "content", to better align with its usage elsewhere (e.g., in field
10056 names) and to avoid confusion with frame payloads in HTTP/2 and
10057 HTTP/3. (Section 6.4)
10059 The term "effective request URI" has been replaced with "target URI".
10062 Restrictions on client retries have been loosened to reflect
10063 implementation behavior. (Section 9.2.2)
10065 The fact that request bodies on GET, HEAD, and DELETE are not
10066 interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)
10068 The use of the Content-Range header field (Section 14.4) as a request
10069 modifier on PUT is allowed. (Section 9.3.4)
10071 A superfluous requirement about setting Content-Length has been
10072 removed from the description of the OPTIONS method. (Section 9.3.7)
10074 The normative requirement to use the "message/http" media type in
10075 TRACE responses has been removed. (Section 9.3.8)
10077 List-based grammar for Expect has been restored for compatibility
10078 with RFC 2616. (Section 10.1.1)
10080 Accept and Accept-Encoding are allowed in response messages; the
10081 latter was introduced by [RFC7694]. (Section 12.3)
10083 "Accept Parameters" (accept-params and accept-ext ABNF production)
10084 have been removed from the definition of the Accept field.
10087 The Accept-Charset field is now deprecated. (Section 12.5.2)
10089 The semantics of "*" in the Vary header field when other values are
10090 present was clarified. (Section 12.5.5)
10092 Range units are compared in a case-insensitive fashion.
10095 The use of the Accept-Ranges field is not restricted to origin
10096 servers. (Section 14.3)
10098 The process of creating a redirected request has been clarified.
10101 Status code 308 (previously defined in [RFC7538]) has been added so
10102 that it's defined closer to status codes 301, 302, and 307.
10105 Status code 421 (previously defined in Section 9.1.2 of [RFC7540])
10106 has been added because of its general applicability. 421 is no longer
10107 defined as heuristically cacheable since the response is specific to
10108 the connection (not the target resource). (Section 15.5.20)
10110 Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has
10111 been added because of its general applicability. (Section 15.5.21)
10113B.4. Changes from RFC 7232
10115 Previous revisions of HTTP imposed an arbitrary 60-second limit on
10116 the determination of whether Last-Modified was a strong validator to
10117 guard against the possibility that the Date and Last-Modified values
10118 are generated from different clocks or at somewhat different times
10119 during the preparation of the response. This specification has
10120 relaxed that to allow reasonable discretion. (Section 8.8.2.2)
10122 An edge-case requirement on If-Match and If-Unmodified-Since has been
10123 removed that required a validator not to be sent in a 2xx response if
10124 validation fails because the change request has already been applied.
10125 (Sections 13.1.1 and 13.1.4)
10127 The fact that If-Unmodified-Since does not apply to a resource
10128 without a concept of modification time has been clarified.
10131 Preconditions can now be evaluated before the request content is
10132 processed rather than waiting until the response would otherwise be
10133 successful. (Section 13.2)
10135B.5. Changes from RFC 7233
10137 Refactored the range-unit and ranges-specifier grammars to simplify
10138 and reduce artificial distinctions between bytes and other
10139 (extension) range units, removing the overlapping grammar of other-
10140 range-unit by defining range units generically as a token and placing
10141 extensions within the scope of a range-spec (other-range). This
10142 disambiguates the role of list syntax (commas) in all range sets,
10143 including extension range units, for indicating a range-set of more
10144 than one range. Moving the extension grammar into range specifiers
10145 also allows protocol specific to byte ranges to be specified
10148 It is now possible to define Range handling on extension methods.
10151 Described use of the Content-Range header field (Section 14.4) as a
10152 request modifier to perform a partial PUT. (Section 14.5)
10154B.6. Changes from RFC 7235
10158B.7. Changes from RFC 7538
10162B.8. Changes from RFC 7615
10166B.9. Changes from RFC 7694
10168 This specification includes the extension defined in [RFC7694] but
10169 leaves out examples and deployment considerations.
10173 Aside from the current editors, the following individuals deserve
10174 special recognition for their contributions to early aspects of HTTP
10175 and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
10176 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
10177 Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
10178 L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
10179 D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
10180 Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
10181 Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders,
10182 Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
10184 This document builds on the many contributions that went into past
10185 specifications of HTTP, including [HTTP/1.0], [RFC2068], [RFC2145],
10186 [RFC2616], [RFC2617], [RFC2818], [RFC7230], [RFC7231], [RFC7232],
10187 [RFC7233], [RFC7234], and [RFC7235]. The acknowledgements within
10188 those documents still apply.
10190 Since 2014, the following contributors have helped improve this
10191 specification by reporting bugs, asking smart questions, drafting or
10192 reviewing text, and evaluating issues:
10194 Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders
10195 Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron
10196 Duby, Asanka Herath, Asbjørn Ulsberg, Asta Olofsson, Attila Gulyas,
10197 Austin Wright, Barry Pollard, Ben Burkert, Benjamin Kaduk, Björn
10198 Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory
10199 Benfield, Cory Nelson, Daisuke Miyakawa, Dale Worley, Daniel
10200 Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi,
10201 Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla,
10202 Vyncke, Erik Kline, Erwin Pe, Etan Kissling, Evert Pot, Evgeny
10203 Vrublevsky, Florian Best, Francesca Palombini, Igor Lubashev, James
10204 Callahan, James Peach, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan,
10205 奥 一穂 (Kazuho Oku), Ken Murchison, Krzysztof Maczyński, Lars Eggert,
10206 Lucas Pardue, Martin Duke, Martin Dürst, Martin Thomson, Martynas
10207 Jusevičius, Matt Menke, Matthias Pigulla, Mattias Grenfeldt, Michael
10208 Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Mohit
10209 Sethi, Murray Kucherawy, Nathaniel J. Smith, Nicholas Hurley, Nikita
10210 Prokhorov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van
10211 Rein, Robert Wilton, Roberto Polli, Roman Danyliw, Samuel Williams,
10212 Semyon Kholodnov, Simon Pieters, Simon Schüppel, Stefan Eissing,
10213 Taylor Hunt, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir
10214 Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu,
10215 Yishuai Li, and Zaheduzzaman Sarker.
10219 1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
10223 100 Continue (status code) *_Section 15.2.1_*
10224 100-continue (expect value) *_Section 10.1.1_*
10225 101 Switching Protocols (status code) *_Section 15.2.2_*
10226 1xx Informational (status code class) *_Section 15.2_*
10230 200 OK (status code) *_Section 15.3.1_*
10231 201 Created (status code) *_Section 15.3.2_*
10232 202 Accepted (status code) *_Section 15.3.3_*
10233 203 Non-Authoritative Information (status code) *_Section 15.3
10235 204 No Content (status code) *_Section 15.3.5_*
10236 205 Reset Content (status code) *_Section 15.3.6_*
10237 206 Partial Content (status code) *_Section 15.3.7_*
10238 2xx Successful (status code class) *_Section 15.3_*
10242 300 Multiple Choices (status code) *_Section 15.4.1_*
10243 301 Moved Permanently (status code) *_Section 15.4.2_*
10244 302 Found (status code) *_Section 15.4.3_*
10245 303 See Other (status code) *_Section 15.4.4_*
10246 304 Not Modified (status code) *_Section 15.4.5_*
10247 305 Use Proxy (status code) *_Section 15.4.6_*
10248 306 (Unused) (status code) *_Section 15.4.7_*
10249 307 Temporary Redirect (status code) *_Section 15.4.8_*
10250 308 Permanent Redirect (status code) *_Section 15.4.9_*
10251 3xx Redirection (status code class) *_Section 15.4_*
10255 400 Bad Request (status code) *_Section 15.5.1_*
10256 401 Unauthorized (status code) *_Section 15.5.2_*
10257 402 Payment Required (status code) *_Section 15.5.3_*
10258 403 Forbidden (status code) *_Section 15.5.4_*
10259 404 Not Found (status code) *_Section 15.5.5_*
10260 405 Method Not Allowed (status code) *_Section 15.5.6_*
10261 406 Not Acceptable (status code) *_Section 15.5.7_*
10262 407 Proxy Authentication Required (status code) *_Section 15.5
10264 408 Request Timeout (status code) *_Section 15.5.9_*
10265 409 Conflict (status code) *_Section 15.5.10_*
10266 410 Gone (status code) *_Section 15.5.11_*
10267 411 Length Required (status code) *_Section 15.5.12_*
10268 412 Precondition Failed (status code) *_Section 15.5.13_*
10269 413 Content Too Large (status code) *_Section 15.5.14_*
10270 414 URI Too Long (status code) *_Section 15.5.15_*
10271 415 Unsupported Media Type (status code) *_Section 15.5.16_*
10272 416 Range Not Satisfiable (status code) *_Section 15.5.17_*
10273 417 Expectation Failed (status code) *_Section 15.5.18_*
10274 418 (Unused) (status code) *_Section 15.5.19_*
10275 421 Misdirected Request (status code) *_Section 15.5.20_*
10276 422 Unprocessable Content (status code) *_Section 15.5.21_*
10277 426 Upgrade Required (status code) *_Section 15.5.22_*
10278 4xx Client Error (status code class) *_Section 15.5_*
10282 500 Internal Server Error (status code) *_Section 15.6.1_*
10283 501 Not Implemented (status code) *_Section 15.6.2_*
10284 502 Bad Gateway (status code) *_Section 15.6.3_*
10285 503 Service Unavailable (status code) *_Section 15.6.4_*
10286 504 Gateway Timeout (status code) *_Section 15.6.5_*
10287 505 HTTP Version Not Supported (status code) *_Section 15.6.6_
10289 5xx Server Error (status code class) *_Section 15.6_*
10293 accelerator *_Section 3.7, Paragraph 6_*
10294 Accept header field *_Section 12.5.1_*
10295 Accept-Charset header field *_Section 12.5.2_*
10296 Accept-Encoding header field *_Section 12.5.3_*
10297 Accept-Language header field *_Section 12.5.4_*
10298 Accept-Ranges header field *_Section 14.3_*
10299 Allow header field *_Section 10.2.1_*
10300 Authentication-Info header field *_Section 11.6.3_*
10301 authoritative response *_Section 17.1_*
10302 Authorization header field *_Section 11.6.2_*
10306 browser *_Section 3.5_*
10310 cache *_Section 3.8_*
10311 cacheable *_Section 3.8, Paragraph 4_*
10312 client *_Section 3.3_*
10313 clock *_Section 5.6.7_*
10314 complete *_Section 6.1_*
10315 compress (Coding Format) Section 8.4.1.1
10316 compress (content coding) *_Section 8.4.1_*
10317 conditional request *_Section 13_*
10318 CONNECT method *_Section 9.3.6_*
10319 connection *_Section 3.3_*
10320 Connection header field *_Section 7.6.1_*
10321 content Section 6.4
10322 content coding *_Section 8.4.1_*
10323 content negotiation Section 1.3, Paragraph 4
10324 Content-Encoding header field *_Section 8.4_*
10325 Content-Language header field *_Section 8.5_*
10326 Content-Length header field *_Section 8.6_*
10327 Content-Location header field *_Section 8.7_*
10328 Content-MD5 header field *_Section 18.4, Paragraph 10_*
10329 Content-Range header field *_Section 14.4_*; Section 14.5
10330 Content-Type header field *_Section 8.3_*
10331 control data *_Section 6.2_*
10335 Date header field *_Section 6.6.1_*
10336 deflate (Coding Format) Section 8.4.1.2
10337 deflate (content coding) *_Section 8.4.1_*
10338 DELETE method *_Section 9.3.5_*
10339 Delimiters Section 5.6.2, Paragraph 3
10340 downstream *_Section 3.7, Paragraph 4_*
10344 effective request URI *_Section 7.1, Paragraph 8.1_*
10345 ETag field *_Section 8.8.3_*
10346 Expect header field *_Section 10.1.1_*
10350 field *_Section 5_*; Section 6.3
10351 field line Section 5.2, Paragraph 1
10352 field line value Section 5.2, Paragraph 1
10353 field name Section 5.2, Paragraph 1
10354 field value Section 5.2, Paragraph 2
10356 * *_Section 18.4, Paragraph 9_*
10357 Accept *_Section 12.5.1_*
10358 Accept-Charset *_Section 12.5.2_*
10359 Accept-Encoding *_Section 12.5.3_*
10360 Accept-Language *_Section 12.5.4_*
10361 Accept-Ranges *_Section 14.3_*
10362 Allow *_Section 10.2.1_*
10363 Authentication-Info *_Section 11.6.3_*
10364 Authorization *_Section 11.6.2_*
10365 Connection *_Section 7.6.1_*
10366 Content-Encoding *_Section 8.4_*
10367 Content-Language *_Section 8.5_*
10368 Content-Length *_Section 8.6_*
10369 Content-Location *_Section 8.7_*
10370 Content-MD5 *_Section 18.4, Paragraph 10_*
10371 Content-Range *_Section 14.4_*; Section 14.5
10372 Content-Type *_Section 8.3_*
10373 Date *_Section 6.6.1_*
10374 ETag *_Section 8.8.3_*
10375 Expect *_Section 10.1.1_*
10376 From *_Section 10.1.2_*
10377 Host *_Section 7.2_*
10378 If-Match *_Section 13.1.1_*
10379 If-Modified-Since *_Section 13.1.3_*
10380 If-None-Match *_Section 13.1.2_*
10381 If-Range *_Section 13.1.5_*
10382 If-Unmodified-Since *_Section 13.1.4_*
10383 Last-Modified *_Section 8.8.2_*
10384 Location *_Section 10.2.2_*
10385 Max-Forwards *_Section 7.6.2_*
10386 Proxy-Authenticate *_Section 11.7.1_*
10387 Proxy-Authentication-Info *_Section 11.7.3_*
10388 Proxy-Authorization *_Section 11.7.2_*
10389 Range *_Section 14.2_*
10390 Referer *_Section 10.1.3_*
10391 Retry-After *_Section 10.2.3_*
10392 Server *_Section 10.2.4_*
10393 TE *_Section 10.1.4_*
10394 Trailer *_Section 6.6.2_*
10395 Upgrade *_Section 7.8_*
10396 User-Agent *_Section 10.1.5_*
10397 Vary *_Section 12.5.5_*
10398 Via *_Section 7.6.3_*
10399 WWW-Authenticate *_Section 11.6.1_*
10400 Fragment Identifiers Section 4.2.5
10401 From header field *_Section 10.1.2_*
10405 gateway *_Section 3.7, Paragraph 6_*
10406 GET method *_Section 9.3.1_*
10408 ALPHA *_Section 2.1_*
10409 Accept *_Section 12.5.1_*
10410 Accept-Charset *_Section 12.5.2_*
10411 Accept-Encoding *_Section 12.5.3_*
10412 Accept-Language *_Section 12.5.4_*
10413 Accept-Ranges *_Section 14.3_*
10414 Allow *_Section 10.2.1_*
10415 Authentication-Info *_Section 11.6.3_*
10416 Authorization *_Section 11.6.2_*
10417 BWS *_Section 5.6.3_*
10419 CRLF *_Section 2.1_*
10420 CTL *_Section 2.1_*
10421 Connection *_Section 7.6.1_*
10422 Content-Encoding *_Section 8.4_*
10423 Content-Language *_Section 8.5_*
10424 Content-Length *_Section 8.6_*
10425 Content-Location *_Section 8.7_*
10426 Content-Range *_Section 14.4_*
10427 Content-Type *_Section 8.3_*
10428 DIGIT *_Section 2.1_*
10429 DQUOTE *_Section 2.1_*
10430 Date *_Section 6.6.1_*
10431 ETag *_Section 8.8.3_*
10432 Expect *_Section 10.1.1_*
10433 From *_Section 10.1.2_*
10434 GMT *_Section 5.6.7_*
10435 HEXDIG *_Section 2.1_*
10436 HTAB *_Section 2.1_*
10437 HTTP-date *_Section 5.6.7_*
10438 Host *_Section 7.2_*
10439 IMF-fixdate *_Section 5.6.7_*
10440 If-Match *_Section 13.1.1_*
10441 If-Modified-Since *_Section 13.1.3_*
10442 If-None-Match *_Section 13.1.2_*
10443 If-Range *_Section 13.1.5_*
10444 If-Unmodified-Since *_Section 13.1.4_*
10446 Last-Modified *_Section 8.8.2_*
10447 Location *_Section 10.2.2_*
10448 Max-Forwards *_Section 7.6.2_*
10449 OCTET *_Section 2.1_*
10450 OWS *_Section 5.6.3_*
10451 Proxy-Authenticate *_Section 11.7.1_*
10452 Proxy-Authentication-Info *_Section 11.7.3_*
10453 Proxy-Authorization *_Section 11.7.2_*
10454 RWS *_Section 5.6.3_*
10455 Range *_Section 14.2_*
10456 Referer *_Section 10.1.3_*
10457 Retry-After *_Section 10.2.3_*
10459 Server *_Section 10.2.4_*
10460 TE *_Section 10.1.4_*
10461 Trailer *_Section 6.6.2_*
10462 URI-reference *_Section 4.1_*
10463 Upgrade *_Section 7.8_*
10464 User-Agent *_Section 10.1.5_*
10465 VCHAR *_Section 2.1_*
10466 Vary *_Section 12.5.5_*
10467 Via *_Section 7.6.3_*
10468 WWW-Authenticate *_Section 11.6.1_*
10469 absolute-URI *_Section 4.1_*
10470 absolute-path *_Section 4.1_*
10471 acceptable-ranges *_Section 14.3_*
10472 asctime-date *_Section 5.6.7_*
10473 auth-param *_Section 11.2_*
10474 auth-scheme *_Section 11.1_*
10475 authority *_Section 4.1_*
10476 challenge *_Section 11.3_*
10477 codings *_Section 12.5.3_*
10478 comment *_Section 5.6.5_*
10479 complete-length *_Section 14.4_*
10480 connection-option *_Section 7.6.1_*
10481 content-coding *_Section 8.4.1_*
10482 credentials *_Section 11.4_*
10483 ctext *_Section 5.6.5_*
10484 date1 *_Section 5.6.7_*
10485 day *_Section 5.6.7_*
10486 day-name *_Section 5.6.7_*
10487 day-name-l *_Section 5.6.7_*
10488 delay-seconds *_Section 10.2.3_*
10489 entity-tag *_Section 8.8.3_*
10490 etagc *_Section 8.8.3_*
10491 field-content *_Section 5.5_*
10492 field-name *_Section 5.1_*; Section 6.6.2
10493 field-value *_Section 5.5_*
10494 field-vchar *_Section 5.5_*
10495 first-pos *_Section 14.1.1_*; Section 14.4
10496 hour *_Section 5.6.7_*
10497 http-URI *_Section 4.2.1_*
10498 https-URI *_Section 4.2.2_*
10499 incl-range *_Section 14.4_*
10500 int-range *_Section 14.1.1_*
10501 language-range *_Section 12.5.4_*
10502 language-tag *_Section 8.5.1_*
10503 last-pos *_Section 14.1.1_*; Section 14.4
10504 media-range *_Section 12.5.1_*
10505 media-type *_Section 8.3.1_*
10506 method *_Section 9.1_*
10507 minute *_Section 5.6.7_*
10508 month *_Section 5.6.7_*
10509 obs-date *_Section 5.6.7_*
10510 obs-text *_Section 5.5_*
10511 opaque-tag *_Section 8.8.3_*
10512 other-range *_Section 14.1.1_*
10513 parameter *_Section 5.6.6_*
10514 parameter-name *_Section 5.6.6_*
10515 parameter-value *_Section 5.6.6_*
10516 parameters *_Section 5.6.6_*
10517 partial-URI *_Section 4.1_*
10518 port *_Section 4.1_*
10519 product *_Section 10.1.5_*
10520 product-version *_Section 10.1.5_*
10521 protocol-name *_Section 7.6.3_*
10522 protocol-version *_Section 7.6.3_*
10523 pseudonym *_Section 7.6.3_*
10524 qdtext *_Section 5.6.4_*
10525 query *_Section 4.1_*
10526 quoted-pair *_Section 5.6.4_*
10527 quoted-string *_Section 5.6.4_*
10528 qvalue *_Section 12.4.2_*
10529 range-resp *_Section 14.4_*
10530 range-set *_Section 14.1.1_*
10531 range-spec *_Section 14.1.1_*
10532 range-unit *_Section 14.1_*
10533 ranges-specifier *_Section 14.1.1_*
10534 received-by *_Section 7.6.3_*
10535 received-protocol *_Section 7.6.3_*
10536 rfc850-date *_Section 5.6.7_*
10537 second *_Section 5.6.7_*
10538 segment *_Section 4.1_*
10539 subtype *_Section 8.3.1_*
10540 suffix-length *_Section 14.1.1_*
10541 suffix-range *_Section 14.1.1_*
10542 t-codings *_Section 10.1.4_*
10543 tchar *_Section 5.6.2_*
10544 time-of-day *_Section 5.6.7_*
10545 token *_Section 5.6.2_*
10546 token68 *_Section 11.2_*
10547 transfer-coding *_Section 10.1.4_*
10548 transfer-parameter *_Section 10.1.4_*
10549 type *_Section 8.3.1_*
10550 unsatisfied-range *_Section 14.4_*
10551 uri-host *_Section 4.1_*
10552 weak *_Section 8.8.3_*
10553 weight *_Section 12.4.2_*
10554 year *_Section 5.6.7_*
10555 gzip (Coding Format) Section 8.4.1.3
10556 gzip (content coding) *_Section 8.4.1_*
10560 HEAD method *_Section 9.3.2_*
10562 Accept *_Section 12.5.1_*
10563 Accept-Charset *_Section 12.5.2_*
10564 Accept-Encoding *_Section 12.5.3_*
10565 Accept-Language *_Section 12.5.4_*
10566 Accept-Ranges *_Section 14.3_*
10567 Allow *_Section 10.2.1_*
10568 Authentication-Info *_Section 11.6.3_*
10569 Authorization *_Section 11.6.2_*
10570 Connection *_Section 7.6.1_*
10571 Content-Encoding *_Section 8.4_*
10572 Content-Language *_Section 8.5_*
10573 Content-Length *_Section 8.6_*
10574 Content-Location *_Section 8.7_*
10575 Content-MD5 *_Section 18.4, Paragraph 10_*
10576 Content-Range *_Section 14.4_*; Section 14.5
10577 Content-Type *_Section 8.3_*
10578 Date *_Section 6.6.1_*
10579 ETag *_Section 8.8.3_*
10580 Expect *_Section 10.1.1_*
10581 From *_Section 10.1.2_*
10582 Host *_Section 7.2_*
10583 If-Match *_Section 13.1.1_*
10584 If-Modified-Since *_Section 13.1.3_*
10585 If-None-Match *_Section 13.1.2_*
10586 If-Range *_Section 13.1.5_*
10587 If-Unmodified-Since *_Section 13.1.4_*
10588 Last-Modified *_Section 8.8.2_*
10589 Location *_Section 10.2.2_*
10590 Max-Forwards *_Section 7.6.2_*
10591 Proxy-Authenticate *_Section 11.7.1_*
10592 Proxy-Authentication-Info *_Section 11.7.3_*
10593 Proxy-Authorization *_Section 11.7.2_*
10594 Range *_Section 14.2_*
10595 Referer *_Section 10.1.3_*
10596 Retry-After *_Section 10.2.3_*
10597 Server *_Section 10.2.4_*
10598 TE *_Section 10.1.4_*
10599 Trailer *_Section 6.6.2_*
10600 Upgrade *_Section 7.8_*
10601 User-Agent *_Section 10.1.5_*
10602 Vary *_Section 12.5.5_*
10603 Via *_Section 7.6.3_*
10604 WWW-Authenticate *_Section 11.6.1_*
10605 header section *_Section 6.3_*
10606 Host header field *_Section 7.2_*
10607 http URI scheme *_Section 4.2.1_*
10608 https URI scheme *_Section 4.2.2_*
10612 idempotent *_Section 9.2.2_*
10613 If-Match header field *_Section 13.1.1_*
10614 If-Modified-Since header field *_Section 13.1.3_*
10615 If-None-Match header field *_Section 13.1.2_*
10616 If-Range header field *_Section 13.1.5_*
10617 If-Unmodified-Since header field *_Section 13.1.4_*
10618 inbound *_Section 3.7, Paragraph 4_*
10619 incomplete *_Section 6.1_*
10620 interception proxy *_Section 3.7, Paragraph 10_*
10621 intermediary *_Section 3.7_*
10625 Last-Modified header field *_Section 8.8.2_*
10626 list-based field Section 5.5, Paragraph 7
10627 Location header field *_Section 10.2.2_*
10631 Max-Forwards header field *_Section 7.6.2_*
10633 multipart/byteranges *_Section 14.6_*
10634 multipart/x-byteranges Section 14.6, Paragraph 4, Item 3
10635 message Section 3.4; *_Section 6_*
10636 message abstraction *_Section 6_*
10637 messages *_Section 3.4_*
10638 metadata *_Section 8.8_*
10640 * *_Section 18.2, Paragraph 3_*
10641 CONNECT *_Section 9.3.6_*
10642 DELETE *_Section 9.3.5_*
10643 GET *_Section 9.3.1_*
10644 HEAD *_Section 9.3.2_*
10645 OPTIONS *_Section 9.3.7_*
10646 POST *_Section 9.3.3_*
10647 PUT *_Section 9.3.4_*
10648 TRACE *_Section 9.3.8_*
10649 multipart/byteranges Media Type *_Section 14.6_*
10650 multipart/x-byteranges Media Type Section 14.6, Paragraph 4,
10655 non-transforming proxy *_Section 7.7_*
10659 OPTIONS method *_Section 9.3.7_*
10660 origin *_Section 4.3.1_*; Section 11.5
10661 origin server *_Section 3.6_*
10662 outbound *_Section 3.7, Paragraph 4_*
10666 phishing *_Section 17.1_*
10667 POST method *_Section 9.3.3_*
10668 Protection Space Section 11.5
10669 proxy *_Section 3.7, Paragraph 5_*
10670 Proxy-Authenticate header field *_Section 11.7.1_*
10671 Proxy-Authentication-Info header field *_Section 11.7.3_*
10672 Proxy-Authorization header field *_Section 11.7.2_*
10673 PUT method *_Section 9.3.4_*
10677 Range header field *_Section 14.2_*
10679 recipient *_Section 3.4_*
10680 Referer header field *_Section 10.1.3_*
10681 representation *_Section 3.2_*
10682 request *_Section 3.4_*
10683 request target *_Section 7.1_*
10684 resource *_Section 3.1_*; Section 4
10685 response *_Section 3.4_*
10686 Retry-After header field *_Section 10.2.3_*
10687 reverse proxy *_Section 3.7, Paragraph 6_*
10691 safe *_Section 9.2.1_*
10692 satisfiable range *_Section 14.1.1_*
10693 secured *_Section 4.2.2_*
10694 selected representation *_Section 3.2, Paragraph 4_*;
10695 Section 8.8; Section 13.1
10696 self-descriptive *_Section 6_*
10697 sender *_Section 3.4_*
10698 server *_Section 3.3_*
10699 Server header field *_Section 10.2.4_*
10700 singleton field Section 5.5, Paragraph 6
10701 spider *_Section 3.5_*
10702 Status Code Section 15
10704 Final Section 15, Paragraph 7
10705 Informational Section 15, Paragraph 7
10706 Interim Section 15, Paragraph 7
10707 Status Codes Classes
10708 1xx Informational *_Section 15.2_*
10709 2xx Successful *_Section 15.3_*
10710 3xx Redirection *_Section 15.4_*
10711 4xx Client Error *_Section 15.5_*
10712 5xx Server Error *_Section 15.6_*
10716 target resource *_Section 7.1_*
10717 target URI *_Section 7.1_*
10718 TE header field *_Section 10.1.4_*
10719 TRACE method *_Section 9.3.8_*
10720 Trailer Fields *_Section 6.5_*
10721 ETag *_Section 8.8.3_*
10722 Trailer header field *_Section 6.6.2_*
10723 trailer section *_Section 6.5_*
10724 trailers *_Section 6.5_*
10725 transforming proxy *_Section 7.7_*
10726 transparent proxy *_Section 3.7, Paragraph 10_*
10727 tunnel *_Section 3.7, Paragraph 8_*
10731 unsatisfiable range *_Section 14.1.1_*
10732 Upgrade header field *_Section 7.8_*
10733 upstream *_Section 3.7, Paragraph 4_*
10735 origin *_Section 4.3.1_*
10736 URI reference *_Section 4.1_*
10738 http *_Section 4.2.1_*
10739 https *_Section 4.2.2_*
10740 user agent *_Section 3.5_*
10741 User-Agent header field *_Section 10.1.5_*
10745 validator *_Section 8.8_*
10746 strong *_Section 8.8.1_*
10747 weak *_Section 8.8.1_*
10748 Vary header field *_Section 12.5.5_*
10749 Via header field *_Section 7.6.3_*
10753 WWW-Authenticate header field *_Section 11.6.1_*
10757 x-compress (content coding) *_Section 8.4.1_*
10758 x-gzip (content coding) *_Section 8.4.1_*
10762 Roy T. Fielding (editor)
10766 United States of America
10767 Email: fielding@gbiv.com
10768 URI: https://roy.gbiv.com/
10771 Mark Nottingham (editor)
10775 Email: mnot@mnot.net
10776 URI: https://www.mnot.net/
10779 Julian Reschke (editor)
10784 Email: julian.reschke@greenbytes.de
10785 URI: https://greenbytes.de/tech/webdav/