Re: lynx-dev Bug#35523: lynx: cookie handling broken with non-printable characters (fwd)

[Klaus Weide]

It just isn't possible to send a cookie like the following with HTTP:

    Set-Cookie: bunny="I3\012."
    (where \012 is LF)

Either the person reporting this misunderstands what's going on, or
is leaving out some information.

A LF char in a HTTP header ends that header line.  The above is
effectively the same as two lines:

    Set-Cookie: bunny="I3
    ."

which of course is completely invalid.  I don't know anything about the
"Python Cookie module", but if it has anything to do with CGI then
it shouldn't be possible to generate such a thing.

Even if this was not \012 aka LF but some other control character,
it would still violate

  1) the more recent State Management RFC and drafts,
  2) the HTTP specs, and
  3) probably the CGI specs (if CGI is involved).

It does not explicitly violate the "Preliminary Specification"
<http://home.netscape.com/newsref/std/cookie_spec.html> from Netscape,
which only says that "some encoding method such as URL style %XX
encoding is recommended, though no encoding is defined" and only
explicitly mentions "semi-colon, comma and white space", but that's just
further proof of the general sloppiness of that document.

I can't image which part of the Lynx cookie handling code would convert
a raw '\r' to the four characters '\\' '0' '1' '2', even if a raw '\r'
could get through.  Without a trace log, I just don't believe that can
happen.

Anyway, the persistent cookie support in lynx 2.8.1 is broken in several
ways.  AFAIK it was marked as "experimental" (it still is in recent
2.8.2dev.N code).  For example a cookie consisting only of

    Set-Cookie: bunny="anything"

shouldn't be stored in a cookie file *at all*, since there is no expiration
date, but lynx 2.8.1 does store it.  This is fixed in 2.8.2dev.N.

There may be problems (still present in lynx 2.8.2dev.N) related to the
dropping of surrounding quotes when persistent cookies are stored, but
we should get a better bug report.

If the Python Cookie module really tries to send raw binary data in HTTP
headers, then it is badly broken.  It should escape characters when required.
I find it more likely that it does that but, the bug reporter was not
looking at what is really being transmitted but at some cooked version.
But we would need to know what really goes over the wire.  Try lynx -trace
then sending Lynx.trace excerpts.

    Klaus