[Zope2] Multiline response headers causing problems for proxies.
When using response.appendHeader, Zope appends the new value following an ",\r\n\t" which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value. In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything" Are there any objections to me applying the attached patch to Zope 2.13 and trunk? Laurence [1] http://www.varnish-cache.org/trac/ticket/905 [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html [3] http://tools.ietf.org/html/rfc1945#section-4.2 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/18/2011 12:01 PM, Laurence Rowe wrote:
When using response.appendHeader, Zope appends the new value following an ",\r\n\t" which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value.
In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything"
Are there any objections to me applying the attached patch to Zope 2.13 and trunk?
+0. We likely need to test that your patch doesn't break stuff on other maybe-not-compliant servers (older Apache, IIS). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2shMUACgkQ+gerLs4ltQ4oKgCg0/BXLTh3VvpBGeNgc+WFKx9V UdEAnRp1lxbXDKFbrJ8nBwgWaRJ/B0y1 =xjg8 -----END PGP SIGNATURE-----
On 18 April 2011 19:36, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2011 12:01 PM, Laurence Rowe wrote:
When using response.appendHeader, Zope appends the new value following an ",\r\n\t" which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value.
In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything"
Are there any objections to me applying the attached patch to Zope 2.13 and trunk?
+0. We likely need to test that your patch doesn't break stuff on other maybe-not-compliant servers (older Apache, IIS).
I don't think there is any risk of this. Plone's CacheFu has always generated the Cache-Control header as a single line, e.g. "Cache-Control:max-age=0, s-maxage=0, must-revalidate" and that has never caused a problem. The problem only rarely shows up because appendHeader is very rarely called, normally setHeader is used. In fact the only usage of it I could find of appendHeader in my egg cache or the entire Zope2 / Plone is in ZPublisher.HTTPResponse where it is called when gzipping the response (to add 'Accept-Encoding' to the Vary). Even then, it only causes a mulit-line header to be generated when you've already set Vary to something else (for instance Accept-Language.) For servers acting as pure proxies, the header value is opaque, so there is no risk. The only possible way a problem could arise is if they interpret the value in the header. Given that the only time this ever happens is with the Vary header, then only caching proxy servers need worry us. Given that they already cope just fine with the usual ", " delimited list of values in the Cache-Control header, I don't think compatibility issues need worry us here. Laurence
On 18 April 2011 17:01, Laurence Rowe <l@lrowe.co.uk> wrote:
When using response.appendHeader, Zope appends the new value following an ",\r\n\t" which splits the header over multiple lines. While this behaviour is standards compliant, it causes problems for both Varnish [1] and Nginx [2] which may then mangle the header value.
In fact the HTTP 1.0 spec notes that splitting over multiple lines in not recommended [3], though the HTTP 1.1 spec does not mention this explicitly, though it does say [4]: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything"
Are there any objections to me applying the attached patch to Zope 2.13 and trunk?
Laurence
[1] http://www.varnish-cache.org/trac/ticket/905 [2] http://nginx.org/pipermail/nginx-devel/2011-April/000859.html [3] http://tools.ietf.org/html/rfc1945#section-4.2 [4] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
I've now applied this to 2.13 and trunk. If it causes any problems, let me know. Laurence
participants (2)
-
Laurence Rowe -
Tres Seaver