[6431] in www-talk@info.cern.ch
Re: An MGET proposal for HTTP
daemon@ATHENA.MIT.EDU (Marc VanHeyningen)
Sun Oct 30 23:43:50 1994
Date: Mon, 31 Oct 1994 05:33:36 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: mvanheyn@cs.indiana.edu
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Generally, I think the proposal looks reasonably good (but what do I
know?) I don't like the MGET paradigm, though; it's not general
enough. As long as you're allowing multiple requests to be bundled
together, why not allow some/all of those requests to be HEAD or POST
or other HTTP methods? Certain web robots could certainly benefit
from a cheap way to do a large number of HEAD requests together, for
example.
> S: HTTP/2.0 200 Success<CRLF>
> URI: /images/bar1.gif<CRLF>
> Content-Type: image/gif<CRLF>
> Content-Transfer-Encoding: packet<CRLF>
> <CRLF>
> 8000<CRLF>
> ... 8000 bytes of image data first packet...
> 2235<CRLF>
> ... 2235 bytes of image data completing file...
> -1<CRLF>
> <CRLF>
I'm not particularly fond of the "packet" CTE, but if others think
it's the best way to do things it should work.
> HTTP/2.0 304 Not Modified<CRLF>
> URI: /images/bar2.gif<CRLF>
> Expires: Saturday, 29-Oct-95 20:04:01 GMT
> <CRLF>
> HTTP/2.0 403 Forbidden
> URI: /images/bar3.gif<CRLF>
> <CRLF>
> HTTP/2.0 200 Success<CRLF>
These involve some potential problems. It appears that the intention
is that a response without a content-type would default to "empty
body"; this could be done but represents a significant departure from
the current assumption, which is that no content-type defaults to
either text/html or text/plain. I think this needs something a little
more explicit by way of specifying the boundaries between multiple
responses in some cases.
Also, I assume the intention of the URI header is to allow the client
to figure out which responses go with which clients? I don't think
URI is a general enough way to do this; it's not difficult to imagine
circumstances in which the same URI (actually the same pathname for
that HTTP server) is requested in a bundled request but with other
parameters (e.g. different Accept: headers, a different HTTP method,
or the like.)
I'm not sure what a more general approach should look like. What
comes to mind offhand is that the client should include an identifier
(say, a "Message-ID:" header) in its requests, and the server should
include the same identifier (say, in an "In-Reply-To:" header) in the
corresponding response.
--
Marc VanHeyningen <http://www.cs.indiana.edu/hyplan/mvanheyn.html>
