On 16 March 2017 14:31:31 GMT+00:00, Jim Griswold <jim.grisw...@gmail.com> wrote: >Thanks, Mark! I filed >https://bz.apache.org/bugzilla/show_bug.cgi?id=60876
Thanks. I don't suppose you'd like to try your hand at a patch? Mark > > >Jim > >On Thu, Mar 16, 2017 at 6:15 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 15/03/17 21:56, Jim Griswold wrote: >> > Hi everyone, >> > >> > After a recent upgrade from Tomcat 8.0.28 to 8.5.11, I've noticed a >> syntax >> > change in the Set-Cookie header generated by Tomcat, and I was >hoping to >> > confirm whether this is intentional or if I'm doing something >> incorrectly. >> > >> > The background: >> > >> > After upgrading Tomcat, some automated tests started failing. These >tests >> > use an Apache CXF client to make requests to a service running >inside >> > Tomcat, and then make various assertions on the value of the >Set-Cookie >> > header returned from from the service. >> > >> > The root cause of the failure appears to be a change in the syntax >used >> for >> > the Set-Cookie header which resulted in parsing failures in the >client. >> > >> > The header that's generated by Tomcat 8.0.28 looks like: >> > >> > Set-Cookie: cookie_name=value; Path=/ >> > >> > With 8.5.11, it looks like: >> > >> > Set-Cookie: cookie_name=value;path=/ >> > >> > Note the missing space after the semicolon and the change from >"Path" to >> > "path". After some digging around, I saw that the >> > new Rfc6265CookieProcessor was changed to be the default cookie >> processor. >> > When I followed instructions [1] to change back to the old >processor, the >> > original behavior was restored and my tests pass again. >> > >> > Is this expected behavior? I see that RFC 6265 specifies [2] that >there >> > must be a space between the semicolon and "path", and that it >should be >> > "Path" with the first letter uppercased. Taking a look at the >> > Rfc6265CookieProcessor source code (the generateHeader method, >> > specifically), the lack of space and lower case p appear to be >> intentional, >> > yet don't seem to conform to the RFC the class is targeting. >> > >> > I am sure I must be missing something since this is the new default >and >> > this is such a common behavior, but I've dug around for a while and >can't >> > find another explanation. >> >> Those are implementation bugs. Please raise a Bugzilla issue. The >case >> issue is probably wider than just path. >> >> Reading through the rest of the spec, they both look to be things >> clients should tolerate so you probably want to look at the client >code >> as well. >> >> Kind regards, >> >> Mark >> >> >> > >> > Thanks in advance for your time and help! >> > >> > Jim >> > >> > [1] >> > http://stackoverflow.com/questions/38696081/how-to- >> change-cookie-processor-to-legacycookieprocessor-in-tomcat-8 >> > >> > [2] https://tools.ietf.org/html/rfc6265#section-4.1.1 >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
