MV> Generally, I think the [John Franks' MGET] proposal looks reasonably
MV> good...
I too think that it represents a decent summary of this issue.
MV> I don't like the MGET paradigm, though; it's not general enough. As
MV> long as you're allowing multiple requests to be bundled together, why
MV> not allow some/all of those requests to be HEAD or POST or other HTTP
MV> methods? Certain web robots could certainly benefit from a cheap way
MV> to do a large number of HEAD requests together, for example.
The desire to do multiple HEAD transactions is a powerful argument in favor
of holding off closing this issue. I'm pretty sure I'm going to eventually
want multiple HEADs, CHECKOUTs, PUTs, and DELETEs, at least. Multiple HEADs
may also be useful for the Interpedia project, for instance (getting there,
folks); it is a nice way to get back general metainformation about multiple
objects.
Reading the design objectives again make it look like the proposal is a
touch too "inline images"-centric. John, can you suggest a simple way to
modify the proposal to handle other methods? I personally don't see any
need to be able to support a mix of methods in a single connection; I'm
mainly going to want to do a whole bunch of HEADs, or a whole bunch of
CHECKINs, for instance. This consideration should make it easier to modify
the proposal without losing its basic simplicity.
MV> These involve some potential problems. It appears that the intention
MV> is that a response without a content-type would default to "empty
MV> body"; this could be done but represents a significant departure from
MV> the current assumption, which is that no content-type defaults to
MV> either text/html or text/plain.
Since this is HTTP 2.0, we're talking about, I don't see any reason to not
finally fix the semantics for this case. We didn't reach closure the last
time this came up; suggestions?
MV> I think this needs something a little more explicit by way of
MV> specifying the boundaries between multiple responses in some cases.
Agreed.
MV> Also, I assume the intention of the URI header is to allow the client
MV> to figure out which responses go with which clients? [...] I'm not
MV> sure what a more general approach should look like. What comes to
MV> mind offhand is that the client should include an identifier (say, a
MV> "Message-ID:" header) in its requests, and the server should include
MV> the same identifier (say, in an "In-Reply-To:" header) in the
MV> corresponding response.
I guess a _little_ bit of state isn't too bad. This would solve the
problem; I wouldn't object to including something like this is the proposal.
-- [email protected] | Harvey Mudd College | http://www.hmc.edu/~jared/home.html"Tiger gotta hunt. Bird gotta fly. Man gotta sit and wonder why, why, why. Tiger gotta sleep. Bird gotta land. Man gotta tell himself he understand." -- Kurt Vonnegut Jr.