On Sat, 22 Apr 1995 wmperry@spry.com wrote:
> So netscape can't do inlined HTML then, eh? If all it sends are:
>
> Accept: image/gif
> Accept: image/jpeg
> Accept: image/xbm
> Accept: */*
>
> Then a server should lump text/plain, application/postscript, text/rtf,
> application/x-ms-word, and text/html all with the same rating, and is
> free to send whichever it wants. And application/x-ms-word would be the
> 'best' one to most servers.
Haha. We ran into this as well with Apache - it seems some clients would
rather get "mother.gif" than "mother.html". :)
So, the server at least presumes "text/html; q=1" and "text/plain; q=1" if
neither are explicitely mentioned. Of course, that may result in a bad
response to a VRML-only browser.....
Actually, that got deleted at Roy's insistence (the default specified
in the HTTP draft is *strictly* */*, if no explicit Accept: headers
are present, and that's what I went with). If someone actually does
specify a type map (either explicitly or through a MultiViews request
for 'mother' where mother.gif and mother.html both exist), well, they
get what they get.
(Fortunately, enabling content negotiation won't ever break existing
links by serving up the wrong variant in cases like this, since
existing links always point directly to one of the variants --- always
to 'mother.gif' or 'mother.html', whichever is required, and never
just to 'mother', which gets bounced with a file not found unless
MultiViews is enabled and the server is allowed to cruise the
directory for possible variants).
This does indeed have the awkward consequences Brian outlined above,
but that's not *nearly* as awkward as what you get by defaulting 'q'
on */* to 1.0 if not specified otherwise (see previous message for a
description of those... glitches). It has, at times, been a little
tempting to vary a bit from the strict letter of the standard for
cases like these (under control of some sort of config directive), but
I wanted to get the standard case right first.
rst