Mailing List Archive

> So, retrievals of /some/dir/index.var will be affected by the qs
> values in the map (which is as follows):
>
> URI: 01; vary="type,language"
>
> URI: 01.jpg
> Content-type: image/jpeg; qs=0.8
>
> URI: 01.gif
> Content-type: image/gif; qs=0.5
>
> 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?


> And a directory containing:
>
> 01.gif
> 01.jpg
>
> http:/01 always returns the .gif.
>
> http:/some/dir/01 does MultiViews, which makes its own type map from
> the 01.* files that it finds --- it does *not* read any *.var file.

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

> 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.

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.


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

From: Randy Terbush <randy@zyzzyva.com>
Reply-To: new-httpd@hyperreal.com


With the following in 'index.var'

So, retrievals of /some/dir/index.var will be affected by the qs
values in the map (which is as follows):

URI: 01; vary="type,language"

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

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

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.

And a directory containing:

01.gif
01.jpg

http:/01 always returns the .gif.

http:/some/dir/01 does MultiViews, which makes its own type map from
the 01.* files that it finds --- it does *not* read any *.var file.

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.

What am I missing? How can I debug this? I was looking
through the code to see if we can somehow log the actual
file served instead of the file requested. This would
be helpful to assure me of what file I am getting. :-)

This dovetails pretty nicely with Andrew's concerns on redirects.

rst

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

finally catching up on some old mail ...

rst said:

> (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...).

Ummmm, hierarchical yes, but I personally hate Lisp. PRDM (lisp-based)
is tolerable only because it is class-based and explicitly typed.
Actually, any hierarchical format that is trivial to parse (and readable)
would be good. You are welcome to invent one.

> 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

Grrr..grumble..grumble. That's not what qs means -- how is the server
supposed to know which one is a "better source" on a global basis?
If the image has > 256 colors, a JPEG will clearly be better. On the
other hand, a 255 color GIF will be a better source than a JPEG reduction
to 50 colors.

Also, at least one URI should have a qs of 1 -- the quality factor
is a degradation measure. Gee, I guess that should be in the spec. ;-)

> 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).

I will change the draft -- this is one of the issues I brought up at
the IETF. Is it sufficient to say:

Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to
a given type, the most specific reference has precedence. For example,

Accept: text/*, text/html, text/html;version=2.0, */*

have the following precedence:

1) text/html;version=2.0
2) text/html
3) text/*
4) */*

The quality value associated with a given type is determined by
finding the media range with the highest precedence which matches
that type. For example,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5

would cause the following values to be associated:

text/html;version=2.0 1
text/html 0.7
text/plain 0.3
image/jpeg 0.5
text/html;level=3 0.7

I think that will suffice. I suggested letting */* default to q=0.5
at the meeting, but that didn't go over well. I will also add some verbage
to the effect that a server may make type-specific assumptions about
parameter value precedence and inclusiveness (i.e., level=3 => version=3.0
and version=3.0 includes version=2.0 for text/html).

NOTE: The level parameter is destined for extinction -- version will
likely be used instead. text/html with tables will probably be
called "text/html;version=2.1"
once the WG folks issue the new table draft and Dan Connolly
updates his W3C stuff.

Another issue: We (as in the IETF) will not specify an automatable response
entity for codes 300 and 406 in HTTP/1.0 -- they will be treated like
any other error code, with the content determined by the server.
This will probably make more sense when the next draft comes out.

........Roy

Date: Fri, 07 Apr 1995 19:26:59 -0700
From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>

Grrr..grumble..grumble. That's not what qs means -- how is the server
supposed to know which one is a "better source" on a global basis?
If the image has > 256 colors, a JPEG will clearly be better. On the
other hand, a 255 color GIF will be a better source than a JPEG reduction
to 50 colors.

But remember, this was in a response to an actual user (Randy) who
actually wanted these as at least default qs values for his jpegs and
gifs respectively, presumably because those are more reasonable
defaults for his own site than qs=1 for each.

(Think about it --- the server doesn't "know" that qs=1 is appropriate
for these cases either; it's an ad hoc assumption. The AddType lines
above specify a *different* ad hoc assumption, for cases where the
server has no further information, and without knowing something about
the images on Randy's machine, you can't really say which of the two
assumptions is more likely to be correct. But see further remarks
below on setting qs).

> 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).

I will change the draft -- this is one of the issues I brought up at
the IETF. Is it sufficient to say:

Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to
a given type, the most specific reference has precedence. For example,

Not what my code currently does, but it's easy to change. (See prior
implementation notes).

For example,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5

would cause the following values to be associated:

text/html;version=2.0 1
text/html 0.7
text/plain 0.3
image/jpeg 0.5
text/html;level=3 0.7

These assignments seem to assume "version" doesn't default to 2.0 for
text/html. Are they required to be maintained even in the face of
server defaulting rules for type parameters (as you suggest below)?

I think that will suffice. I suggested letting */* default to q=0.5
at the meeting, but that didn't go over well.

That's really unfortunate --- it makes 'qs' values a serious
misfeature when applied to the current crop of browsers (most of which
send a list of media types and */* --- sending one of the named media
types is always preferable to sending something else, but the draft
requires that you send "something else" anyway if it happens to have a
higher qs value).

I'm thinking seriously about giving webmasters the option of having
*/* default to q=0.1 anyway, under config-file option, with the
admonition that it's a deliberate variation from the precise letter of
the most recent HTTP draft.

I will also add some verbage
to the effect that a server may make type-specific assumptions about
parameter value precedence and inclusiveness (i.e., level=3 => version=3.0
and version=3.0 includes version=2.0 for text/html).

NOTE: The level parameter is destined for extinction -- version will
likely be used instead. text/html with tables will probably be
called "text/html;version=2.1"
once the WG folks issue the new table draft and Dan Connolly
updates his W3C stuff.

Hmmm... I'm getting a little bit worried that there may not *be*
content-type discrimination of tables vs. non-tables HTML, because
there won't be an authoritative document that says how to do it when
the tables-capable browsers hit the market, and the non-authoritative
ones keep changing so fast that it's too risky to implement what they
specify. (It may just get wiped away in the next committee meeting,
and replaced with something incompatible).

Of course, that is not a statement about the technical merits of the
change --- from that perspective, "version" actually makes a little
more sense than "level". Just call it a general grump.

Another issue: We (as in the IETF) will not specify an automatable response
entity for codes 300 and 406 in HTTP/1.0 -- they will be treated like
any other error code, with the content determined by the server.
This will probably make more sense when the next draft comes out.

OK, I'll cook something up when I have a chance. (Right now,
finishing up the non-forking stuff is taking most of my server-hacking
time).

rst