Re: An MGET proposal for HTTP

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Sun, 30 Oct 1994 23:12:21 -0500


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>