On 22/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-10-21 at 20:50 +0100, sebb wrote:
> > On 21/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2008-10-21 at 13:07 +0100, sebb wrote:
> > > > On 20/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > > > > On Mon, 2008-10-20 at 09:42 -0700, Joseph Mocker wrote:
> > > > > > It sounds like your webserver, or whatever is generating &
> processing
> > > > > > the session cookie, is in error. From my reads of RFC2109 &
> RFC2068,
> > > > > > quotes are reserved characters, they are not allowed in the
> cookie value.
> > > > > >
> > > > > > They say the cookie value can be either
> > > > > >
> > > > > > token | quoted-string
> > > > > >
> > > > > > where
> > > > > >
> > > > > > token = 1*<any CHAR except CTLs or tspecials>
> > > > > >
> > > > > > tspecials = "(" | ")" | "<" | ">" | "@"
> > > > > > | "," | ";" | ":" | "\" | <">
> > > > > > | "/" | "[" | "]" | "?" | "="
> > > > > > | "{" | "}" | SP | HT
> > > > > >
> > > > > > and
> > > > > >
> > > > > > quoted-string = ( <"> *(qdtext) <"> )
> > > > > >
> > > > > > qdtext = <any TEXT except <">>
> > > > > >
> > > > > >
> > > > > > So in your example, the quoted-string form is used, therefore
> the quotes
> > > > > > are not part of the cookie value.
> > > > > >
> > > > > > Perhaps one of the developers can comment?
> > > > > >
> > > > >
> > > > >
> > > > > Joe,
> > > > >
> > > > > I second that. The culprit is the broken server side script.
> > > > >
> > > >
> > > > I agree that the quotes are not part of the value, however, I don't
> > > > agree that the server is broken.
> > > >
> > > > RFC 2109 says that the cookie value can be a token, or a quoted
> > > > string. Given that arbitrary white-space is allowed between tokens,
> > > > quotes are required to preserve spaces and any other special
> > > > characters.
> > > >
> > > > In this case the trailing "=" is not allowed in a plain token, but it
> > > > is allowed in TEXT.
> > > >
> > > > RFC 2068 says:
> > > >
> > > > CTL = <any US-ASCII control character
> > > > (octets 0 - 31) and DEL (127)>
> > > >
> > > > TEXT = <any OCTET except CTLs,
> > > > but including LWS>
> > > >
> > > > So for example the value <Apache HttpClient> would need to be
> provided as:
> > > >
> > > > Set-Cookie: Product="Apache HttpClient"
> > > >
> > > >
> > > > and returned to the server as
> > > >
> > > > Cookie: Product="Apache HttpClient"
> > > >
> > > > Likewise, the value <dfgsdfgsdg=> needs to be quoted, both in the
> > > > Set-Cookie and Cookie headers.
> > > >
> > > > It's not clear from RFC2108 whether user agents are allowed to strip
> > > > quotes from values if the quotes are not necessary - i.e. where the
> > > > value is a valid token - but it seems to me that user agents must not
> > > > strip quotes which are required to ensure that the value is valid.
> > > >
> > > > As far as I can tell, the header:
> > > >
> > > > Cookie: POSESSIONID=dfgsdfgsdg=
> > > >
> > > > is not valid according to RFC2109 , because the trailing "=" is not
> > > > valid in a token - it has to be quoted as in:
> > > >
> > > > Cookie: POSESSIONID="dfgsdfgsdg="
> > > >
> > >
> > >
> > > Well, it is all nice and dandy, and I almost got convinced, but there is
> > > one little detail. The Set-Cookie header in question violates both
> > > RFC2109 and RFC2965 by not including the mandatory Version attribute.
> >
> > OK, I'd overlooked that detail.
> >
> > > Therefore, all well-behaved HTTP agents MUST treat that cookie as
> > > Netscape compatible. As far as Netscape cookie draft is concerned the
> > > following cookie is perfectly valid, as the spec does not impose any
> > > restrictions on characters used in cookie values:
> > >
> > > Cookie: POSESSIONID=dfgsdfgsdg=
> > >
> >
> > I found a copy of the Netscape draft at:
> >
> > http://curl.haxx.se/rfc/cookie_spec.html
> >
> > Which says:
> >
> > >>>
> > Set-Cookie: NAME=VALUE; expires=DATE;
> > path=PATH; domain=DOMAIN_NAME; secure
> >
> > NAME=VALUE
> > This string is a sequence of characters excluding semi-colon, comma
> > and white space. If there is a need to place such data in the name or
> > value, some encoding method such as URL style %XX encoding is
> > recommended, though no encoding is defined or required.
> > <<<
> >
> > I read this as meaning that " (double-quote) is valid as a character
> > in a Netscape cookie value.
> >
> > In which case I contend that the server is entitled to send the cookie
> > value with quotes in it and to expect the quotes in the cookie to be
> > returned by the user agent.
>
>
> Netscape draft leaves a lot of room for different interpretations. I
> certainly do not see any reason why the server should reject a cookie
> without the quotes in the cookie value. To me, the server script is
> still utterly broken.
>
My reading of the spec. suggests that the quotes are part of the
value, in which case it is clearly an error to remove them, and the
server is correct in not recognising the value.
As far as I can tell, the Netscape draft does not allow for any form
of quoting, therefore it is an error to assume that enclosing quotes
can be removed.
>
> Oleg
>
>
> >
> > > So, the server is _badly_ broken form the standpoint of both RFC2109 and
> > > RFC2965, and on top of that it even messes up Netscape compatibility.
> > >
> >
> > It may be broken in terms of the RFCs, but to me it seems to be OK as
> > far as the Netscape spec is concerned.
> >
> > > Oleg
> > >
> > >
> > >
> > > > >
> > > > > Oleg
> > > > >
> > > > >
> > > > > > --joe
> > > > > >
> > > > > >
> > > > > > Reinhard Pagitsch wrote:
> > > > > > > Hello to all,
> > > > > > >
> > > > > > > From our webserver I get a session cookie in the form
> > > > > > > POSESSIONID="dfgsdfgsdg="
> > > > > > > But the HTTPClient sends back the cookie in the form
> > > > > > > POSESSIONID=dfgsdfgsdg=.
> > > > > > > Therefore no authentication is done. Is there a way to
> configure the
> > > > > > > HttpClient to send back
> > > > > > > the session cookie as it is and do no modifications?
> > > > > > >
> > > > > > > Thank you,
> > > > > > > Reinhard
> > > > > > >
> > > > > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
