[ZCM] [ZC] 2300/ 3 Comment "Zope sends malformed Vary header"

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

==============================================================
= 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


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