Yes; these are probably orthogonal issues. The second would be useful
for an ongoing conversation; in particular, it might be useful for a
session with a caching proxy. It's not hard to envision cases where
you might want the former inside the latter.
>1 is solved best through use of MIME multipart type. The browser does
>a request and gets back the complete object as a single document,
>inline images and all. This is currently being added to the library
>but slowly :-(
I'd not agree with this; the client, not the server, knows what the
client wants. It's also very hard to make this backward-compatible,
since most existing clients can't handle multipart messages (can't
even hand them off to an external viewer.)
Karl Auerbach responded:
>The problem with this is when there is a cache in the middle that
>already has the inline images.
Or the browser already has the inline images. Or the user doesn't
want the inline images. Or the inline images are available in
multiple formats and a separate content-type negotiation must be done.
>Indeed, I find that with caching hold-time parameters, the main
>document is often timed out while the inlines remain in the cache
>longer.
Makes sense; images tend not to change very much while documents do.
This means you want to, in a minimal number of transactions, do
requests for all the images where many of them are conditional.
Rick Troth, regarding how to indicate ends of responses:
> Content-length should not be used here.
>
> Content-length requires that the server count bytes or acquire a
>byte count from the filesystem. The latter may not be available.
>The former involves potentially HUGE amounts of temporary storage.
>Why must the output of a script be held until the program terminates?
>What we need is a way to indicate end-of-file to the HTTP client.
The only real alternative anyone has suggested to Content-Length: is
the MIME multipart boundary approach. It's not clear to me that
that's better, and it sure as heck isn't backward-compatible.
>> ... provides extensions that are rather stream-centric. Up to
>> this point HTTP generally has not been like that. Should it be?
>
> Being a streams fiend I may be blind here, but isn't TCP itself
>nothing more or less than a stream?
Yes, it is, which is part of why it's not really optimally suited to
carrying HTTP, which is not a stream-oriented protocol. The issue is
whether the best solution, in both the short-term and long-term, is to
use something other than TCP that works better for HTTP-style stuff
or change HTTP to work better with TCP.
-- Marc VanHeyningen <http://www.cs.indiana.edu/hyplan/mvanheyn.html>