www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@c2.net>
Subject Re: mod_negotiation/3447: Accept-Encoding headers not used in mod_negotiation (fwd)
Date Fri, 27 Nov 1998 17:40:00 GMT
The following reply was made to PR mod_negotiation/3447; it has been noted by GNATS.

From: Paul Sutton <paul@c2.net>
To: apbugs@apache.org
Cc:  Subject: Re: mod_negotiation/3447: Accept-Encoding headers not used in
 mod_negotiation (fwd)
Date: Fri, 27 Nov 1998 17:32:07 +0000 (GMT)

 I think this is a valid thing to fix, but I'm a bit concerned about the
 logic of the patch. Since it is Friday afternoon I might have made a
 mistake, so let me explain.
 This table shows how the first part of the patch will set the values of
 the content_encoding field for a particular variant:
                     no encoding            has an encoding X
 Request with
 no A-E:               1                       1
 Request with
 empty A-E:            1                       0
 Request with
 A-E: X                1                       2           }
 Request with                                              }
 A-E: without                                              }
 X                     1                       0           }
 The brackets (}) show that the last two lines can all occur on a single
 request, if there are variants with both matching an non-matching
 Now consider the second part of the patch below, when a request comes in
 with a non-empty A-E: line. Say A-E: gzip. Consider having variants
 x.gz and x, which are found _in that order_.
 Now the first variant, x.gz gets picked as the best so far (since it is
 the first, and is acceptable). So best->encoding is non-empty (it would
 also get picked in preference to any other variants without an encoding,
 because of encoding_quality = 2, as desired, using the second part of
 the "if" in the patch below).
 Now mod_negotiation looks at variant x. It is acceptable. So it gets to
 the code in the patch below. This variant's encoding_quality is 1, so the
 first part of the "if" below gets activated. This says that the best so
 far _has_ an encoding (which is does) _and_ the new variant does not have
 an encoding, we should pick the new variant (x) as the best so far. So we
 flip back to prefering the non-encoded variant.
 I think I'd prefer to see the logic of the second part of the patch below
 changed to:
   prefer the variant with the highest value of encoding_quality
   if both the best and variant's encoding qualities are the
   same, prefer the variant without an encoding
 The first bit means we prefer the variants with quality 2 over those with
 quality 1 (which is what this PR is about). The second part comes into
 play if the request as no A-E: and we have variants with and without
 encodings (the first line of the table), and prefers unencoded variants
 (the current default). 
 Paul Sutton, C2Net Europe                    http://www.eu.c2.net/~paul/
 Editor, Apache Week .. the latest Apache news http://www.apacheweek.com/

View raw message