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