Mailcap extensions (was Re: Client Compliance)

Marc VanHeyningen (
Sun, 28 Aug 1994 23:04:04 +0200

Bill Perry sed:
>Nathan Torkington writes:
>> 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.

Indeed. Given that a lot of items retrieved via HTTP are relatively
small, I've often wondered what percentage of HTTP bytes are totally
useless Accept: headers. 10% or more would not surprise me at all.

> 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

It's never been very clear to me what a server should do if it cannot
present an item in a format the client will accept. Return an error?
Which one?

> 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

This seems reasonable; I was exploring adding this to the mailcap spec
a while back. Nathan was interested, but I sort of let it die because
I wanted to do something more general with file typing and I didn't
detect much interest (I mean, how many clients even bother to parse
mailcap files as currently defined, let alone new features?)

Not to flame you, Bill, but your use of the quality settings above
looks exactly backward to me. The purpose of quality is to specify
how losslessly the client's viewer can present that content-type.
Presuambly you can display a bitmap losslessly, so you might specify a
quality setting of 1.0. A GIF might be slightly lossy, say about
0.95. A JPEG might be lossier still, since there are more colors to
quant down to a 256 colormap, so it might have a setting of 0.9 or
0.8. Now, naturally there is also lossiness on the server end (there
would be a lot of loss convering a JPEG to a bitmap) which the server
is supposed to calculate and multiply by the client lossiness.

What I would use low quality settings for are things like the

image/gif; giftoppm | pnmscale -width 80 | ppmtopgm | pgmtopbm | pbmtoascii;\

Now, *that's* lossy. But it does provide a very crude idea of what an
image looks like even on a VT100.

Marc VanHeyningen  <>