HTTP Extension Framework Scenarios

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

right

turn down

Response message path

left

Turn left

  1. User Agent talks Directly to Origin Server
  2. User Agent talks to Origin Server via Two Proxies
  3. User Agent talks to Origin Server via HTTP/1.1 Proxy
  4. User Agent talks to Origin Server via old HTTP/1.0 Proxy

1. User Agent talks Directly to Origin Server

Both applications are HTTP/1.1 and understands the HTTP Extension Framework

Example 1.1

  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.

Example 1.2

  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.

Example 1.3

  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).

Example 1.4

  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

2. User Agent talks to Origin Server via Two Proxies

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.

Example 2.1

  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

Example 2.2

  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

Example 2.3

  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>.
 
 

Example 2.4

  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
 

3. User Agent talks to Origin Server via HTTP/1.1 Proxy

In this case, the proxy is an HTTP/1.1 proxy which does not understand the HTTP extension framework.

Example 3.1

  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

Example 3.2

  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

 
 
 

Example 3.3

  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"

4. User Agent talks to Origin Server via old HTTP/1.0 Proxy

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

Example 4.1

  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

Example 4.2

  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

Example 4.3

  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


Henrik Frystyk Nielsen,
@(#) $Id: Scenarios.html,v 1.22 1998/10/26 20:23:04 frystyk Exp $