tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Tomcat Wiki] Update of "Cookies" by jboynes
Date Sat, 04 Jan 2014 21:25:57 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.

The "Cookies" page has been changed by jboynes:

Add proposal to focus discussion of the issues.

  = Cookies =
+ == Proposed Changes ==
+ The intent of the following changes is improve interoperability of cookies with other servers
and with client-side !JavaScript. The primary changes are a switch to the RFC6265 format for
transmission of V0 cookies to be more in line with browser behaviour, and support for UTF-8
encoded values that are now specified by HTML-5.
+ This is very preliminary and intended primary to focus discussion on something concrete
now the behavior has been clarified.
+ === Changes to Cookie class ===
+  C1 Stricter default validation of name::
+  :: Change the default value of STRICT_NAMING to be true even if STRICT_SERVLET_COMPLIANCE
is false. Application impact is that applications that wish to set cookies with names that
are valid per Netscape's rules but that are not valid "tokens" per RFC2109 or RFC6265 will
need to explicitly set this system property. The intent of the change is to notify application
developers that they are using a cookie name that is likely to have interoperability issues.
+  :: '''Alternative C1a:''' remove option for Netscape naming entirely. Applications that
need to set names that do not comply with RFC2109 and RFC6265 would need to sub-class Cookie
themselves. If this is common, then we could provide a default implementation of that behaviour
(e.g. o.a.t.!NetscapeCookie).
+  C2 Always allow "/" in Netscape cookie names::
+  :: Discontinue use of FWD_SLASH_IS_SEPARATOR to configure whether a "/" character can appear
in a name when STRICT_NAMING is false and instead always allow it. No negative application
impact and matches the behaviour of the RI. This property was introduced to prevent quoting
of tokens used in Path values as that is not supported by IE but that behaviour is not needed
for names.
+  C3 Always disallow "=" in Netscape cookie names::
+  :: Now throw !IllegalArgumentException if a "=" character is present. Application impact
is that an attempt to use "=" will now trigger an IAE before the cookie is sent rather than
having the browser set a cookie with an inconsistent name and value. When parsing the received
Set-Cookie header, browsers treat all characters up to the first "=" character as the name
and the remainder as the value. Having a "=" character in the name will result in an incorrect
+ === Changes to generation of Set-Cookie header ===
+  G1 Use RFC6265 format header for V0 cookies::
+  :: When version == 0 always generate a RFC6265 header, raising an exception from addCookie
if the value is invalid rather than attempting to upgrade to a RFC2109 header to use quoting.
Application impact is that they will now fail fast with an error rather than inconsistent
data as described in Bug 55920; applications that do not set invalid values will not be impacted.
+  G2 Use RFC2109 format header only for V1 cookies::
+  :: When version == 1 always generate a RFC2109 header, raising an exception from addCookie
if the value is invalid. This preserves existing behaviour for applications that use V1 cookies.
+  G3 Stop adding quotes or escaping to values::
+  :: The value supplied by the application will be validated to the relevant specification
and will result in a IAE if it does not conform. The value will never be modified to add quotations
or escape characters, Application impact is that an attempt to set an invalid value will result
in an early error rather than inconsistent data.
+  G4 Use UTF-8 encoding for values::
+  :: The value (which is a UCS-16 Java String) will be encoded using UTF-8 when being added
to the header. Application impact is that non-ASCII characters will no longer cause an IAE.
For V0 cookies, this is an extension to RFC6265 required to support HTML-5. V1 cookies already
allow 8-bit characters if quoted and this is likely to be needed to avoid an IAE as the value
would still be validated; it would be the application's responsibility to quote the value.
+  G5 Validate domain per RFC6265::
+  :: The domain will now be validated per RFC1034 rather than simply as a value. Application
impact is that an invalid domain will now raise an IAE rather than be rejected by the browser.
No semantic validation (e.g. number of dots) will be performed. A valid domain name is a "token"
and so no quotation would be needed.
+  G6 Do not quote Path values for V0 cookies::
+  :: The quotes needed to make a Path value valid per RFC2109 will no longer be added for
V0 cookies. No application impact. Paths contain "/" characters which require quoting in a
RFC2109 value which causes issues for IE which does no expect the quotes; the FWD_SLASH_IS_SEPARATOR
property was used to prevent them being added. This behaviour is not needed for a V0 cookie.
+  G7 Always set both Max-Age and Expires as a pair::
+  :: When maxAge >= 0, then always set both Expires (Netscape) and Max-Age (RFC2109 and
RFC6265) attributes to support older and newer browsers. This removes the need for the ALWAYS_ADD_EXPIRES
system property.
+ === Changes to parsing of Cookie header ===
+  P1 Parse non-RFC2109 cookies using a lenient RFC6256 parser::
+  :: Parse any header not starting with "$Version=1" as a RFC6256 style header and do not
attempt to apply RFC2109 rules. Application impact will be that more consistent parsing with
the way user-agents are generating the header which will mean more cookies to be accepted;
cookie values containing quotes or escape characters may be changed.
+ The lenient parser for V0 cookies will allow:
+  * A cookie name will accept all CHARs up to semicolon or equals. Leading and trailing spaces
will be trimmed. This relaxes RFC6265 to accommodate additional characters browsers can use
in names but does not allow for 8-bit characters in names.
+  * A cookie value will accept all octets up to a semicolon decoded using UTF-8. Leading
and trailing spaces will be trimmed. This relaxes RFC6265 to accommodate HTML5.
+   * '''Issue:''' Any commas added by header folding prior to receipt will be accepted as
part of the previous cookie's value. This is indicative of a mis-behaving proxy or user-agent
and conflicts with browsers that accept commas in values.
+   * '''Issue:''' There is a conflict with Safari (!WebKit?) here in that it does allow semicolons
in values that start/end with DQUOTE. However, the other browsers will truncate the value
at the semicolon when it is being set resulting in a mismatched pair.
+  * Any invalid character will result in the cookie being dropped. Parsing will restart at
the next semicolon.
+  * Any cookie whose name begins with "$" will be dropped to avoid confusion with RFC2109
attributes. RFC6265 and Netscape do not support $Path and $Domain attributes and so any value
they define will not be used to set fields in a Cookie object.
+  * Cookies whose name matches an attribute (e.g. "Expires") will be permitted.
+ This generally matches the rules defined by Netscape and RFC6265 for the Cookie header.
+  P2 Parse RFC2109 requests (determined by the presence of a "$Version=1" attribute) using
the current parser::
+  :: Retains current behaviour if the browser sends a RFC2109 header.
+  :: '''Issue:''' The notes below that shaped this proposal have not be checked against a
browser that actually sends a RFC2109 format header.
+  P3 Do not throw IAE from the parser::
+  :: Invalid syntax will result in a user-data log entry and cookies being dropped rather
than throwing of an IAE. Application impact is that requests with an invalid Cookie header
will now be dispatched to the application.
+ === Impact of proposal on existing issues ===
+ ||<:10%>'''Issue'''||Impact||
+ ||[[|Bug 55917]]||Parsing will no
longer cause an IAE. 8-bit values will be interpreted as a UTF-8 value and the cookie would
be dropped if they are not a valid encoding.||
+ ||[[|Bug 55918]]||The cookie would
be dropped rather than accepted.||
+ ||[[|Bug 55920]]||Valid values would
be round tripped including quotes supplied by the application. Attempts to set invalid values
would result in a IAE from addCookie. Invalid values sent by the browser would result in the
cookie being ignored.||
+ ||[[|Bug 55921]]||Attempts to set
a cookie containing raw JSON would results in an IAE due to the DQUOTE characters. A cookie
sent from the browser containing JSON would be accepted although any semicolons in the data
would result in early termination (note, browsers other than Safari do not allow semicolons
in values anyway).||
  == Parsing the Cookie header by Tomcat ==
  The various specifications define the following formats for the Cookie header sent by the

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message