RFC 2774
An HTTP Extension Framework
Part 1 of 4 🎀
Title Block ✨
Okay bestie, this one is RFC 2774: An HTTP Extension Framework 🦋 It came out of the Network Working Group in February 2000. The authors are H. Nielsen and P. Leach from Microsoft, and S. Lawrence from Agranat Systems. It's an Experimental doc, which means it's not an Internet standard (more on that in a sec 🧪). The header doesn't list anything it obsoletes or updates, so there's no other RFC it's replacing or changing.
Status of This Memo 💜
This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors want discussion and suggestions for improvement, and distribution of this memo is unlimited. Share it, argue about it, make it better 💅
Copyright Notice 🌸
Copyright (C) The Internet Society (2000). All Rights Reserved.
IESG Note 🙈
This document was originally requested for Proposed Standard status. Because the reviews were mixed during Last Call and within the HTTP working group, it got published as an Experimental document instead. That isn't necessarily a sign of technical flaws. The bigger worry is whether this document really reflects community consensus about where HTTP should go next. More study and discussion are needed before anyone can decide that ⭐
Also, when HTTP is used as a base for other protocols, it might make sense to use other extension mechanisms alongside these ones or instead of them. So this document shouldn't be treated as a blueprint for adding extensions to HTTP. It does define mechanisms that could be useful in those situations 🧚
Abstract ✨
Lots of applications have proposed their own extensions to HTTP, and they cover a huge range: distributed authoring, collaboration, printing, and remote procedure calls. Right now these extensions aren't coordinated, because there's never been a standard framework for defining them, so nobody has a clean way to separate concerns. This document describes a generic extension mechanism for HTTP. It's built to balance private agreement against public specification, and to let HTTP clients, servers, and proxies get extended for applications. Each extension gets a globally unique identifier, and HTTP header fields carry that identifier and related info between the parties in the extended conversation 🦋
Table of Contents 📋
1. Introduction ...............................................3
2. Notational Conventions .....................................3
3. Extension Declarations .....................................4
3.1 Header Field Prefixes ...................................5
4. Extension Header Fields ....................................6
4.1 End-to-End Extensions ...................................7
4.2 Hop-by-Hop Extensions ...................................7
4.3 Extension Response Header Fields ........................8
5. Mandatory HTTP Requests ....................................8
5.1 Fulfilling a Mandatory Request .........................10
6. Mandatory HTTP Responses ..................................11
7. 510 Not Extended ..........................................11
8. Publishing an Extension ...................................11
9. Caching Considerations ....................................12
10. Security Considerations ...................................13
11. References ................................................13
12. Acknowledgements ..........................................14
13. Authors' Addresses ........................................14
14. Summary of Protocol Interactions ..........................15
15. Examples ..................................................16
15.1 User Agent to Origin Server ............................16
15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........17
15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........18
Full Copyright Statement ......................................201. Introduction 🎀
Okay so the whole point here is balancing private agreement with public specification, and letting HTTP clients and servers pick up new behaviour from software components while they're running. The kinds of extensions you can add go all the way from:
- extending a single HTTP message;
- introducing new encodings;
- initiating HTTP-derived protocols for new applications; to...
- switching to protocols which, once initiated, run independent of the original protocol stack.
Here's how it's meant to work, step by step 💖
- Someone designs and specifies an extension. They give it a globally unique URI and put one or more representations of it at that address (see section 8).
- An HTTP client or server that supports this extension mechanism (called an agent from here on) announces that it's using the extension by pointing to its URI in an extension declaration inside an HTTP message (see section 3).
- The HTTP application the extension declaration is meant for (called the ultimate recipient) can work out how to read the extended message from that declaration 🧠
This proposal uses features from HTTP/1.1 but still plays nicely with HTTP/1.0 apps, so extended apps and existing HTTP apps can coexist. Applications implementing this proposal MUST be based on HTTP/1.1 (or later versions of HTTP) 🔥
2. Notational Conventions 📝
This spec uses the same notation and basic parsing building blocks as RFC 2068 [5]. Specifically, the BNF constructs "token", "quoted-string", "Request-Line", "field-name", and "absoluteURI" in this document should be read the way RFC 2068 [5] describes them.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6] 👑
This proposal doesn't depend on particular features of URLs [8] that can't possibly be expressed as URNs (see section 8). So the more generic term URI [8] gets used all the way through the spec 🦋
3. Extension Declarations 💅
An extension declaration can say that an extension has been applied to a message, and it can also reserve a chunk of the header namespace using a header field prefix (see 3.1). This section defines the extension declaration itself. Section 4 then defines a set of header fields that use it 💜
This spec doesn't define what applying an extension to a message actually does, and it doesn't say whether two extensions can or can't logically coexist in one message. It's just a framework for describing which extensions got applied, and for spelling out what the ultimate recipient has to do, or is allowed to do, to correctly read any extension declarations in that message 🧚
The grammar for an extension declaration looks like this:
ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]
namespace = ";" "ns" "=" header-prefix
header-prefix = 2*DIGIT
decl-extensions = *( decl-ext )
decl-ext = ";" token [ "=" ( token | quoted-string ) ]An extension is identified by either an absolute, globally unique URI or a field-name. A field-name MUST specify a header field that's uniquely defined in an IETF Standards Track RFC [3]. You can tell a URI apart from a field-name because a URI has a colon (":") in it ✨
Allowing header field names as extension identifiers is a transition strategy, moving us from decentralized extensions toward extensions defined in IETF Standards Track RFCs. This carries on until the globally unique URI space gets mapped to features defined in IETF Standards Track RFCs, following the guidelines in section 8 🌈
Here are some example extension declarations:
"http://www.company.com/extension"; ns=11
"Range"An agent MAY use the decl-extensions mechanism to include optional extension declaration parameters, but it can't count on the recipient recognizing those parameters. An agent MUST NOT use decl-extensions to pass extension instance data. That data MAY be passed using header field prefix values instead (see section 3.1). Unrecognized decl-ext parameters SHOULD be ignored, and proxies MUST NOT remove them when forwarding the extension declaration 🫶
3.1 Header Field Prefixes 🦋
The header-prefix is a dynamically generated string. Any header field in the message whose name matches that string, using string prefix-matching, belongs to that extension declaration. Header field prefixes let an extension declaration reserve a subspace of the header space in a protocol message. That stops header field name clashes and lets several declarations using the same extension sit in the same message without conflicting 💖
Header fields that use a header-prefix look like this:
prefixed-header = prefix-match field-name
prefix-match = header-prefix "-"Linear white space (LWS) MUST NOT be used between the header-prefix and the dash ("-"), or between the prefix-match and the field-name. The string prefix matching algorithm is applied to the prefix-match string 💅
Using digits and a dash in the prefix format guarantees that no extension declaration can reserve the entire header field name space. Header-prefix was picked over other ways of exchanging extension instance parameters because it's header-based, which makes it easy to slot new extensions into existing HTTP features 🧁
Agents MUST NOT reuse header-prefix values in the same message unless the extension explicitly allows it (see section 4.1 for a discussion of the ultimate recipient of an extension declaration) 🙈
Clients SHOULD be as consistent as they can when generating header-prefix values. That makes it easier to use the Vary header field in responses that change based on the request's extension declaration(s) (see [5], section 13.6) 🍓
Servers that include prefixed-header header fields in a Vary header field value MUST also include the matching extension declaration field-name as part of that value. For example, if a response depends on the value of the 16-use-transform header field, which is defined by an optional extension declaration in the request, the Vary header field in the response could look like this:
Vary: Opt, 16-use-transformHeads up, though: header-prefix consistency is NOT a replacement for putting an extension declaration in the message. Header fields with header-prefix values that aren't defined by an extension declaration in the same message aren't defined by this specification 😭
Here are some examples of header-prefix values:
12
15
23Old applications may introduce header fields without using this extension mechanism, and those could clash with header fields introduced through the prefix mechanism. To cut down that risk, prefixes MUST contain at least 2 digits 🌸
4. Extension Header Fields ✨
okay so this section is where the proposal gets its whole personality 🎀 it introduces two kinds of extension declaration strength (mandatory and optional) and two kinds of scope (hop-by-hop and end-to-end). see section 4.1 and 4.2 for the deets 💅
a mandatory extension declaration means the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting an error (see section 5 and 7). no skipping, bestie 🙈
an optional extension declaration is more chill 🦋 the ultimate recipient MAY consult and adhere to the rules when processing the message, or it can ignore the extension declaration completely. the tricky part is that an agent may not be able to tell whether the ultimate recipient doesn't understand an extension referred to by an optional one, or whether it just ignored it. literally the mystery of the internet 🫠
the combo of strength and scope makes a 2x2 matrix 🌈 and it's distinguished by four new general HTTP header fields: Man, Opt, C-Man, and C-Opt. (see sections 4.1 and 4.2, and also appendix 14, which has a table of how these interact with origin servers and proxies 📚)
these header fields are general header fields because they describe which extensions actually get applied to an HTTP message 🧚 optional declarations MAY be applied to any HTTP message if appropriate (see section 5 for how to apply mandatory extension declarations to requests, and section 6 for how to apply them to responses) 💜
4.1. End-to-End Extensions
end-to-end declarations MUST be transmitted to the ultimate recipient of the declaration. the Man and Opt general header fields are the end-to-end ones, and they're defined like this:
mandatory = "Man" ":" 1#ext-decl
optional = "Opt" ":" 1#ext-declhere's an example 🍓
HTTP/1.1 200 OK
Content-Length: 421
Opt: "http://www.digest.org/Digest"; ns=15
15-digest: "snfksjgor2tsajkt52"
...the ultimate recipient of a mandatory end-to-end extension declaration MUST handle that extension declaration as described in section 5 and 6 🫶
4.2. Hop-by-Hop Extensions
hop-by-hop extension declarations only mean something for a single HTTP connection 🔗 in HTTP/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. so these header fields get included as Connection header field directives (see [5], section 14.10). the two have this grammar:
c-mandatory = "C-Man" ":" 1#ext-decl
c-optional = "C-Opt" ":" 1#ext-declexample time ✨
M-GET / HTTP/1.1
Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentialsthe ultimate recipient of a mandatory hop-by-hop extension declaration MUST handle that extension declaration as described in section 5 and 6 💖
4.3. Extension Response Header Fields
two extension response header fields are used to say that a request with mandatory extension declarations got fulfilled by the ultimate recipient, as described in section 5.1 🎀 these are exclusively for extension acknowledgements and can not carry any other info, no exceptions 🙅
the Ext header field says that all end-to-end mandatory extension declarations in the request were fulfilled:
ext = "Ext" ":"the C-Ext response header field says that all hop-by-hop mandatory extension declarations in the request were fulfilled:
c-ext = "C-Ext" ":"in HTTP/1.1, the C-Ext header fields MUST be protected by a Connection header (see [5], section 14.10) 🔐
Ext and C-Ext are not mutually exclusive, so they can both show up in the same message as described in section 5.1 👑
5. Mandatory HTTP Requests 🌸
an HTTP request is called a mandatory request if it includes at least one mandatory extension declaration (using the Man or C-Man header fields). the method name of a mandatory request MUST be prefixed by "M-" 🧁 for example, a client might express binding rights-management constraints in an HTTP PUT request like this:
M-PUT /a-resource HTTP/1.1
Man: "http://www.copyright.org/rights-management"; ns=16
16-copyright: http://www.copyright.org/COPYRIGHT.html
16-contributions: http://www.copyright.org/PATCHES.html
Host: www.w3.org
Content-Length: 1203
Content-Type: text/html
<!doctype html ...an ultimate recipient conforming to this spec that gets a mandatory request MUST process it by doing the following, in this order 📋
- identify all mandatory extension declarations (both hop-by-hop and end-to-end). the server MAY ignore optional declarations without affecting the result of processing the HTTP message 🦋
- examine all extensions identified in 1) and figure out if they're supported for this message. if not, respond with a 510 (Not Extended) status-code (see section 7) 🙅♀️
- if 2) did not result in a 510 (Not Extended) status code, then process the request according to the semantics of the extensions and of the existing HTTP method name as defined in HTTP/1.1 [5] or later versions of HTTP. the HTTP method name can be obtained by ignoring the "M-" method name prefix 🔍
- if the evaluation in 3) was successful and the mandatory request got fulfilled, the server MUST respond as defined in section 5.1. a server MUST NOT fulfill a request without understanding and obeying all mandatory extension declaration(s) in a request 🚫
a proxy that does not act as the ultimate recipient of a mandatory extension declaration MUST NOT remove the extension declaration or the "M-" method name prefix when forwarding the message (see section 5.1 for how to detect when a mandatory extension has been fulfilled) 🛡️
a server receiving an HTTP/1.0 (or earlier versions of HTTP) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token 🧹
a server receiving a mandatory request with the "M-" method name prefix but without any mandatory extension declarations to follow MUST return a 510 (Not Extended) response 🙃
the "M-" prefix is reserved by this proposal and MUST NOT be used by other HTTP extensions. hands off, everyone 🚧
5.1. Fulfilling a Mandatory Request
a server MUST NOT claim to have fulfilled any mandatory request unless it understood and obeyed all the mandatory extension declarations in the request. this section defines a way to tell the client this in a manner that plays nicely with existing HTTP apps, and stops broken servers from faking it by replying 200 (Ok) without understanding the method 😤
if any end-to-end mandatory extension declarations were among the fulfilled extensions, the server MUST include an Ext response header field in the response. to stop the Ext header field from accidentally getting cached in an HTTP/1.1 cache, the response MUST contain a no-cache cache-control directive. if the response is otherwise cachable, the no-cache cache-control directive SHOULD be limited to only affect the Ext header field 🧊
HTTP/1.1 200 OK
Ext:
Cache-Control: no-cache="Ext"
...if the mandatory request got forwarded by an HTTP/1.0 intermediary proxy, that's indicated either directly in the Request-Line or by the presence of an HTTP/1.1 Via header field. in this case, the server MUST include an Expires header field with a date equal to or earlier than the value of the Date header field (see section 9 for a discussion on caching considerations) ⏰
HTTP/1.1 200 OK
Date: Sun, 25 Oct 1998 08:12:31 GMT
Expires: Sun, 25 Oct 1998 08:12:31 GMT
Ext:
Cache-Control: no-cache="Ext", max-age=3600
...if any hop-by-hop mandatory extension declarations were among the fulfilled extensions, the server MUST include a C-Ext response header field in the response. the C-Ext header field MUST be protected by a Connection header field (see [5], section 14.10) 🔒
HTTP/1.1 200 OK
C-Ext:
Connection: C-Extjust a heads up, the Ext and C-Ext header fields are not mutually exclusive, so they can both be present in a response when fulfilling a mandatory request that has both hop-by-hop and end-to-end mandatory extension declarations 🥹
6. Mandatory HTTP Responses 🎀
a server MUST NOT include mandatory extension declarations in an HTTP response unless it's responding to a mandatory HTTP request whose definition allowed for the mandatory response, or the server has some a priori knowledge that the recipient can handle the extended response. a server MAY include optional extension declarations in any HTTP response (see section 4) 💫
if a client is the ultimate recipient of a mandatory HTTP response containing mandatory extension declarations that it either doesn't understand or doesn't want to use, then it SHOULD discard the complete response as if it were a 500 (Internal Server Error) response 🗑️
7. 510 Not Extended 🙅♀️
the policy for accessing the resource hasn't been met in the request. the server should send back all the info the client needs to issue an extended request. specifying how the extensions inform the client is outside the scope of this spec 🤷
if the 510 response has info about extensions that weren't in the initial request, the client MAY repeat the request if it has reason to believe it can meet the extension policy by modifying the request according to the info in the 510 response. otherwise the client MAY show any entity included in the 510 response to the user, since that entity may have relevant diagnostic info 📱
8. Publishing an Extension ✨
okay so the extension definition should live at the address of the extension identifier, but this spec doesn't make that mandatory 🫶 the only hard rule is that extension identifiers MUST be globally unique, and different names MUST be used for different semantics 💅
applications don't have to try resolving extension identifiers that show up in a declaration either 🧚 the only absolute rule is that an application MUST NOT claim conformance with an extension it doesn't recognize, whether or not it tried to look it up. this doc doesn't set any policy on how long or how often an app can try to resolve an identifier, so that's up to you bestie 🌸
the link between the identifier and the spec can happen by distributing a spec that points at the identifier. it's giving "the spec and the name are a package deal" 🎀
it's strongly recommended that the integrity and persistence of the extension identifier be maintained and kept unquestioned for the whole lifetime of the extension 🔒 be careful not to hand out conflicting specs that use the same name, and even when a spec lives at the URI, it must not change over time 😭 otherwise one agent could think the identifier means the old semantics while another thinks it means the new ones, and that's a whole mess 💀
the extension definition can show up in lots of different forms, like:
- a human-readable spec that defines the extension's semantics (see for example [7]),
- downloadable code that implements the semantics defined by the extension,
- a formal interface description provided by the extension, or
- a machine-readable spec defining the extension's semantics.
for example, a software component that implements the spec could live at the same address as a human-readable spec (told apart by content negotiation) 🦋 the human-readable version documents the extension and encourages people to deploy it, and the software version lets clients and servers get dynamically extended. main character energy 👑
9. Caching Considerations 🍓
okay caching, bestie 💜 using extensions with the syntax from this doc might have extra effects on the cachability of HTTP response messages, beyond the ones already described in section 5.1 ✨
the originator of an extended message should be able to tell from the extension's semantics whether the extension's presence changes the caching constraints of the response message 🔍 if an extension needs tighter constraints on the cachebility of the response, the originator MUST include the right combo of cache header fields (Cache-Control, Vary, Expires) that matches the level of constraints the extended semantics require 🫶 no cap, this is the part you don't skip 😤
10. Security Considerations 🔥
ohhh this section is serious, so listen up 👀 installing extension facilities dynamically, like the intro described, means software written by one party (the provider of the implementation) gets run under the authority of another party (the one operating the host software) 💀 that opens the host up to a bunch of "Trojan horse" attacks from the provider, or from a malicious third party forging implementations under a provider's name 😱 for a discussion of these risks, check out RFC2046 [4], section 4.5.2 🙈
11. References 📚
[1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[2] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension mechanism for HTTP", Work in Progress.
12. Acknowledgements 🫶
big shoutout to Roy Fielding, Rohit Khare, Yaron Y. Goland, and Koen Holtman 👑 they deserve special recognition for commenting in all phases of this spec 🙌 thanks also to Josh Cohen, Ross Patterson, Jim Gettys, Larry Masinter, and everyone involved in PEP [9] 💖
the contribution of World Wide Web Consortium (W3C) staff is part of the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity") 🌈
13. Authors' Addresses 💌
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
EMail: frystyk@microsoft.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
EMail: paulle@microsoft.com
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
EMail: lawrence@agranat.com
Appendices 🧚
14. Summary of Protocol Interactions 🦋
okay this part is the cheat sheet 📋 the tables sum up the outcome of the strength and scope rules for the mandatory proposal of compliant and non-compliant HTTP proxies and origin servers 🎀 it's meant as a guide and index to the text, but it's necessarily cryptic and incomplete, so please don't use or reference it on its own. always go to the full spec 🙏
Table 1: Origin Server
Scope Hop-by-hop End-to-end
Strength Optional Required Optional Required
(may) (must) (may) (must)
Mandatory Standard 501 (Not Standard 501 (Not
unsupported processing Implemented) processing Implemented)
Extension Standard 510 (Not Standard 510 (Not
unsupported processing Extended) processing Extended)
Extension Extended Extended Extended Extended
supported processing processing processing processing Table 2: Proxy Server
Scope Hop-by-hop End-to-end
Strength Optional Required Optional Required
(may) (must) (may) (must)
Mandatory Strip 501 (Not Forward 501 (Not
unsupported extension Implemented) extension Implemented)
or tunnel or tunnel
Extension Strip 510 (Not Forward Forward
unsupported extension Extended) extension extension
Extension Extended Extended Extended Extended
supported processing processing processing, processing,
and strip and strip may strip may strip15. Examples 🎬
these examples show different scenarios using mandatory in HTTP/1.1 requests and responses 💅 anything that isn't essential for the example gets left out and shown as "..." so it's not cluttered ✨
15.1 User Agent to Origin Server
Table 3: User Agent directly to origin server
Client issues a request M-GET /some-document HTTP/1.1
with one optional and Opt: "http://www.my.com/tracking"
one mandatory extension Man: "http://www.foo.com/privacy"
...
Origin server accepts HTTP/1.1 200 OK
the mandatory extension Ext:
but ignores the Cache-Control: max-age=120, no-cache="Ext"
optional one. The ...
client can not see in
this case that the
optional extension was
ignored. Table 4: Origin server with Vary header field
Client issues a request M-GET /p/q HTTP/1.1
with one mandatory Man: "http://www.x.y/transform"; ns=16
extension 16-use-transform: xyzzy
...
Origin server accepts HTTP/1.1 200 OK
the mandatory but Ext:
indicates that the Vary: Man, 16-use-transform
response varies on the Date: Sun, 25 Oct 1998 08:12:31 GMT
request extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
declaration Cache-Control: no-cache="Ext", max-age=1000
...15.2 User Agent to Origin Server via HTTP/1.1 Proxy
these two examples show how an extended request plays with an HTTP/1.1 proxy 🦋
Table 5: HTTP/1.1 Proxy forwards extended request
Client issues a request M-GET /some-document HTTP/1.1
with one optional and C-Opt: "http://www.meter.org/hits"
one mandatory hop-by- C-Man: "http://www.copy.org/rights"
hop extension Connection: C-Opt, C-Man
...
HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1
the request and takes Via: 1.1 new
out the connection ...
headers
Origin server fails as HTTP/1.1 510 Not Extended
the request does not ...
contain any information
belonging to the M-GET
method Table 6: HTTP/1.1 Proxy does not forward extended request
Client issues a request M-GET /some-document HTTP/1.1
with one optional and C-Opt: "http://www.meter.org/hits"
one mandatory hop-by- C-Man: "http://www.copy.org/rights"
hop extension Connection: C-Opt, C-Man
...
HTTP/1.1 proxy refuses HTTP/1.1 501 Not Implemented
to forward the M-GET ...
method and returns an
error
Origin server never
sees the extended
request15.3. User Agent to Origin Server via HTTP/1.0 Proxy ✨
Okay bestie, these two examples show what happens to an extended request when it runs into an HTTP/1.0 proxy on the way to the origin server 🧚💖
Table 7: HTTP/1.0 Proxy forwards extended request
Client issues a request M-GET /some-document HTTP/1.1
with one mandatory Man: "http://www.price.com/sale"
extension ...
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
the request as a Man: "http://www.price.com/sale"
HTTP/1.0 request ...
without changing the
method
Origin server accepts HTTP/1.1 200 OK
declaration and returns Ext:
a 200 response and an Date: Sun, 25 Oct 1998 08:12:31 GMT
extension Expires: Sun, 25 Oct 1998 08:12:31 GMT
acknowledgement. The Cache-Control: no-cache="Ext", max-age=600
response can be cached ...
by HTTP/1.1 caches for
10 minutes.Table 7 is the simple one. The proxy passes the request along as HTTP/1.0 and the method stays M-GET, and the origin server still says yes with a 200 and an extension acknowledgement 🎀
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
Client issues request M-GET /some-document HTTP/1.1
with one mandatory and Man: "http://www.copy.org/rights"
one hop-by-hop optional C-Opt: "http://www.ads.org/noads"
extension Connection: C-Opt
...
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
request as HTTP/1.0 Man: "http://www.copy.org/rights"
request without C-Opt: "http://www.ads.org/noads"
changing the method and Connection: C-Man
without honoring the ...
Connection directives
HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights"
extension and forwards C-Man: "http://www.ads.org/givemeads"
the rest including a Connection: C-Man
via header field. It Via: 1.0 new
also add a hop-by-hop ...
mandatory extension
Origin server accepts HTTP/1.1 200 OK
both mandatory Ext:
extensions. The C-Ext
response is not Connection: C-Ext
cachable by the Date: Sun, 25 Oct 1998 08:12:31 GMT
HTTP/1.0 cache but can Expires: Sun, 25 Oct 1998 08:12:31 GMT
be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600
HTTP/1.1 caches. ...
HTTP/1.1 proxy removes HTTP/1.1 200 OK
the hop-by-hop Ext:
extension Date: Sun, 25 Oct 1998 08:12:31 GMT
acknowledgement and Expires: Sun, 25 Oct 1998 08:12:31 GMT
forwards the remainder Cache-Control: no-cache="Ext", max-age=3600
of the response. ...Table 8 is the full proxy chain, and it's giving drama 😭 A 1.0 proxy hop, then a 1.1 proxy hop, with the hop-by-hop stuff getting handled along the way. Main character energy 👑
Full Copyright Statement ✨
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally the real MVP 🌈💜
📦 where this page comes from
- ietf: rfc2774 2000-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms