You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2024/02/01 16:31:15 UTC
Re: Session Cookie Logging
On 27/01/2024 14:38, Dan McLaughlin wrote:
> Hey Mark,
>
> If you see a bug report, then that will mean I was able to reproduce it. I
> see different behaviors in our local docker environment. Still, it's
> nowhere as complex as our production environment--where everything is
> clustered and behind load balancers, etc... It probably would be easier
> for me to reproduce in our pre-prod environment and attach a debugger to
> see where the / is coming from.
>
> I glanced at the code, and SessionConfig is the only place setting the
> CookiePath to / might happen. Would you agree?
>
> } else {
> // Only handle special case of ROOT context where cookies require a
> // path of '/' but the servlet spec uses an empty string
> if (contextPath.length() == 0) {
> contextPath = "/";
> }
There are other places such as the RewriteValve. I think debugging is
your best option here.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 2/1/24 11:54, Dan McLaughlin wrote:
> I was able to identify the problem - there was a session configuration with
> cookie configuration in the catalina-base/web.xml file.
catalina-base/conf/web.xml?
I did mention on 26 Jan that this wasn't a good idea and could be
causing this kind of problem. Whatever is in the application's
WEB-INF/web.xml file should override the global setting, though. If you
are finding that it's not working that way, please file a bug.
> I just wanted to suggest that it would be great if logging could be enabled
> to show not only what the parameters were set to, but also where the
> values came from. It seems like the sessionCookiePath could be resolved in
> many ways, such as from the filename of the war, context.xml file name, the
> sessionCookiePath, the cookie-config under the web.xml file in the
> catalina-base/conf directory or from the web.xml packaged in the WAR. I
> haven't had a chance to look at the logic in the Apache code, but this
> would be a helpful addition and would have saved a lot of time trying to
> debug where the value came from.
That may be a tall order. There are many many configurations settings
that can come from all over the place with defaults, default-defaults,
and spec-defined defaults. The session cookie path isn't particularly
special in this way... it just happens to be the one configuration
setting you are really really interested in, specifically.
Tracking exactly where a specific configuration setting came from would
likely require a lot of extra code for not much benefit.
-chris
> On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas <ma...@apache.org> wrote:
>
>>
>>
>> On 27/01/2024 14:38, Dan McLaughlin wrote:
>>> Hey Mark,
>>>
>>> If you see a bug report, then that will mean I was able to reproduce
>> it. I
>>> see different behaviors in our local docker environment. Still, it's
>>> nowhere as complex as our production environment--where everything is
>>> clustered and behind load balancers, etc... It probably would be easier
>>> for me to reproduce in our pre-prod environment and attach a debugger to
>>> see where the / is coming from.
>>>
>>> I glanced at the code, and SessionConfig is the only place setting the
>>> CookiePath to / might happen. Would you agree?
>>>
>>> } else {
>>> // Only handle special case of ROOT context where cookies require a
>>> // path of '/' but the servlet spec uses an empty string
>>> if (contextPath.length() == 0) {
>>> contextPath = "/";
>>> }
>>
>> There are other places such as the RewriteValve. I think debugging is
>> your best option here.
>>
>> 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: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
Hey Mark,
I was able to identify the problem - there was a session configuration with
cookie configuration in the catalina-base/web.xml file.
I just wanted to suggest that it would be great if logging could be enabled
to show not only what the parameters were set to, but also where the
values came from. It seems like the sessionCookiePath could be resolved in
many ways, such as from the filename of the war, context.xml file name, the
sessionCookiePath, the cookie-config under the web.xml file in the
catalina-base/conf directory or from the web.xml packaged in the WAR. I
haven't had a chance to look at the logic in the Apache code, but this
would be a helpful addition and would have saved a lot of time trying to
debug where the value came from.
--
Thanks,
Dan
On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas <ma...@apache.org> wrote:
>
>
> On 27/01/2024 14:38, Dan McLaughlin wrote:
> > Hey Mark,
> >
> > If you see a bug report, then that will mean I was able to reproduce
> it. I
> > see different behaviors in our local docker environment. Still, it's
> > nowhere as complex as our production environment--where everything is
> > clustered and behind load balancers, etc... It probably would be easier
> > for me to reproduce in our pre-prod environment and attach a debugger to
> > see where the / is coming from.
> >
> > I glanced at the code, and SessionConfig is the only place setting the
> > CookiePath to / might happen. Would you agree?
> >
> > } else {
> > // Only handle special case of ROOT context where cookies require a
> > // path of '/' but the servlet spec uses an empty string
> > if (contextPath.length() == 0) {
> > contextPath = "/";
> > }
>
> There are other places such as the RewriteValve. I think debugging is
> your best option here.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*NOTICE:* This e-mail message and all attachments transmitted with
it are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is strictly prohibited. The contents of this
e-mail are confidential and may be subject to work product privileges. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.