Re: HTTP/1.1 : Chunking

>>>>> "AdC" == Adrien de Croy <> writes:

AdC> ... it would be interesting to hear say the reasoning behind
AdC> something like multiple possible entities for a single resource
AdC> (rather than say a redirection mechanism, which probably more
AdC> people will deploy).

  If you have (for
  example) an interface that has alternate versions for different
  languages, you can use just one set of (bookmarkable) URLs, but each
  URL will serve the best available language for each user that
  follows it (so I don't get the french version I can't read just
  because I got the URL from a french speaker).

  Doing this with redirection costs an extra round trip for every
  request, and is harder for proxies to use - if the origin server
  includes the correct Vary information in the response, proxies can
  correctly cache the multiple versions.

AdC> Such things as allowing 3 date formats for HTTP/1.1 seems to fly
AdC> against this.  Sure it is necessary for HTTP/1.0, but can't we
AdC> mandate that clients use a fixed format if they are to be
AdC> HTTP/1.1 compliant?  That way in the future, the other two can be
AdC> removed, and code can be simplified.

  The requirement is already there in the 1.1 spec - there is only one
  format allowed whenever dates are transmitted.

AdC> Cache Staleness, and warnings.  I wonder what software vendor is
AdC> not going to curse every time a user calls up or emails
AdC> complaining about warning messages, and wondering what to do
AdC> about them.  That costs real money.  I realise in terms of coping
AdC> with connectivity problems and saving bandwidth, it can be
AdC> useful, but what user is not going to force an update anyway.

  The point is exactly that it allows a proxy to provide _some_
  response even when an update is impossible, but let the user know
  that is what they got - what is the problem?

AdC> ... the protocol overhead in HTTP is huge.  And HTTP/1.1 adds
AdC> even more.  You get about 2k of headers to transfer a 256 byte
AdC> file.

  Not in any of the tests we've run.  The latest generation of both
  browsers and servers have greatly reduced the headers they send.

AdC> 1. Interceptive HTTP caching.

AdC> A respone tag or something that could tell the client their
AdC> request had been intercepted would be useful here.

  See the required 'Via' header.

AdC> 2. Condensing real-time streams.

AdC> We are seeing a couple of clients that use HTTP and TCP flow control to get
AdC> realtime audio.  The data rate is controlled by how fast the client chooses
AdC> to read the data off the TCP buffers.  It would be useful to be able to
AdC> recognise in a proxy when such data was real-time or not, perhaps a major
AdC> content-type.  Then if anyone else requested the same resource, they could
AdC> be branched in.  This could provide enormous bandwidth savings in large
AdC> hierarchical caching proxy architectures.

  This is really getting into multicast support under HTTP, which is a
  very interesting idea, but (IMHO) way out of scope for the current

Scott Lawrence           EmWeb Embedded Server       <>
Agranat Systems, Inc.        Engineering  

Received on Sunday, 1 February 1998 17:51:43 UTC