[ZCM] [ZC] 2300/ 5 Resolve "Zope sends malformed Vary header"

Issue #2300 Update (Resolve) "Zope sends malformed Vary header"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/2300

==============================================================
= Resolve - Entry #5 by mj on Mar 27, 2007 8:54 am

 Status: Accepted => Resolved

Fix checked in for Zope 2.9:

http://svn.zope.org/Zope/branches/2.9/?rev=73721&view=rev

Zope 2.10:

http://svn.zope.org/Zope/branches/2.10/?rev=73722&view=rev

and Zope trunk:

http://svn.zope.org/Zope/trunk/?rev=73723&view=rev
________________________________________
= Accept - Entry #4 by mj on Mar 26, 2007 3:33 am

 Status: Pending => Accepted

 Supporters added: mj

Yes, internally ZPublisher.HTTPResponse deliniates headers with only newline, but ZServer.HTTPResponse then uses '\r\n' to write out the headers. The end-result for the browser is '\r\n' delimeted headers.

There is a bug here though, but only when using addHeader; self.accumulated_headers is output directly, without cleaning up the header capitalisation (a SHOULD), and with \n separation instead of \r\n (a MUST). I'll fix the latter.

Now, if the Vary header was added using addHeader it will get \n deliminations indeed.
________________________________________
= Comment - Entry #3 by ctheune on Mar 26, 2007 2:28 am

That's my interpretation of RFC2616 as well:

"HTTP/1.1 defines the sequence CR LF as the end-of-line marker for 
 all protocol elements except the entity-body (see appendix 19.3 for
 tolerant applications). The end-of-line marker within an 
 entity-body is defined by its associated media type, as described
 in section 3.7.

       CRLF           = CR LF
"

________________________________________
= Comment - Entry #2 by limi on Mar 25, 2007 6:49 pm

And on IRC, Wichert added:

"HTTP RFCs say headers are \r\n seperated"

:)
________________________________________
= Request - Entry #1 by limi on Mar 25, 2007 6:46 pm

>From http://dev.plone.org/plone/ticket/5786:

"""
We have a proxy that checks the web site before allowing access, and if there is a mistake, we can't connect to your web site.

Your web site answers as a vary accept-encoding which is normal, but the next value is not correct. The line return for this Vary is "\n" instead of being "\r\n".

"""

Wichert adds:

"""
>From ZPublisher.HTTPResponse.HTTPResponse.setHeader:

        key = name.lower()
        if accumulate_header(key):
            self.accumulated_headers = (
                "%s%s: %s\n" % (self.accumulated_headers, name, value))
            return

Notice how that uses \n
"""

This seems to be an issue in Zope. I'm not sure what the specs say, but it seems like both \r\n is required here.

Full case history:

http://dev.plone.org/plone/ticket/5786


==============================================================