Hi Lars,
According to the HTTP specs: "If no Accept-Encoding field is present in a
request, the server MAY assume that the client will accept any content
coding. In this case, if "identity" is one of the available content-codings,
then the server SHOULD use the "identity" content-coding, unless it has
additional information that a different content-coding is meaningful to the
client."
I read this part too quickly and decided to assume that all encodings were
accepted in this case. It seems safer to only accept Identity encoding. Just
change line 254 of PreferenceUtils to:
preference.getEncodings().add(new EncodingPref(Encodings.IDENTITY));
Let me know if that solves the issue.
Thanks,
Jerome
> -----Message d'origine-----
> De : Lars Heuer [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 18 mai 2006 16:29
> À : Jerome Louvel
> Objet : CompressChainlet issue
>
> Hi Jerome,
>
> I discovered that the CompressChainlet compresses the output even if
> the accepted-encoding header is empty. Actually I've not tested this
> scenario at the beginning of this week.
> I am not sure who is responsible for the failure (the compress
> chainlet or the preferences).
> I'll investigate it further if I find some time.
>
> I seems that more JUnit tests would be a good idea. Are all test cases
> in the SVN? Or do you have more?
>
> Best regards,
> Lars
> --
> http://semagia.com
