On 09/18/2007 07:40 PM, Roy T.Fielding wrote: > On Sep 18, 2007, at 6:46 PM, Plüm, Rüdiger, VF-Group wrote: >> This works "as designed". Please see the difference between the accept >> headers sent by >> IE6 and Firefox >> >> IE6 : Accept-Encoding: gzip, deflate >> Firefox: Accept-Encoding: gzip,deflate >> >> IE6 adds an additional space between gzip and deflate. >> As the response varies on Accept-Encoding two representations of the >> response get saved >> (which are actually the same). >> It could be argued that this should not matter. > > Argued? The space does not change the value of the field (which is > a comma-separated list). The question is really up to us as to how
But this is only true for this special case of Accept-Encoding (and all other headers where the field-value is a comma separated list), correct? It wouldn't be true for a header whose field-content is made of *TEXT, right? How do we know if a field-value is just *TEXT or field-content LWS field-content? e.g. IMHO the field-value of the header Example below could be seen as *TEXT as well as token *separator token: Example: token1, token2 If we think it is *TEXT I think token1, token2 and token1,token2 are different values, whereas if we see it as token *separator token I think they represent the same value. > much effort we make to compare the values for equality, since the > non-match just makes our cache slow and bulky. Given the number Agreed. Depending on the answers above we may need to have a list of headers (like Accept-Encoding) where we compare the tokens in the field-value. For all other headers we would stay with the plain compare we do today. See also the TODO comments in mod_disk_cache.c::regen_key. Regards Rüdiger
