Sorry for the double post, I thought my first post got dropped. But it was my fault because I hadn't subscribed. Anyway more below...
> ----- Original Message ----- > From: Graham Leggett <[EMAIL PROTECTED]> > To: [email protected] > Subject: confirm subscribe to [email protected] > > > Paul Fee wrote: > > > > Could someone point out a reason for the different behaviour in the > > request and response path? > > Cookies. > > Cookie headers cannot be compressed as the RFC says they should be, so > proxy works around this by not compressing headers. Thanks for that, now I see the problem. The response could contain a "set-cookie" header, such as: Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT The problem being the date may contain a "," character. Use of this reserved character for a purpose other than separating multiple header values means that the Set-Cookie header can not be compressed. Fortunately in the case of a request, the "cookie" header will not contain a date, hence the same problem is not present. > > > How about making the behaviour configurable so that it's consistent > > in both directions and if necessary the headers can be left in > > their original uncompressed form? > > In theory, the idea that it be consistent in both directions is not > unreasonable - it follows the principle of "be lenient in what we accept". Therefore, we've eliminated the idea of calling apr_table_compress() for the response due to set-cookie. Would you foresee any issues with disabling the apr_table_compress() call for the request? I'd like to add the option to leave request headers in the form in which they were received from the client. Today, multiple headers with the same name are compressed when read from the client. Therefore Apache modules reading the headers will see a single string with comma separated values. However modules, in theory, could also add new headers so we could have something like: hdr: value1, value2 hdr: value3 If apr_table_compress() was not called, would that break anything? Would modules expect comma separated values or would they be designed to cope with both representations as RFC2616 says they MUST? If we assume that the rest of Apache will cope with both representations, then disabling the call to apr_table_compress() in ap_get_mime_headers_core() will not cause problems. Of course we should keep it configurable and perhaps have the default set to enabled so as not to force new behaviour on users. Thanks, Paul -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
