httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Problems with Content Negociation (fwd)
Date Thu, 16 May 1996 17:21:12 GMT
On Thu, 16 May 1996, Robert S. Thau wrote:

> A caveat:  "the same quality value" doesn't always mean what one
> might want it to mean.  For instance, suppose there are variants of a
> given resource available, an image/png variant at qs=0.9 and a
> text/plain variant at qs=0.2 (ascii graphics).  Now, if a browser
> sends:
>   Accept: text/html, text/plan, image/xbm, image/gif, image/jpeg, */*
> the png variant matches the wildcard, and its superior qs value gives
> it a *much* higher aggregate quality rating (q*qs), which causes it to
> be sent, even though the browser in this instance probably can't
> handle image/png terribly gracefully.  Note that jiggering the final
> products by 0.0002 (which is, I *think*, what your patch would do in
> this case --- apologies if I misread) would not affect the outcome.

Yes, that's what the patch does. It subtracts 0.0001 from the accept
quality value for a type/* wildcard and 0.0002 from a */* wilcard. And
I don't think it *should* affect the value for the case you cite. The
browser sent it, that's what it must want... Now one could make the
case that the browser in this instance is broken... but I make the
case that it's broken twice, which cancels out. Netscape 2.01, for
example, sends (from memory, could be something slightly different),

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Based on my knowledge of the browser (which I use regularly), I'd say
that what it *really* perfers is text/html, which falls under the */*
category. So it does perfer */* at the same level as the images, to
some degree.

> The server really does have to treat wildcards as having a
> *substantially* lower q value in order to generate sensible behavior
> in these sorts of examples, given what existing browsers actually do
> send.

Right, but you can't generalize that, because some browsers to get it
right, and these would get screwed if you substantially lowered the
values internally in Apache. Now, we could compare User-Agent strings,
but this seems dubious in its value.

Note that Netscape 2.0 and later, for example, does better than
earlier versions did... when requesting an inline image, it doesn't
send the */*, just the five image/* formats it supports.

> FWIW, in cases where two variants have the exact same *aggregate*
> quality rating (q*qs), the existing code has a tiebreaking rule which
> favors the first type listed in the Accept: headers, which would give
> matches to the wildcard the lowest preference in the cited example,
> and in yours.  (This rule is actually implicit in the order in which

This is actually where the bug report came from. Someone was using a
browser that sent */* first. Fixing it so that in cases of ties,
wilcard entries are not perffered over non-wildcard ones would solve
their problem, and that's all my patch tries to do.

> the variants are checked, but it's there nonetheless).  There are also
> numerous other tie-breaking rules which come into play in this
> situation, and preferring exact matches to wildcards might be a good
> one to add, but I'm not sure that jiggering the numbers is the best
> way to do it.

Well, it seemed the simplest. Least likely to break something else.

Alexei Kosut <>      The Apache HTTP Server
      "War does not determine who is right, only who is left."

View raw message