Apr 9, 1995, 11:25 AM
Post #6 of 6
(1672 views)
Permalink
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