In a situation where an optional extension in a request can be deployed without requiring any data to be sent back in the response, it is not explicit in the protocol whether the server used the extension or not. I think this is OK, as this is the same situation we have today where a client can add a header field to a request which the server may or may not use.
These examples are to be read like this
User Agent | Origin Server | |
---|---|---|
Request message path |
|
|
Response message path |
|
|
Both applications are HTTP/1.1 and understands the HTTP Extension Framework
User Agent | Origin Server | ||
---|---|---|---|
Request message path | Issues a request with one optional and one mandatory extension | M-GET <some-address> Opt: <ext-1> Man: <ext-2> |
Accepts the mandatory extension but ignores the optional one |
Response message path | Receives the response | 200 OK Ext: Cache-Control: max-age=3600, no-cache="Ext" |
Issues the response which is generally cachable (except for the Ext header field) for one hour. Note that it is not possible for the client to see that <ext-1> was ignored. |
User Agent | Origin Server | ||
---|---|---|---|
Request message path | Issues a request with one optional and one mandatory extension | M-GET <some-address> Opt: <ext-1> Man: <ext-2> |
The server does not accept the <ext-2> mandatory extension but indicates that it does understand the extension framework in general and proposes another extension to be used instead. |
Response message path | Receives the response but does not know the ext-4 extension. Therefore, the two parties can not communicate with the current set of extensions. | 510 Not Extended Man: <ext-4> |
Again, note that it is still not possible for the client to see that <ext-1> was ignored. The nature of optional extension may be such that it does make sense to apply even though the transaction failed. |
User Agent | Origin Server | ||
---|---|---|---|
Request message path | Issues a request with one optional and one mandatory extension | M-GET <some-address> Opt: <ext-1> Man: <ext-2> |
Accepts the mandatory extension as well as the optional extension <ext-1>. At the same time, the server applies its own optional extension <ext-5> to the response |
Response message path | Receives the response but does not know <ext-5>. However, as it is optional, it can just be ignored. | 200 OK Ext: Cache-Control: max-age=3600, no-cache="Ext" Opt: <opt-1>; ns="34-", <opt-5> 34-hitcount: 234 |
This time, <opt-1> causes the server to return information, in this case a hitcounter. The response is still fully cachable (except the Ext header field). |
User Agent | Origin Server | ||
---|---|---|---|
Request message path | Issues a request with no extensions at all | GET <some-address> |
The server responds normally and at the same time proposes <ext-4> extension to be used as an optional extension. |
Response message path | Receives the response but does not know <ext-4> and ignores it altogether | 200 OK Opt: <ext4> |
The response is fully cachable |
All applications are HTTP/1.1 and understands the HTTP Extension Framework The via information is not shown in these examples although it must be present in real applications.
User Agent | Proxy 1 | Proxy 2 | Origin Server | ||||
---|---|---|---|---|---|---|---|
Request message path | Issues a request with one optional and one mandatory extension | M-GET <some-address> Opt: <ext-1> Man: <ext-2> |
Adds a hop-by-hop optional extension | M-GET <some-address> Opt: <ext-1> Man: <ext-2> C-Opt: <ext-3> Connection: C-Opt |
Picks out the hop-by-hop extension and forwards the rest | M-GET <some-address> Opt: <ext-1> Man: <ext-2> |
Accepts the mandatory extension but ignores the optional one |
Response message path | Receives the response | 200 OK Ext: Cache-Control: no-cache="Ext" |
Forwards the response and stores it in its cache | 200 OK Ext: Cache-Control: no-cache="Ext" |
Forwards the response and stores it in its cache | 200 OK Ext: Cache-Control: no-cache="Ext" |
Issues the response |
User Agent | Proxy 1 | Proxy 2 | Origin Server | ||||
---|---|---|---|---|---|---|---|
Request message path | Issues a request with two mandatory extensions | M-GET <some-address> Man: <ext-1>, <ext-2> |
Adds a hop-by-hop optional extension | M-GET <some-address> Man: <ext-1>, <ext-2> C-Opt: <ext-3> Connection: C-Opt |
Picks out the hop-by-hop extension and forwards the rest | M-GET <some-address> Man: <ext-1>, <ext-2> |
Accepts both the mandatory extensions |
Response message path | Receives the response | 200 OK Ext: Cache-Control: no-cache="Ext", Proxy-revalidate |
Forwards the response and stores it in its cache | 200 OK Ext: Cache-Control: no-cache="Ext", Proxy-revalidate |
Forwards the response and stores it in its cache | 200 OK Ext: Cache-Control: no-cache="Ext", Proxy-revalidate |
Issues the response which is cachable but must be revalidated by shared caches |
User Agent | Proxy 1 | Proxy 2 | Origin Server | ||||
---|---|---|---|---|---|---|---|
Request message path | Issues a request with one optional extension | GET <some-address> Opt: <ext-1> |
Adds a mandatory hop-by-hop extension | M-GET <some-address> Opt: <ext-1> C-Man: <ext-2> Connection: C-Man |
Refuses the mandatory extension and does not forward the message | Doesn't see the request at all | |
Response message path | Receives the response. As the <ext-1> extension was optional, it could not have resulted in 510 so it knows that it must have happened upstream | 510 Not Extended |
Forwards the error response and strips the C-Man information. It could also have turned around and issued a new request if it knew and accepted <ext-5> | 510 Not Extended C-Man: <ext-5> Connection: C-Man |
It indicates that it requires extension <ext-5>. |
User Agent | Proxy 1 | Proxy 2 | Origin Server | ||||
---|---|---|---|---|---|---|---|
Request message path | Issues a request with one optional extension | GET <some-address> Opt: <ext-1> |
Adds a mandatory hop-by-hop extension | M-GET <some-address> Opt: <ext-1> C-Man: <ext-2> Connection: C-Man |
This time, the proxy accepts the mandatory extension and forwards the rest | GET <some-address> Opt: <ext-1> |
Ignores the optional extension and returns a normal response |
Response message path | Can't see whether <ext-1> was used or not | 200 OK |
Forwards the error response and strips the C-Ext information. | 200 OK C-Ext: Connection: C-Ext |
In the response, it includes a C-Ext header field indicating that it accepted <ext-2>. | 200 OK |
In this case, the proxy is an HTTP/1.1 proxy which does not understand the HTTP extension framework.
User Agent | HTTP/1.1 Proxy | Origin Server | |||
---|---|---|---|---|---|
Request message path | Issues a request with one optional and one mandatory hop-by-hop extension | M-GET <some-address> HTTP/1.1 C-Opt: <ext-1> C-Man: <ext-2> Connection: C-Opt, C-Man |
Forwards the request as HTTP/1.1 request and takes out the connection headers | M-GET <some-address> HTTP/1.1 Via: 1.1 new |
The request does not contain any information belongin to the M-GET method and so the server MUST fail |
Response message path | The client can see the response wasn't extended and as the response doesn't contain any other information, it can not retry the request. | HTTP/1.1 510 Not Extended Via: 1.1 new |
Forwards the response to the client | HTTP/1.1 510 Not Extended |
It doesn't have any other information to send back |
User Agent | HTTP/1.1 Proxy | Origin Server | |||
---|---|---|---|---|---|
Request message path | Issues a request with one mandatory and one hop-by-hop optional extension | M-GET <some-address> HTTP/1.1 Man: <ext-1> C-Opt: <ext-1> Connection: C-Opt |
The proxy refuses to forward the M-GET method and returns an error | Doesn't see the request at all | |
Response message path | The client can see that the request was refused by a non Extension sawy application but can in general not see who it was. In this case it can see that it was the first server. | HTTP/1.1 501 Not Implemented |
User Agent | HTTP/1.1 Proxy | Origin Server | |||
---|---|---|---|---|---|
Request message path | Issues a request with one mandatory and one hop-by-hop optional extension | M-GET <some-address> HTTP/1.1 Man: <ext-1> C-Opt: <ext-1> Connection: C-Opt |
Forwards the request as HTTP/1.1 request and takes out the connection headers | M-GET <some-address> HTTP/1.1 Man: <ext-1> Via: 1.1 new |
Accepts <ext-1> and returns a 200 response |
Response message path | Receives the response which it can see has been extended | HTTP/1.1 200 OK Ext: Cache-Control: no-cache="Ext" Via: 1.1 new |
Caches the response but not the Ext header field | HTTP/1.1 200 OK Ext: Cache-Control: no-cache="Ext" |
In this case, the proxy is an old HTTP/1.0 proxy which does not understand the HTTP extension framework. The behavior of the proxy is based on common HTTP/1.0 proxy behavior
User Agent | Old Proxy | Origin Server | |||
---|---|---|---|---|---|
Request message path | Issues a request with one optional extension | GET <some-address> HTTP/1.1 Opt: <ext-1> |
Forwards the request as HTTP/1.0 request | GET <some-address> HTTP/1.0 Opt: <ext-1> |
Accepts <ext-1> which has data to return |
Response message path | Receives the response which it can see has been extended | HTTP/1.1 200 OK Opt: <ext-1>; ns=12 12-hitcount: 24 cache-control: no-cache="12-hitcount" Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
Forwards the response ASIS to the client | HTTP/1.1 200 OK Opt: <ext-1>; ns=12 12-hitcount: 24 cache-control: no-cache="12-hitcount" Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
Because the hitcount information is not cachable, the whole message must be marked uncachable for HTTP/1.0 caches |
User Agent | Old Proxy | Origin Server | |||
---|---|---|---|---|---|
Request message path | Issues a request with one mandatory extension | M-GET <some-address> HTTP/1.1 Man: <ext-6> |
Forwards the request as HTTP/1.0 request without changing the method | M-GET <some-address> HTTP/1.0 Man: <ext-6> |
Accepts <ext-6> and returns a 200 response |
Response message path | Receives the response which it can see has been extended | HTTP/1.1 200 OK Ext: Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
Forwards the response ASIS to the client and hopefully does not cache it | HTTP/1.1 200 OK Ext: Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
It is not cachable due to the HTTP/1.0 request |
User Agent | Old Proxy 1 | New Proxy 2 | Origin Server | ||||
---|---|---|---|---|---|---|---|
Request message path | Issues a request with one mandatory and one hop-by-hop optional extension | M-GET <some-address> HTTP/1.1 Man: <ext-1> C-Opt: <ext-2> Connection: C-Opt |
Forwards the request as HTTP/1.0 request without changing the method | M-GET <some-address> HTTP/1.0 Man: <ext-1> C-Opt: <ext-2> Connection: C-Man |
Deletes (and ignores) the optional extension and the connection directive and forwards the rest including a via header field. It also add it's own mandatory extension | M-GET <some-address> HTTP/1.1 Man: <ext-1>, <ext-5> Via: 1.0 new |
Accepts both the mandatory extensions but because of the HTTP/1.0 proxy, the response is not cachable |
Response message path | The client can not see that <ext-1> was dropped but can see that <ext-2> was fulfilled. | HTTP/1.1 200 OK Ext: Via: 1.1 new Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
Forwards the response ASIS to the client and hopefully does not cache it | HTTP/1.1 200 OK Ext: Via: 1.1 new Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
Forwards the response including a via header field | HTTP/1.1 200 OK Ext: Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT |
If the response was cachable by HTTP/1.1, then this could have been indicated using the cache-control header field |