www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Ausbeck <pa...@alumni.cse.ucsc.edu>
Subject Re: mod_negotiation/3447: Accept-Encoding headers not used in mod_negotiation
Date Wed, 25 Nov 1998 17:20:01 GMT
The following reply was made to PR mod_negotiation/3447; it has been noted by GNATS.

From: Paul Ausbeck <paula@alumni.cse.ucsc.edu>
To: Dirk-Willem van Gulik <dirk.vangulik@jrc.it>
Cc: apbugs@hyperreal.org, apache-bugdb@apache.org
Subject: Re: mod_negotiation/3447: Accept-Encoding headers not used in mod_negotiation
Date: Wed, 25 Nov 1998 09:17:37 -0800

 I think that applying a quality factor to Accept-encoding might not make
 sense. The tie-breaking procedure seemed ok with me when I examined the
 code. That is why I just inverted the tie-breaking policy for the case
 where it is clearly more efficient to send the encoded variant.
 I am not in the position to spend enough time on this to completely
 rewrite the code. Below is a description of the algorithm that I sent to
 the original discoverer of the problem, Adam Costello.
 Paul Ausbeck
 I downloaded NN 4.5 and it handles gzip compression correctly.
 I also thought some more on how to describe the negotiation algorithm.
 The current method is quality factor based. The various variants are
 ranked according to quality factor without consideration of encoding
 The basic algorithm compares each variant in turn with the best variant
 found thus far. So if more than two variants exist with the same quality
 factor, the first considered remains the best. This basic technique is
 unchanged in my proposed algorithm.
 The encoding quality factor comes into play in a tie-breaker. If an
 unencoded variant exists with the same quality factor as the highest
 encoded variant, the tie is broken in favor of the unencoded variant.
 My change is to this tie-breaking procedure. If two variants exist with
 the same highest quality factor, the tie is broken in favor of the
 encoded variant if the client has expressed a preference for that
 variant throught Accept-Encoding. Otherwise, the tie-breaker reverts to
 the existing method.
 I do this by expanding the number of "states" of the encoding_quality
 variable. "Zero" indicates the browser says no to a particular type of
 encoding. This occurs when the browser says it will accept some types of
 encodings. Any that it doesn't accept are assumed to be rejected. 
 "One" indicates the browser is neutral (hasn't sent any Accept-Encoding
 headers). In the existing algorithm "one" also indicates that the
 browser has accepted a particular encoding.
 In my change the new state "two" indicates that the browser has
 expressed a preference for an encoding through Accept-Encoding. "One" is
 not overloaded and only expresses neutrality. The polarity of the
 encoding tie-breaking procedure is reversed only for variants in state

View raw message