[
https://issues.apache.org/jira/browse/HTTPCLIENT-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15783197#comment-15783197
]
Detlev Beutner commented on HTTPCLIENT-1006:
--------------------------------------------
Hi there,
Some follow-up some years later ;-)
# Concerning RFC 2109, as Liang Sung pointed out, quoted-strings are allowed
for values. So, following this (very old) RFC, the double-quotes should NOT be
stripped.
# Concerning RFC 2965, the same holds: "value = token |
quoted-string" and so on... No mentioning to strip the quotes.
# Concerning the current RFC 6265, the same holds again: "cookie-value =
*cookie-octet / ( DQUOTE *cookie-octet DQUOTE )" and so on... No mentioning to
strip the quotes.
So far about the theory, with very good hint by Liang Sun for the technical
background / need.
Now concerning reality, I have the following example:
Call https://launchpad.support.sap.com (the main support site of SAP!) and
trace the http traffic. launchpad.support.sap.com redirects via JS to
authn.hana.ondemand.com, which again redirects via JS to
accounts.sap.com(/saml2/idp/sso/accounts.sap.com). The last request leads to a
response with a header as follows:
Set-Cookie
XSRF_COOKIE="77+976SSde+/vQFq77+9HO+/vXND77+977+9dGwQ77+9Fu+/vXBtTe+/ve+/vUZt77+9cFfvv706MTQ4MjkzNDg4Nzk1NA==";
Version=1; Path=/; Secure; HttpOnly
The value (base64 encoded value of some binary stuff and a timestamp), sent
back to the server, in about 60% needs to be enclosed by doublequotes,
otherwise the server answers with a 400 (bad request), probably for similar
reasons Liang Sun pointed out (the given value above for example needs the DQs).
Now, how do browsers work with this?
# IE11: Sends the value back with double quotes.
# FF50.1: Sends the value back with double quotes.
# Chrome 54: Sends the value back with double quotes.
Currently, the following CookieSpecs are non-deprecated:
NETSCAPE
STANDARD
STANDARD_STRICT
DEFAULT
>From these only NETSCAPE supports the persistence of the double quotes (where
>in fact the old Netscape cookie draft did not mention DQs at all, but also did
>not explicitly exclude them).
>From the real-world scenarios given above, the pragmatic DEFAULT /has/ to
>persist the DQs, too.
>From the RFC 6265, as well as 4.1.1 as 5.2 Alg. 1 (esp. #6, which defines that
>the DQ's are part of the value itself), STANDARD as well as STANDARD_STRICT
>/have/ to persist the DQs, too.
So I would suggest to re-open and fix this. I cannot realize any reason for any
of the currently supported CookieSpecs (which handle cookies at all; i.e.
except IGNORE_COOKIES ;-)) why to strip the DQs. If somewhere in the world
there is an example for such a need, I think /for this/ a new spec might be
needed. Stripping the DQs in the current specs is just a bug (and always was).
Best regards, Detlev
> BrowserCompatSpec: don't trim " around cookie value
> ---------------------------------------------------
>
> Key: HTTPCLIENT-1006
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1006
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.0.2
> Reporter: Marc Guillemot
>
> If the server sends a cookie header like:
> Set-Cookie: first="hello world"
> then HttpClient parses it as cookie with value >hello world<, wrongly
> removing the leading and trailing quotes. The incorrect quote removal occurs
> in BasicHeaderValueParser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
