httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: content-arbitration
Date Mon, 03 Apr 1995 10:00:29 GMT
   Date: Sun, 02 Apr 1995 17:36:55 -0500
   From: Randy Terbush <randy@zyzzyva.com>

   > Note that this means that clients which don't send any quality
   > preferences of their own (and most don't) should always get the jpeg,
   > when retrieval goes through this map.

   How do I determine what a kind of preference a browser is sending?

If it's not Arena, it isn't sending any ;-).

   That means that if the client does not send a preference, then it get's
   the first file in the map?

If you're actually going through a map file, then yes.  If you're
going through MultiViews, the server's choice will be random, but
consistent as long as the directory doesn't change.  (It's actually by
order of the files in the directory, but explaining that in the docs
is probably more trouble than it's worth).

   > I've keep on getting the feeling that in this circumstance, MultiViews
   > should read 01.var if it finds it, rather than using its own map.  I
   > originally thought that this sort of mixing of the two mechanisms
   > would cause more confusion than it solved, but I'm more and more
   > seeing that the reverse seems to be the case.

Incidentally, I've made a patch which arranges for this behavior ---
I'll probably be uploading to hyperreal in the next day or two, but
now that I'm actually running Apache on port 80, I'd like to be able
to test it here first.

   I guess that I had understood that index.var is a global map
   file for everything in the current directory.  ie. while more than
   one file in map; read index.var.

Ummm... nope.  However you got this impression, we need to do
something to correct it.

(Incidentally, I don't think per-directory type maps are a bad idea,
but the current type-map syntax doesn't easily generalize that far;
there's nothing in it which says which entries are variants for which
URIs.  I suppose Roy will point out that this is an advantage of
hierarchical lisp-based syntaxes...).

   I also find myself wanting to do:

   URI: *.jpg
   Content-type: image/jpeg; qs=0.8

   URI: *.gif
   Content-type: image/gif; qs=0.5

Try this:

  AddType image/jpeg;qs=0.8 jpeg
  AddType image/gif;qs=0.5 gif

(Note the absence of whitespace between types and params).

However, with the current crop of browsers (which don't send q
values), this will *always* send the jpeg if both are available, even
if the browser actually said "Accept: image/gif" and didn't say
anything at all about Accept:ing jpeg's.

(This is the same problem you had earlier with html vs. html3; at
least in that case, and for browsers which, unlike Netscape, send
"Accept: text/html", things would work more sensibly if the 'q' values
on wildcard Accept: headers defaulted to a value lower than one, say
0.1.  I could easily change the code to do this, but we then wouldn't
be in conformance with the draft standard.  There are two ways out of
this --- change the draft, or put it under control of a config
directive, so people who want exact standard conformance can have it).

rst

Mime
View raw message