You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Robert Winch <rw...@gmail.com> on 2016/09/02 21:19:20 UTC
Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
It appears that Tomcat 8.5.4 does not conform to the Servlet 3.1
specification in regards to the Cookie RFC that should be used.
= Servlet 3.1 Specification
Tomcat 8.5.4 states it follows the Servlet 3.1 specification [1].
The Servlet 3.1 Cookie class level Javadoc states [2]:
> This class supports both the Version 0 (by Netscape) and Version 1 (by
RFC 2109) cookie specifications. By default,
> cookies are created using Version 0 to ensure the best interoperability.
The Servlet 3.1 Cookie setVersion(int v) Javadoc states [3]:
> Sets the version of the cookie protocol that this Cookie complies with.
> Version 0 complies with the original Netscape cookie specification.
Version 1 complies with RFC 2109.
> Since RFC 2109 is still somewhat new, consider version 1 as experimental;
do not use it yet on production sites.
= Tomcat Behavior
Given the Javadoc, we should expect that RFC 2109 would be used with the
following code.
Cookie cookie = new Cookie("name","value with spaces");
cookie.setVersion(1);
httpServletResponse.addCookie(cookie);
However, in Tomcat 8.5.4 I receive the following Stacktrace which
demonstrates that RFC 6265 is being used. You can run
the sample code by using the sample project I put together [4].
java.lang.IllegalArgumentException: An invalid character [32] was present
in the Cookie value
org.apache.tomcat.util.http.Rfc6265CookieProcessor.validateCookieValue(Rfc6265CookieProcessor.java:160)
org.apache.tomcat.util.http.Rfc6265CookieProcessor.generateHeader(Rfc6265CookieProcessor.java:109)
org.apache.catalina.connector.Response.generateCookieString(Response.java:989)
org.apache.catalina.connector.Response.addCookie(Response.java:937)
org.apache.catalina.connector.ResponseFacade.addCookie(ResponseFacade.java:386)
sample.CookieServlet.doGet(CookieServlet.java:19)
javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
= Tomcat Documentation
The Tomcat Cookie class level Javadoc appears to contradict the Servlet 3.1
Javadoc [5].
> This class supports both the RFC 2109 and the RFC 6265 specifications. By
default, cookies are created using RFC 6265.
The Tomcat Cookie setVersion(int v) Javadoc seems to agree with the Servlet
3.1 Javadoc [6]:
> Returns the version of the protocol this cookie complies with. Version 1
complies with RFC 2109, and version 0 complies
> with the original cookie specification drafted by Netscape. Cookies
provided by a browser use and identify the browser's
> cookie version.
However, the above stacktrace indicates the behavior does not align with
the Servlet Javadoc nor does it align with the
Tomcat Cookie setVersion method level Javadoc.
= Help
I realize that I can manually configure LegacyCookieProcessor, but this
doesn't seem like any configuration should be necessary
to conform to the Servlet 3.1 specification. Any help sorting this out
would be greatly appreciated!
[1] http://tomcat.apache.org/whichversion.html
[2] https://docs.oracle.com/javaee/7/api/javax/servlet/http/Cookie.html
[3]
https://docs.oracle.com/javaee/7/api/javax/servlet/http/Cookie.html#setVersion-int-
[4] https://github.com/rwinch/tomcat8.5.4-cookie-rfc6265
[5]
https://tomcat.apache.org/tomcat-8.5-doc/servletapi/javax/servlet/http/Cookie.html
[6]
https://tomcat.apache.org/tomcat-8.5-doc/servletapi/javax/servlet/http/Cookie.html#setVersion(int)
Cheers,
Rob
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Rémy Maucherat <re...@apache.org>.
2016-09-06 18:38 GMT+02:00 Robert Winch <rw...@gmail.com>:
> Thank you for your response.
>
You're welcome.
Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Robert,
On 9/6/16 11:05 PM, Robert Winch wrote:
> Mark / R�my,
>
> Thanks again for your responses.
>
> I'd like to point out one more thing. Mark stated:
>
>> To date, the only problem we have seen with RFC6265 that comes to
>> mind is that Tomcat rejects domain values with leading '.' when
>> an application creates a cookie.
>
> The problem I am experiencing is that applications are using a
> cookie value that contains a space. The cookie value was valid
> prior to Tomcat 8.5, but is no longer valid.
>
> This means that an update to Tomcat 8.5 prevents the previous
> cookies from being returned by HttpServletRequest.getCookies(). It
> also means that writing the cookie values is no longer valid.
> Writing the cookies could be adjusted, but reading the cookies
> cannot be fixed because the values are already written.
It's an ugly hack, but you can always read the HTTP header yourself
and interpret the string as you see fit.
Or just use the LegacyCookieParser for a while, and re-write your
application's cookies to be more RFC-friendly.
- -chris
> On Tue, Sep 6, 2016 at 5:13 PM, R�my Maucherat <re...@apache.org>
> wrote:
>
>> 2016-09-06 23:04 GMT+02:00 Mark Thomas <ma...@apache.org>:
>>
>>> I was assuming that Servlet 4.0 would update to RFC6265 so
>>> 9.0.x would be no change. 8.0.x uses the legacy parser by
>>> default so we are only talking about 8.5.x. here.
>>>
>>> The reason I was fine with adding this to
>>> STRICT_SERVLET_COMPLIANCE for 8.5.x was that enabling
>>> STRICT_SERVLET_COMPLIANCE is, unless you are trying to run the
>>> TCK, far more likely to cause problems than fix them. I don't
>>> see it as an option most (all?) real-world users would want to
>>> enable. It is the "Well, we don't recommend it but if you
>>> *really* want specification compliance then here you are."
>>> option. Which seems to be a good fit for this request.
>>>
>>
>> Well, yes, some items got added to the flag that are a bit
>> questionable. I see the very similar URI encoding, which defaults
>> to UTF-8 if it's not used. That's a similar behavior change that
>> can hurt.
>>
>> Now it bundles too many "legacy HTTP" with some "extra Servlet
>> spec behaviors", and that's not the best combo. Ideally the
>> "strict compliance" flag should be limited to actual Servlet spec
>> behaviors.
>>
>>
>>> And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies
>>> then one line in $CATALINA_BASE/conf/context.xml will switch
>>> the default back.
>>>
>>> Is the above enough to move you to a -0 on this?
>>>
>>
>> If people are ok with that new behavior, then that's what it can
>> become.
>>
>>>
>>>> Thanks to you actually, it looks doubtful anyone would have
>>>> tackled a cookie refactoring ...
>>>
>>> Thanks. I must confess that I do still have a small sense of
>>> dread any time a cookie related bug crops up.
>>>
>>>> People who need absolute compatibility can just as easily
>>>> configure another cookie support, but the requirement is
>>>> really illegitimate and counter productive.
>>>
>>> True. The same could be said for all the other defaults changed
>>> by STRICT_SERVLET_COMPLIANCE.
>>>
>>>> I also think the specification language is not intentional,
>>>> it's only a lack of update in the old javadoc basically.
>>>
>>> Indeed but unfortunately we are stuck with the spec language we
>>> have. If EG members could actually fix stuff like this directly
>>> rather than having to convince the Oracle spec lead to make the
>>> change...
>>>
>>> https://java.net/jira/browse/SERVLET_SPEC-37
>>>
>>> I didn't pay a lot of attention to it then, and it doesn't seem
>>> to be
>> getting fixed.
>>
>> R�my
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJX0X0cAAoJEBzwKT+lPKRYvDwP/iX4ZuCtJXxDRm+cYG9Ot3jg
tKnnrIe8FHnHB8pzRKNWnVsb2CFn/FaqOPqeHZ8+nlE38sM7zKzTZJoo3PKBz7eZ
dD4BvHMP0p2dobXmn8bUOtfRc9xxXQ1xC3SmdXQeEynmKkXzfAq9OO+f8a4unlT1
gSEqTBddnPnwWMm+OsKm7tgAfn6O2D4bVvDNC+GRHH7+CSfBF+dxvR6qmRqz9B26
vA2Q/qXEv0VHWKP0+fu5X91x18gqDzXWBluR6zATVwZUa23WjGHwxIKGQ/rne1GE
15Yp5ucghV9ip8IoAthMq7DLcby5WIwGLvTGtN06cemD1U6wXbhWwdRxri+AP6T1
GOQM+aL7VIZD2KFr5rMSXHuPHBSvjaFfodhSALnh9tJtt33PGJ/eiSpYKJA5lKw3
8PV/Z+2kJlpuXmQwJ82OiQLfUgjCrEhibUFxiXphrJ/KOhIoBC7fWFih9OLoD+4S
jGS7vT/uLZGmF59t3sL6Wu2C/Ew4tgaeeUazrVaHyjqiVftiBAeMR6el844l64Tj
Wh2lXtfnpDskWoRbkseem+tiMK7j431vfialh6EbhPxCaLZUo50zHdD9X2Tw009A
PdQH3mUT79Fwj8CREwOLYVH3UeGg414e+UdImQVKnl0Epc8fpQqi0G3+QOXKD+p7
/p12dXhJu1Z2zefdMirx
=b14o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Robert Winch <rw...@gmail.com>.
Mark / Rémy,
Thanks again for your responses.
I'd like to point out one more thing. Mark stated:
> To date, the only problem we have seen with RFC6265 that comes to mind
> is that Tomcat rejects domain values with leading '.' when an
> application creates a cookie.
The problem I am experiencing is that applications are using a cookie value
that contains a space. The cookie value was valid prior to Tomcat 8.5, but
is no longer valid.
This means that an update to Tomcat 8.5 prevents the previous cookies from
being returned by HttpServletRequest.getCookies(). It also means that
writing the cookie values is no longer valid. Writing the cookies could be
adjusted, but reading the cookies cannot be fixed because the values are
already written.
Regards,
Rob
On Tue, Sep 6, 2016 at 5:13 PM, Rémy Maucherat <re...@apache.org> wrote:
> 2016-09-06 23:04 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> > I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would
> > be no change. 8.0.x uses the legacy parser by default so we are only
> > talking about 8.5.x. here.
> >
> > The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for
> > 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are
> > trying to run the TCK, far more likely to cause problems than fix them.
> > I don't see it as an option most (all?) real-world users would want to
> > enable. It is the "Well, we don't recommend it but if you *really* want
> > specification compliance then here you are." option. Which seems to be a
> > good fit for this request.
> >
>
> Well, yes, some items got added to the flag that are a bit questionable. I
> see the very similar URI encoding, which defaults to UTF-8 if it's not
> used. That's a similar behavior change that can hurt.
>
> Now it bundles too many "legacy HTTP" with some "extra Servlet spec
> behaviors", and that's not the best combo. Ideally the "strict compliance"
> flag should be limited to actual Servlet spec behaviors.
>
>
> > And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one
> > line in $CATALINA_BASE/conf/context.xml will switch the default back.
> >
> > Is the above enough to move you to a -0 on this?
> >
>
> If people are ok with that new behavior, then that's what it can become.
>
> >
> > > Thanks to
> > > you actually, it looks doubtful anyone would have tackled a cookie
> > > refactoring ...
> >
> > Thanks. I must confess that I do still have a small sense of dread any
> > time a cookie related bug crops up.
> >
> > > People who need absolute compatibility can just as easily
> > > configure another cookie support, but the requirement is really
> > > illegitimate and counter productive.
> >
> > True. The same could be said for all the other defaults changed by
> > STRICT_SERVLET_COMPLIANCE.
> >
> > > I also think the specification language is not intentional, it's only a
> > > lack of update in the old javadoc basically.
> >
> > Indeed but unfortunately we are stuck with the spec language we have. If
> > EG members could actually fix stuff like this directly rather than
> > having to convince the Oracle spec lead to make the change...
> >
> > https://java.net/jira/browse/SERVLET_SPEC-37
> >
> > I didn't pay a lot of attention to it then, and it doesn't seem to be
> getting fixed.
>
> Rémy
>
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Rémy Maucherat <re...@apache.org>.
2016-09-06 23:04 GMT+02:00 Mark Thomas <ma...@apache.org>:
> I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would
> be no change. 8.0.x uses the legacy parser by default so we are only
> talking about 8.5.x. here.
>
> The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for
> 8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are
> trying to run the TCK, far more likely to cause problems than fix them.
> I don't see it as an option most (all?) real-world users would want to
> enable. It is the "Well, we don't recommend it but if you *really* want
> specification compliance then here you are." option. Which seems to be a
> good fit for this request.
>
Well, yes, some items got added to the flag that are a bit questionable. I
see the very similar URI encoding, which defaults to UTF-8 if it's not
used. That's a similar behavior change that can hurt.
Now it bundles too many "legacy HTTP" with some "extra Servlet spec
behaviors", and that's not the best combo. Ideally the "strict compliance"
flag should be limited to actual Servlet spec behaviors.
> And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one
> line in $CATALINA_BASE/conf/context.xml will switch the default back.
>
> Is the above enough to move you to a -0 on this?
>
If people are ok with that new behavior, then that's what it can become.
>
> > Thanks to
> > you actually, it looks doubtful anyone would have tackled a cookie
> > refactoring ...
>
> Thanks. I must confess that I do still have a small sense of dread any
> time a cookie related bug crops up.
>
> > People who need absolute compatibility can just as easily
> > configure another cookie support, but the requirement is really
> > illegitimate and counter productive.
>
> True. The same could be said for all the other defaults changed by
> STRICT_SERVLET_COMPLIANCE.
>
> > I also think the specification language is not intentional, it's only a
> > lack of update in the old javadoc basically.
>
> Indeed but unfortunately we are stuck with the spec language we have. If
> EG members could actually fix stuff like this directly rather than
> having to convince the Oracle spec lead to make the change...
>
> https://java.net/jira/browse/SERVLET_SPEC-37
>
> I didn't pay a lot of attention to it then, and it doesn't seem to be
getting fixed.
Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Mark Thomas <ma...@apache.org>.
On 06/09/2016 21:29, R�my Maucherat wrote:
> 2016-09-06 19:11 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
>> This looks like something that is a good fit for
>> STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change
>> the default CookieProcessor to LegacyCookieProcessor.
>>
> I think I'm -1 for using the strict compliance flag for that. It's too big
> a behavior change, and the current situation is far more robust.
I was assuming that Servlet 4.0 would update to RFC6265 so 9.0.x would
be no change. 8.0.x uses the legacy parser by default so we are only
talking about 8.5.x. here.
The reason I was fine with adding this to STRICT_SERVLET_COMPLIANCE for
8.5.x was that enabling STRICT_SERVLET_COMPLIANCE is, unless you are
trying to run the TCK, far more likely to cause problems than fix them.
I don't see it as an option most (all?) real-world users would want to
enable. It is the "Well, we don't recommend it but if you *really* want
specification compliance then here you are." option. Which seems to be a
good fit for this request.
And if users want STRICT_SERVLET_COMPLIANCE but RFC6265 cookies then one
line in $CATALINA_BASE/conf/context.xml will switch the default back.
Is the above enough to move you to a -0 on this?
> Thanks to
> you actually, it looks doubtful anyone would have tackled a cookie
> refactoring ...
Thanks. I must confess that I do still have a small sense of dread any
time a cookie related bug crops up.
> People who need absolute compatibility can just as easily
> configure another cookie support, but the requirement is really
> illegitimate and counter productive.
True. The same could be said for all the other defaults changed by
STRICT_SERVLET_COMPLIANCE.
> I also think the specification language is not intentional, it's only a
> lack of update in the old javadoc basically.
Indeed but unfortunately we are stuck with the spec language we have. If
EG members could actually fix stuff like this directly rather than
having to convince the Oracle spec lead to make the change...
https://java.net/jira/browse/SERVLET_SPEC-37
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Rémy Maucherat <re...@apache.org>.
2016-09-06 19:11 GMT+02:00 Mark Thomas <ma...@apache.org>:
> This looks like something that is a good fit for
> STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change
> the default CookieProcessor to LegacyCookieProcessor.
>
> I think I'm -1 for using the strict compliance flag for that. It's too big
a behavior change, and the current situation is far more robust. Thanks to
you actually, it looks doubtful anyone would have tackled a cookie
refactoring ... People who need absolute compatibility can just as easily
configure another cookie support, but the requirement is really
illegitimate and counter productive.
I also think the specification language is not intentional, it's only a
lack of update in the old javadoc basically.
Rémy
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Mark Thomas <ma...@apache.org>.
On 06/09/2016 20:57, Robert Winch wrote:
> Mark,
>
> Thanks again for your detailed response.
>
> In addition to the STRICT_SERVLET_COMPLIANCE flag, would you consider
> supporting the older RFC if a cookie version was explicitly set on the
> Cookie?
If applications want to explicitly send version 1 cookies then they'll
need to configure the LegacyCookieProcessor.
Given that RFC6265 essentially documents the current browser behaviour
and also that RFC6265 says clients should ignore the version attribute
I'd be surprised if any but a tiny minority of applications actually
needed to send the version attribute. I guess if someone has written a
custom client that actually implements RFC2109 they'd need this but it
is going to be that unusual.
Mark
>
> Cheers,
> Rob
>
> On Tue, Sep 6, 2016 at 1:21 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 06/09/2016 19:02, Robert Winch wrote:
>>> Mark,
>>>
>>> Thank you for the detailed response.
>>>
>>> I'm looking to assess the full impact of applications that might choose
>> to
>>> use LegacyCookieProcessor. Can you elaborate on why using
>>> LegacyCookieProcessor is a bad idea?
>>
>> It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the
>> current reality as well as the RFC6265 processor.
>>
>> As an aside, the Servlet spec implies strict adherence to RFC2109. That
>> would be fairly messy. From memory, it breaks interoperability with
>> Google and IE, as well as a bunch of other issues.
>>
>> Rfc6262CookieProcessor is better because:
>> - it is a much closer match to how browsers actually behave
>> - it handles UTF-8 (this is actually a deviation from RFC6265)
>>
>> To quote from the intro of RFC6265:
>> <quote>
>> Prior to this document, there were at least three descriptions of
>> cookies: the so-called "Netscape cookie specification" [Netscape],
>> RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
>> documents describe how the Cookie and Set-Cookie headers are actually
>> used on the Internet (see [Kri2001] for historical context).
>> </quote>
>>
>> The potential downside is that Tomcat is strict in what it allows
>> applications to send. If applications don't adhere to RFC6265 then they
>> will see exceptions around cookie handling.
>>
>>> Are you aware of other containers that also use RFC6265?
>>
>> I haven't undertaken any sort of survey.
>>
>> To date, the only problem we have seen with RFC6265 that comes to mind
>> is that Tomcat rejects domain values with leading '.' when an
>> application creates a cookie. We could be lenient here but that goes
>> against our general philosophy of not adding workarounds for bad
>> application behaviour expect in exception circumstances (and this isn't
>> close to this point so far).
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Robert Winch <rw...@gmail.com>.
Mark,
Thanks again for your detailed response.
In addition to the STRICT_SERVLET_COMPLIANCE flag, would you consider
supporting the older RFC if a cookie version was explicitly set on the
Cookie?
Cheers,
Rob
On Tue, Sep 6, 2016 at 1:21 PM, Mark Thomas <ma...@apache.org> wrote:
> On 06/09/2016 19:02, Robert Winch wrote:
> > Mark,
> >
> > Thank you for the detailed response.
> >
> > I'm looking to assess the full impact of applications that might choose
> to
> > use LegacyCookieProcessor. Can you elaborate on why using
> > LegacyCookieProcessor is a bad idea?
>
> It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the
> current reality as well as the RFC6265 processor.
>
> As an aside, the Servlet spec implies strict adherence to RFC2109. That
> would be fairly messy. From memory, it breaks interoperability with
> Google and IE, as well as a bunch of other issues.
>
> Rfc6262CookieProcessor is better because:
> - it is a much closer match to how browsers actually behave
> - it handles UTF-8 (this is actually a deviation from RFC6265)
>
> To quote from the intro of RFC6265:
> <quote>
> Prior to this document, there were at least three descriptions of
> cookies: the so-called "Netscape cookie specification" [Netscape],
> RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
> documents describe how the Cookie and Set-Cookie headers are actually
> used on the Internet (see [Kri2001] for historical context).
> </quote>
>
> The potential downside is that Tomcat is strict in what it allows
> applications to send. If applications don't adhere to RFC6265 then they
> will see exceptions around cookie handling.
>
> > Are you aware of other containers that also use RFC6265?
>
> I haven't undertaken any sort of survey.
>
> To date, the only problem we have seen with RFC6265 that comes to mind
> is that Tomcat rejects domain values with leading '.' when an
> application creates a cookie. We could be lenient here but that goes
> against our general philosophy of not adding workarounds for bad
> application behaviour expect in exception circumstances (and this isn't
> close to this point so far).
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Mark Thomas <ma...@apache.org>.
On 06/09/2016 19:02, Robert Winch wrote:
> Mark,
>
> Thank you for the detailed response.
>
> I'm looking to assess the full impact of applications that might choose to
> use LegacyCookieProcessor. Can you elaborate on why using
> LegacyCookieProcessor is a bad idea?
It isn't that LegacyCookieProcessor is bad, it just doesn't reflect the
current reality as well as the RFC6265 processor.
As an aside, the Servlet spec implies strict adherence to RFC2109. That
would be fairly messy. From memory, it breaks interoperability with
Google and IE, as well as a bunch of other issues.
Rfc6262CookieProcessor is better because:
- it is a much closer match to how browsers actually behave
- it handles UTF-8 (this is actually a deviation from RFC6265)
To quote from the intro of RFC6265:
<quote>
Prior to this document, there were at least three descriptions of
cookies: the so-called "Netscape cookie specification" [Netscape],
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
documents describe how the Cookie and Set-Cookie headers are actually
used on the Internet (see [Kri2001] for historical context).
</quote>
The potential downside is that Tomcat is strict in what it allows
applications to send. If applications don't adhere to RFC6265 then they
will see exceptions around cookie handling.
> Are you aware of other containers that also use RFC6265?
I haven't undertaken any sort of survey.
To date, the only problem we have seen with RFC6265 that comes to mind
is that Tomcat rejects domain values with leading '.' when an
application creates a cookie. We could be lenient here but that goes
against our general philosophy of not adding workarounds for bad
application behaviour expect in exception circumstances (and this isn't
close to this point so far).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Robert Winch <rw...@gmail.com>.
Mark,
Thank you for the detailed response.
I'm looking to assess the full impact of applications that might choose to
use LegacyCookieProcessor. Can you elaborate on why using
LegacyCookieProcessor is a bad idea?
Are you aware of other containers that also use RFC6265?
Thanks,
Rob
On Tue, Sep 6, 2016 at 12:17 PM, Mark Thomas <ma...@apache.org> wrote:
> On 06/09/2016 18:11, Mark Thomas wrote:
> > On 06/09/2016 17:38, Robert Winch wrote:
> >> Thank you for your response.
> >>
> >> I don't see how the Tomcat documentation can be fixed unless the
> Tomcat's
> >> Servlet APIs are going to deviate from the Servlet 3.1 specification. If
> >> Tomcat continues to deviate from the specification, I don't see how
> Tomcat
> >> 8.5 can claim Servlet 3.1 compliance.
> >
> > There are numerous places where Tomcat deviates from the the Servlet
> > spec by default for various reasons including, amongst others,
> > performance, standard practise and plain common sense.
> >
> > Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you
> > really want to stick to the letter of the Servlet spec. Back when we
> > had access to a current TCK, it was required to be set to pass the TCK.
> >
> >> Do you see a way to get the Tomcat cookie implementation to align with
> the
> >> Servlet 3.1 API specification? Can you elaborate on why Tomcat has
> decided
> >> to deviate from the specification in this respect? Is there a reason we
> >> cannot fix the behavior (especially if the cookie version is explicitly
> >> set)?
> >
> > This looks like something that is a good fit for
> > STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change
> > the default CookieProcessor to LegacyCookieProcessor.
> >
> > As to why the default is RFC6265, neither browsers nor servers
> > implemented them fully and/or correctly.
>
> Them being the previous cookie specs.
>
> > Tomcat discovered this the hard
> > way several years ago when we tightened up the cookie parsing code to
> > follow the specs as a result of some security issues. The majority of
> > apps promptly broke.
> >
> > Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Mark Thomas <ma...@apache.org>.
On 06/09/2016 18:11, Mark Thomas wrote:
> On 06/09/2016 17:38, Robert Winch wrote:
>> Thank you for your response.
>>
>> I don't see how the Tomcat documentation can be fixed unless the Tomcat's
>> Servlet APIs are going to deviate from the Servlet 3.1 specification. If
>> Tomcat continues to deviate from the specification, I don't see how Tomcat
>> 8.5 can claim Servlet 3.1 compliance.
>
> There are numerous places where Tomcat deviates from the the Servlet
> spec by default for various reasons including, amongst others,
> performance, standard practise and plain common sense.
>
> Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you
> really want to stick to the letter of the Servlet spec. Back when we
> had access to a current TCK, it was required to be set to pass the TCK.
>
>> Do you see a way to get the Tomcat cookie implementation to align with the
>> Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided
>> to deviate from the specification in this respect? Is there a reason we
>> cannot fix the behavior (especially if the cookie version is explicitly
>> set)?
>
> This looks like something that is a good fit for
> STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change
> the default CookieProcessor to LegacyCookieProcessor.
>
> As to why the default is RFC6265, neither browsers nor servers
> implemented them fully and/or correctly.
Them being the previous cookie specs.
> Tomcat discovered this the hard
> way several years ago when we tightened up the cookie parsing code to
> follow the specs as a result of some security issues. The majority of
> apps promptly broke.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Mark Thomas <ma...@apache.org>.
On 06/09/2016 17:38, Robert Winch wrote:
> Thank you for your response.
>
> I don't see how the Tomcat documentation can be fixed unless the Tomcat's
> Servlet APIs are going to deviate from the Servlet 3.1 specification. If
> Tomcat continues to deviate from the specification, I don't see how Tomcat
> 8.5 can claim Servlet 3.1 compliance.
There are numerous places where Tomcat deviates from the the Servlet
spec by default for various reasons including, amongst others,
performance, standard practise and plain common sense.
Generally, the STRICT_SERVLET_COMPLIANCE system property is used if you
really want to stick to the letter of the Servlet spec. Back when we
had access to a current TCK, it was required to be set to pass the TCK.
> Do you see a way to get the Tomcat cookie implementation to align with the
> Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided
> to deviate from the specification in this respect? Is there a reason we
> cannot fix the behavior (especially if the cookie version is explicitly
> set)?
This looks like something that is a good fit for
STRICT_SERVLET_COMPLIANCE. My current thinking is if this is set, change
the default CookieProcessor to LegacyCookieProcessor.
As to why the default is RFC6265, neither browsers nor servers
implemented them fully and/or correctly. Tomcat discovered this the hard
way several years ago when we tightened up the cookie parsing code to
follow the specs as a result of some security issues. The majority of
apps promptly broke.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Robert Winch <rw...@gmail.com>.
Thank you for your response.
I don't see how the Tomcat documentation can be fixed unless the Tomcat's
Servlet APIs are going to deviate from the Servlet 3.1 specification. If
Tomcat continues to deviate from the specification, I don't see how Tomcat
8.5 can claim Servlet 3.1 compliance.
Do you see a way to get the Tomcat cookie implementation to align with the
Servlet 3.1 API specification? Can you elaborate on why Tomcat has decided
to deviate from the specification in this respect? Is there a reason we
cannot fix the behavior (especially if the cookie version is explicitly
set)?
Thanks!
Rob
On Fri, Sep 2, 2016 at 4:46 PM, Rémy Maucherat <re...@apache.org> wrote:
> 2016-09-02 23:19 GMT+02:00 Robert Winch <rw...@gmail.com>:
>
> > I realize that I can manually configure LegacyCookieProcessor
> >
> > Yes, you'll have to configure the legacy cookie processor to support the
> less formal former cookie RFCs, this is as expected. If you find any
> discrepancies about that in the Tomcat documentation, you may file a bug.
> The default will remain to use the current cookie RFC.
>
> Rémy
>
Re: Tomcat 8.5.4 uses RFC 6265 by default which does not appear to be
Servlet 3.1 compliant
Posted by Rémy Maucherat <re...@apache.org>.
2016-09-02 23:19 GMT+02:00 Robert Winch <rw...@gmail.com>:
> I realize that I can manually configure LegacyCookieProcessor
>
> Yes, you'll have to configure the legacy cookie processor to support the
less formal former cookie RFCs, this is as expected. If you find any
discrepancies about that in the Tomcat documentation, you may file a bug.
The default will remain to use the current cookie RFC.
Rémy