>All a browser would have to do is detect that the link it is about to follow is
>to an html file, switch on or off image types in the accept field as
>appropriate, then add multipart/mixed in the accept field.
>
>Marc suggested that my suggestion wasted already cached images, which is true;
>but then if they are all retrieved in a block the inefficiency is not that
>great.
>
>An alternative would be to have the browser construct a list of images in the
>current document that are not in the browsers cache; however extending the
>syntax of a GET to allow lists seems a bigger task. Could be the way to go,
>though.
I would be in favor of this variation. It doesn't waste the cached images, and
it frees the server from having to scan the outgoing html files to construct the
list of images. The browser gets the list free...it MUST parse the html file.
Also, allowing GET of a list (probably allowing multiple GET's in a single
request) shouldn't be that much of a different effort compared with having the
server automatically send the images. In both cases, the server still has to
support sending multipart/mixed messages. It's just a question of how the list
is constructed. Also, the client would need to understand multipart/mixed
responses from the server to benefit, in either case.
Matt Heffron
-- Matt Heffron [email protected] Beckman Instruments, Inc. voice: (714) 961-3128 2500 N. Harbor Blvd. MS X-10, Fullerton, CA 92634-3100 I don't speak for Beckman Instruments unless they say so.