On Wed, 2008-10-22 at 19:15 +0100, sebb wrote:
> 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.
> 

I respectfully disagree. Any transformation that disambiguates input is
encoding to me.

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

I agree to that. What I cannot agree to is that one (in my opinion,
clearly broken) CGI script constitutes the de facto behaviour.

Anyway, feel free to make adjustments to the existing cookie specs you
deem necessary.

Oleg 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to