Message-ID: <365C3BB1.135C@alumni.cse.ucsc.edu>
Date: Wed, 25 Nov 1998 09:17:37 -0800
From: Paul Ausbeck <paula@alumni.cse.ucsc.edu>
MIME-Version: 1.0
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
References: <Pine.SOL.3.96.981125085520.23361d-100000@elect6>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: apache-bugdb-owner@apache.org
Precedence: bulk

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

Adam:

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

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

Paul