-
Bug
-
Resolution: Unresolved
-
P4
-
9
Customer proposed a RFE which is filed under bugdb 21226574.
However, customer suggests to add a javadoc change to JDK9. Simply making it clear that the method supports cookie parsing in one direction only, and draw attention to the conflicting standards of Cookie header field encoding depending on the direction. It needs to be clear to the developer when this method should be used and when not. At the moment it is unclear.
ACTUAL BEHAVIOR
---------------
HttpCookie parse fails if version attribute is first
The java-doc for java.net.HttpCookie.parse(String) does indicate that it can parse either "set-cookie" or "set-cookie2" headers. But it also states that it supports parsing a header with no leading token at all. It is therefore a subtle inference that the developer must make that this parse utility only supports cookies send FROM a server, and does NOT support the "cookie" header value when sending cookies TO a server. The cookie specification (RFC 2109: https://www.ietf.org/rfc/rfc2109.txt) states that the cookie header, and the set-cookie header should be formatted slightly differently. When sending cookies FROM the server (set-cookie), the cookie name-value attribute-value pair must be first; and that all other attribute-value pairs (including version) come afterwards. However, the format for the cookie header attribute states that the cookie-version attribute must come first. When the cookie-version attribute (e.g. "$Version=1;") comes first, the HttpCookie.parse method fails, and throws an java.lang.IllegalArgumentException: Illegal cookie name.
At the least, this lack of support for parsing "cookie" headers where the version attribute comes first should be clearly documented in the HttpCookie.parse method's java-doc; but really the implementation should be changed to support both "set-cookie" and "cookie" header parsing.
It should be noted that the Open Source library org.apache.cxf:cxf-rt-transports-http explicitly formats cookies with the Version number first when populating the "cookie" header field: see org.apache.cxf.transport.http.Cookie.requestCookieHeader()
EXPECTED BEHAVIOR
-----------------------
At the least, this lack of support for parsing "cookie" headers where the version attribute comes first should be clearly documented in the HttpCookie.parse method's java-doc; but really the implementation should be changed to support both "set-cookie" and "cookie" header parsing.
However, customer suggests to add a javadoc change to JDK9. Simply making it clear that the method supports cookie parsing in one direction only, and draw attention to the conflicting standards of Cookie header field encoding depending on the direction. It needs to be clear to the developer when this method should be used and when not. At the moment it is unclear.
ACTUAL BEHAVIOR
---------------
HttpCookie parse fails if version attribute is first
The java-doc for java.net.HttpCookie.parse(String) does indicate that it can parse either "set-cookie" or "set-cookie2" headers. But it also states that it supports parsing a header with no leading token at all. It is therefore a subtle inference that the developer must make that this parse utility only supports cookies send FROM a server, and does NOT support the "cookie" header value when sending cookies TO a server. The cookie specification (RFC 2109: https://www.ietf.org/rfc/rfc2109.txt) states that the cookie header, and the set-cookie header should be formatted slightly differently. When sending cookies FROM the server (set-cookie), the cookie name-value attribute-value pair must be first; and that all other attribute-value pairs (including version) come afterwards. However, the format for the cookie header attribute states that the cookie-version attribute must come first. When the cookie-version attribute (e.g. "$Version=1;") comes first, the HttpCookie.parse method fails, and throws an java.lang.IllegalArgumentException: Illegal cookie name.
At the least, this lack of support for parsing "cookie" headers where the version attribute comes first should be clearly documented in the HttpCookie.parse method's java-doc; but really the implementation should be changed to support both "set-cookie" and "cookie" header parsing.
It should be noted that the Open Source library org.apache.cxf:cxf-rt-transports-http explicitly formats cookies with the Version number first when populating the "cookie" header field: see org.apache.cxf.transport.http.Cookie.requestCookieHeader()
EXPECTED BEHAVIOR
-----------------------
At the least, this lack of support for parsing "cookie" headers where the version attribute comes first should be clearly documented in the HttpCookie.parse method's java-doc; but really the implementation should be changed to support both "set-cookie" and "cookie" header parsing.