> 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>