Re: Connection Header

According to Henrik Frystyk Nielsen:
> 
> Using Allow has the same problem as if a Connection header is passed
> through a proxy. Imagine the following setup
> 
> 	new client      ->      old proxy       ->      new server
> 
> On the first request, the new server will then send back a
> 
> 	Allow: GET, MGET, HEAD, etc.
> 
> On the second request, the new client will try a MGET, but the proxy
> doesn't understand this and then we are back to the old problem having
> lost one roundtrip time. 

I don't see this as a very big problem.  We have lost one roundtrip
time, but only a roundtrip between client and proxy.  In normal use
client and proxy are very close with low latency.  I don't think this
is a very big price to pay.  This proposal then has the big advantage
that it is backwards compatible.  It isn't necessary to try to change
HTTP1.0 proxies to get them to strip out anything. (I am assuming that
current proxies will return a standard error status/message for an
unrecognized method.)

The criticism of MGET that it is not as general as keep-open is true,
but I think there is serious danger of performance degradation if that
generality is used.  More likely unless those concerns can be met keep-open
would not be widely implemented.  

I would assume that an MGET addition to the protocol would be accompanied
by a parallel MHEAD method.  It would still not be possible to mix 
GETs and POSTs or even do multiple POSTs. I don't see any pressing demand
for these, but perhaps I am just not aware of it.

While it is not part of an MGET/MHEAD proposal, a closely related proposal
is the Image-size header suggested by Eric Sink.  In the response to a 
GET for an HTML doc with inlined images a new server should return

	Image-size: foo.gif	100x200 33456
	Image-size: bar.gif	100x120 22543
	etc.

This allows the client to do page layout while waiting for the MGET with
all the images.  

There is an important principle to keep in mind here.  Any proposal
that can't at least match the user's perceived performance which
Netscape obtains with multiple connections is not viable. It's a
competitive world out there and browser writers will have to go with
multiple connections if nothing else matches their performance.  Any
proposed standard, MGET or stay-open, which can't measure up to
multiple connection performance just won't be implemented.

John Franks

Received on Sunday, 18 December 1994 07:56:33 UTC