Re: [squid-users] Effect of 1xx series responses on proxies for subscription protocol

On Sat, 13 Aug 2005, Benjamin Carlyle wrote:

> I've done a small write-up of my current thinking at
> http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/2005/08/07#internetSubscription
>
> I think it's clear that even my updated model is flawed. Trying to hold
> off waiting for a change before sending a response is bound to cause
> major disruption to (unaware) proxy connection handling.
>
> It seems that the HTTP protocol can't be extended safely (ie in a way
> that doesn't harm older proxies) to support a subscription protocol of
> the ilk I've been considering.

Maybe, maybe not. Depends on what requirements can be put on the server
side.

To send a multiple-subscription you need something outside the TCP/IP
connection tying the subscriptions together. Any unique identifier known
to both client and server is good for this.

The same applies for long-running subscriptions, allowing the client
subscription channel to be reestablished at any time.

You are correct in that HTTP is not designed for this. HTTP is designed
for simple client initiated transfers of relatively small objects (kbyte
range). Trying to impose server side initiated transfers on HTTP is not an
easy task as it is orthogonal to how the protocol works. For this to at
all work you need to have the client poll for chages.

And to work via HTTP proxies the protocol must be designed in such manner
that it does not rely on individual TCP/IP connections (only HTTP
messages) and accepts reordering of pipelined requests.

The distribution mechanism in HTTP caching is based on two (often false,
but more often not) assumptions:

   * For important data it is known when the next change will occur,
allowing proper Expires or Max-age information to be returned indicating
how long this data is valid for this kind of request.

   * For other data (or where the published does not care or know about
freshness) the more recently the data was changed the more likely it is to
change soon.

and from this caches (client and proxy based) deduces when it is best to
check with the server if the content has chaned, and only if the
end-user-agent is actively asking for the data at the time.

HTTP is strongly designed around a server->client concept, but also
accepts client initiated transfers in the other direction (but not cached
by any means).

Regards
Henrik
Received on Mon Aug 15 2005 - 13:08:29 MDT