You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1998/02/05 21:40:00 UTC

Re: mod_negotiation/1772: Can't handle both "Accept-Encoding: gzip" and "Accept-Encoding: x-gzip"

The following reply was made to PR mod_negotiation/1772; it has been noted by GNATS.

From: "Roy T. Fielding" <fi...@kiwi.ics.uci.edu>
To: Dean Gaudet <dg...@arctic.org>
Cc: Ronald Tschalaer <Ro...@psi.ch>, apbugs@hyperreal.org
Subject: Re: mod_negotiation/1772: Can't handle both "Accept-Encoding: gzip" and "Accept-Encoding: x-gzip" 
Date: Thu, 05 Feb 1998 11:42:42 -0800

 >Roy I'm not so clear on this one.  The spec does say gzip/x-gzip and
 >compress/x-compress should be considered equivalent, so that is a bug. 
 >But I can't find words in rfc2068, rfc2048 or rfc2045 which say we should
 >do this for all content encodings. 
 
 It's a good idea anyway.  My long-standing argument against the use of
 "x-" prefixes is that the only way to make a clean transition between
 them and a registered type is to strip any "x-" before comparison, thus
 making any use of "x-" a waste of time.
 
 +1 in concept, but I'd prefer it if the two-character comparisons were
 not done using strncmp.  For example
 
 >> !         if (!strncmp(name, "x-", 2))
 
 sucks performance-wise when compared to
 
              if (name[1] == '-' && (name[0] == 'x' || name[0] == 'X'))
 
 It would be even better if it parsed the optional q-value, which was
 recently added to the Accept-Encoding syntax (in spite of my objections).
 
 ....Roy