On 22/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-10-22 at 19:00 +0100, sebb wrote:
> > On 22/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2008-10-22 at 11:52 +0100, sebb wrote:
> > > > 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.
> > > >
> > >
> > >
> > > I am not sure I can agree to that. I do not see anything in the draft
> > > suggesting that quoting may be disallowed. Moreover, the draft clearly
> > > states "some encoding method ... is recommended". To me, that clearly
> > > includes quoting.
> > >
> >
> > Quoting != encoding.
> >
>
>
> Why?
>
Not sure how to explain that. They both have the same goal - to ensure
that the value is interpreted correctly - but the mechanism is
different.
>
> > Besides, if there is quoting method then there needs to be a
> > definition of what characters require quoting, and what the quoting
> > character(s) are.
> >
>
>
> That is why I think Netscape draft is inherently ambiguous and Netscape
> cookies ought to be avoided
>
Agreed the spec is ambiguous and incomplete.
But HC purports to support Netscape cookies, and so should try to
support the de facto behaviour of Netscape cookies.
> Oleg
>
>
>
> > If we assume it follows RFC2109 in that regard, then "=" needs to be
> quoted.
> >
> > I guess it would be useful to know how the particular server behaves
> > if there is no "=" in the cookie value. Likewise browsers.
> >
> > > Oleg
> > >
> > >
> > > >
> > > > >
> > > > > 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]
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]
