-----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 <r...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
