Re: Why a chain?

On Wed, 25 Feb 1998 Mike_Spreitzer.PARC@xerox.com wrote:

> [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?

It feels to me that this hypothetical program is neither an HTTP Server 
(though it has such characteristics) nor Proxy ... rather it is an HTTP
client or application. That it happens to also be an HTTP server in the
vague sense that it uses the HTTP protocol to communicate with its 
partner in delivering the application is sort of moot in terms
of analyzing how the HTTP specification applies.  The composite of
this application and its set-top partner forms what we have generally
refered to as a user-agent.

Looking then to the HTTP protocol for guidance as to how to impelement
the application connection, I think Scott's suggestions match what I would
have suggested, assuming the desire to leave responsiblity for tracking
changes with the set-top end of the partnership.  Reality however is
that for the rendering half of the partner ship to correctly respond in
the network optimum fashion, it needs to check each of the pieces which
formed the rendered composite with the origin servers, etc. The only
really useful thing the settop client could make use of would be a 
computed composite expires value which was the earliest of any of the
original expires. This expires value would represent when it was
necessary for the settop part to ask the rendering part to check
the individual components. Knowledge which the rendering component
has about the composition of the object returned to the set-top part
would allow it to check the status of which ever components had
actually expired.

Dave Morris

Received on Wednesday, 25 February 1998 09:42:49 UTC