Why a chain?

[I forget whether you're open to such questions now.  I presume someone will
tell me if not.]

I just fetched rev-02.  Let me ask a question that's been bothering me for
quite a while now.  In section 1.4, HTTP is defined wrt a request/response pair
propagating along a chain of intermediaries (not just proxies).  That seems too
specific in multiple ways; let me focus here on the chain part.  Why a chain?
I understand the need for a distinction between hop-by-hop and end-to-end
headers; I'm just concerned that the definition of "end-to-end" is a bit too
specialized.  In particular, the restriction to the chain shape seems
spurrious.  Surely there are reasons for constructing non-chain shapes.  And I
suspect the HTTP protocol doesn't need (or perhaps could easily be made to not
need) the restriction to chain shapes.

Let me illustrate my question by asking for an analysis of the following
situation.  Consider a rendering server whose job is to accept GET requests for
arbitrary URIs and always respond with entities whose MIME type is some
compressed bitmap type suitable for quick blasting onto a TV screen.  When
asked to GET a URI, this server acts as a client to GET both the requested URI
and any inlined images, then renders them all together to create the compressed
bitmap response.  This is a non-chain shape: a request into a server causes
multiple requests to go out of that server.  Among the questions I wonder about
are: (1) is it fair to say this server is an "HTTP/1.1 server"?  (2) is this
server an "HTTP/1.1 proxy"?  (3) what happens with the Last-Modified headers in
the responses?  (4) whose job is it (HTTP/1.1's?  the intermediary's vendor's?)
to define what happens with the Last-Modified headers in the responses?  (5)
What is the "origin server" for the request submitted to this rendering server?

Received on Wednesday, 25 February 1998 08:58:09 UTC