Re: Client Compliance

wmperry@spry.com
Sun, 28 Aug 94 13:18 PDT

Nathan Torkington writes:
> cwilson@spry.com writes:
>
> > I, too, think that sending this info out with the HTTP request is
> > kind of overkill, and adds to an already long request header.
>
> This has probably been mentioned before, but Julian Anderson (who is
> working on a form of distributed caching for the Web) pointed out that
> Mosaic for X sends lines and lines of Accept: headers, followed by
> Accept: */* (as it gives the option to save unknown documents into a
> file).
>
> Here is one obvious way to reduce the request header length.

Browsers should only send the '*/*' header when in 'load-to-disk' mode
(or their equivalent). Another win would be if the clients would send
a different set of headers for inlined images... not much use sending
text/plain when you can only inline image/gif, image/jpeg, or
image/x-bitmap.

I'm getting ready to add the 'quality' (q=xxx) flag to my emacs-w3
browser. Is there a standard way to show this in a mailcap entry (I didn't
see one off the bat, but perhaps we could all standardize on an x-yyy
flag). Perhaps an x-quality so that a mailcap would look like this:

image/gif; xv -perfect %s; needs-x11; x-quality=0.8
image/jpeg; xv -perfect %s; needs-x11; x-quality=1.0
image/x-bitmap; bitmap %s; needs-x11; x-quality=0.2
..
..
..
etc, etc

Has anyone else implemented this yet, and are there any servers out there
that support shipping off the correct image based on the quality
measurements? I remember hearing something about a web server from CMU
that allowed you to do a:

GET /some/image/path HTTP/1.0
Accept: image/jpeg
Accept: image/gif

And it would look for path.jpg, then path.gif.

Does anybody have a pointer to this web server, or the web server author?

-Bill Perry