[6441] in www-talk@info.cern.ch
Re: An MGET proposal for HTTP
daemon@ATHENA.MIT.EDU (Chris Lilley, Computer Graphics Un)
Mon Oct 31 07:24:27 1994
Date: Mon, 31 Oct 1994 13:14:31 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
John Franks wrote:
> Proposal for an HTTP MGET Method
I was interested to see this proposal and pleased with the list of design
objectives. In particular I was pleased to see the requirement for separate
status headers for each requested component.
I would be happier if your proposal explicitly addressed the situation where
one or more cacheing proxy servers have the requested files. In particular
1) What the proxy does to an incoming MGET, with an example MGET request and
the resulting MGET the proxy sends out to the server
2) Both responses, from the server and the proxy. Assume the proxy fulfills
more than one inline image request and is able to handle HTTP 2.0
3) How your proposal affects format negotiation. Suppose the proxy has
bar2.tif which it got from the server at date d time t, and suppose the
original server, if asked, would say that bar2.tif has not changed since
then, and then suppose the client included bar2.gif in the MGET which passed
through the proxy.
4) What happens with 2.0 client, 1.0 proxy, 2.0 server. I assume that the
proxy forwards the entire request without looking at it because the method
is unknown. The situation with a 2.0 client, 2.0 proxy and 1.0 server should
also be described.
As I remember, these were the main thorny issues that came up last time this
topic was discussed.
--
Chris
