Re: Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

Chris - The header logging is a good idea. We'll add that. In the meantime,
it looks like it might have been premature to indicate that "the problem
persists with HTTP/1.1". The one instance that I found was a red herring,
so to date the problem has *not* recurred since addressing the HTTP/1.0
issue.

In re: our web server and Wireshark. We have an nginx instance sitting on a
separate (web server) machine. The Wireshark was the app server, so it was
capturing the traffic from nginx to Tomcat.

At any rate, I will be sure to keep you apprised as to the status.
Hopefully the HTTP/1.1 fix addresses the problem...

Chad

On Wed, Feb 28, 2018 at 8:17 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chad,
>
> On 2/27/18 9:02 PM, Chad Stansbury wrote:
> > Thanks for your response. Unfortunately it doesn't appear to be a
> > bad cookie name or value, as the identical set of cookies are
> > passed (and parsed correctly) on requests that immediately precede
> > and follow the failing request. That's pretty clear from both the
> > Wireshark and Tomcat access logs we have. What we're seeing is that
> > the client (which is a browser, usually Chrome) sends a burst of
> > requests, and occasionally one of those requests will fail as the
> > web app detects that is has no cookies even though the Wireshark
> > indicates that there are.  We even added logging to the
> > AccessLogValve to log the cookies that we're looking for, and it
> > yields an empty value... So we know that the cookie parsing is
> > either failing or the cookies get cleared following parsing, but
> > before being passed on to the AccessLogValve.
>
> Sounds like you have it at least semi-reproducible. That's great news.
>
> What about logging both the results of request.getCookies() as well as
> request.getHeader("Cookie")? If the parsing is failing, you will get
> no Cookie objects from request.getCookie(), but you should still get
> the header back from the request.
>
> If there is no header in the request... well, then maybe something is
> wrong elsewhere with the request, and Tomcat never gets to the Cookie
> header at all.
>
> > Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that
> > the problem persists even with HTTP/1.1. The one thing that I
> > failed to mention on the original note is that we're running Tomcat
> > on a Windows server. So I'm not sure if that has anything to do
> > with the issue that we're seeing or not...
>
> I wouldn't expect Windows to have anything to do with it, same for
> HTTP/1.0 versus HTTP/1.1... headers haven't changed much across HTTP
> versions, and Tomcat treats those headers the same regardless of the
> advertised version of the protocol. The biggest difference between
> HTTP/1.0 and HTTP/1.1 is that HTTP/1.1 has a few required headers.
>
> > That being said, I will double-check the catalina.out to see if we
> > can find any cookie parsing related errors.
>
> That would be good. Again, it will probably only be logged a single
> time, not every time. But if you have the opportunity to bounce Tomcat
> and hit it with a load that will likely cause an error to occur, you
> ought to be able to catch an error message -- if indeed Cookie-parsing
> is the problem. Or, if request-parsing is the problem, too.
>
> One more question: are you using a reverse-proxy like httpd out in
> front? Exactly where are you sampling with Wireshark?
>
> - -chris
>
> > On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Chad,
> >
> > On 2/27/18 9:44 AM, Chad Stansbury wrote:
>  We've been troubleshooting an issue where our web application
>  is getting a very occasional request that contains no cookies
>  even though a Wireshark on the application server shows those
>  cookies coming in on the request.
> 
>  I was able to replay the request that was captured via
>  Wireshark, and when doing so, everything goes through just
>  fine... so that rules out any sort of weird character set /
>  header parsing issues.
> 
>  Environment specifics: Tomcat v7.0.77 running the (http-bio)
>  connector
> 
>  Now here's the twist: Currently something in the site
>  infrastructure has been configured to proxy to Tomcat with
>  HTTP/1.0 instead of 1.1. We're trying to track that down and
>  address that issue (for performance reasons), but in the mean
>  time, we're wondering whether or not this is a concurrency
>  issue related to protocol caching/recycling?
> 
>  Has anyone ever seen anything like this before? Is there any
>  legitimate scenario(s) where Tomcat will *not* parse out the
>  cookies, but still route the request to the web app? Is this
>  possible an edge condition that that might be caused by the
>  use of HTTP/1.0? Could this possibly be caused by the number
>  of maxThreads exceeding the 

Re: Tomcat 7 - Sporadic problem re: cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chad,

On 2/27/18 9:02 PM, Chad Stansbury wrote:
> Thanks for your response. Unfortunately it doesn't appear to be a
> bad cookie name or value, as the identical set of cookies are
> passed (and parsed correctly) on requests that immediately precede
> and follow the failing request. That's pretty clear from both the
> Wireshark and Tomcat access logs we have. What we're seeing is that
> the client (which is a browser, usually Chrome) sends a burst of
> requests, and occasionally one of those requests will fail as the
> web app detects that is has no cookies even though the Wireshark
> indicates that there are.  We even added logging to the
> AccessLogValve to log the cookies that we're looking for, and it
> yields an empty value... So we know that the cookie parsing is
> either failing or the cookies get cleared following parsing, but
> before being passed on to the AccessLogValve.

Sounds like you have it at least semi-reproducible. That's great news.

What about logging both the results of request.getCookies() as well as
request.getHeader("Cookie")? If the parsing is failing, you will get
no Cookie objects from request.getCookie(), but you should still get
the header back from the request.

If there is no header in the request... well, then maybe something is
wrong elsewhere with the request, and Tomcat never gets to the Cookie
header at all.

> Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that
> the problem persists even with HTTP/1.1. The one thing that I
> failed to mention on the original note is that we're running Tomcat
> on a Windows server. So I'm not sure if that has anything to do
> with the issue that we're seeing or not...

I wouldn't expect Windows to have anything to do with it, same for
HTTP/1.0 versus HTTP/1.1... headers haven't changed much across HTTP
versions, and Tomcat treats those headers the same regardless of the
advertised version of the protocol. The biggest difference between
HTTP/1.0 and HTTP/1.1 is that HTTP/1.1 has a few required headers.

> That being said, I will double-check the catalina.out to see if we
> can find any cookie parsing related errors.

That would be good. Again, it will probably only be logged a single
time, not every time. But if you have the opportunity to bounce Tomcat
and hit it with a load that will likely cause an error to occur, you
ought to be able to catch an error message -- if indeed Cookie-parsing
is the problem. Or, if request-parsing is the problem, too.

One more question: are you using a reverse-proxy like httpd out in
front? Exactly where are you sampling with Wireshark?

- -chris

> On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Chad,
> 
> On 2/27/18 9:44 AM, Chad Stansbury wrote:
 We've been troubleshooting an issue where our web application
 is getting a very occasional request that contains no cookies
 even though a Wireshark on the application server shows those
 cookies coming in on the request.
 
 I was able to replay the request that was captured via
 Wireshark, and when doing so, everything goes through just
 fine... so that rules out any sort of weird character set /
 header parsing issues.
 
 Environment specifics: Tomcat v7.0.77 running the (http-bio) 
 connector
 
 Now here's the twist: Currently something in the site 
 infrastructure has been configured to proxy to Tomcat with
 HTTP/1.0 instead of 1.1. We're trying to track that down and
 address that issue (for performance reasons), but in the mean
 time, we're wondering whether or not this is a concurrency
 issue related to protocol caching/recycling?
 
 Has anyone ever seen anything like this before? Is there any 
 legitimate scenario(s) where Tomcat will *not* parse out the 
 cookies, but still route the request to the web app? Is this 
 possible an edge condition that that might be caused by the
 use of HTTP/1.0? Could this possibly be caused by the number
 of maxThreads exceeding the `processorCache` value?
> 
> My immediate thought is that the cookie name or value contains a 
> character that causes parsing to fail within Tomcat. Do you have
> any information about which cookies appear to be being ignored by
> Tomcat (that is, not passed-on to the application) versus those
> that ARE available to the application?
> 
> Tomcat will generally log cookie-parsing errors to catalina.log,
> and possibly to the application's log as well, but it may only do
> so once per Tomcat-launch to avoid filling the disk with logs. Are
> you seeing anything in the Tomcat logs which suggest that
> cookie-parsing is failing ?
> 
> Is the client a browser, or some non-human-interface device, such
> as a client-library or something like that?
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: 

Re: Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

Hello Chris -

Thanks for your response. Unfortunately it doesn't appear to be a bad
cookie name or value, as the identical set of cookies are passed (and
parsed correctly) on requests that immediately precede and follow the
failing request. That's pretty clear from both the Wireshark and Tomcat
access logs we have. What we're seeing is that the client (which is a
browser, usually Chrome) sends a burst of requests, and occasionally one of
those requests will fail as the web app detects that is has no cookies even
though the Wireshark indicates that there are.  We even added logging to
the AccessLogValve to log the cookies that we're looking for, and it yields
an empty value... So we know that the cookie parsing is either failing or
the cookies get cleared following parsing, but before being passed on to
the AccessLogValve.

Also, as a follow-up, we corrected the HTTP/1.0 issue, and see that the
problem persists even with HTTP/1.1. The one thing that I failed to mention
on the original note is that we're running Tomcat on a Windows server. So
I'm not sure if that has anything to do with the issue that we're seeing or
not...

That being said, I will double-check the catalina.out to see if we can find
any cookie parsing related errors.

Thanks, Chad

On Tue, Feb 27, 2018 at 3:13 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chad,
>
> On 2/27/18 9:44 AM, Chad Stansbury wrote:
> > We've been troubleshooting an issue where our web application is
> > getting a very occasional request that contains no cookies even
> > though a Wireshark on the application server shows those cookies
> > coming in on the request.
> >
> > I was able to replay the request that was captured via Wireshark,
> > and when doing so, everything goes through just fine... so that
> > rules out any sort of weird character set / header parsing issues.
> >
> > Environment specifics: Tomcat v7.0.77 running the (http-bio)
> > connector
> >
> > Now here's the twist: Currently something in the site
> > infrastructure has been configured to proxy to Tomcat with HTTP/1.0
> > instead of 1.1. We're trying to track that down and address that
> > issue (for performance reasons), but in the mean time, we're
> > wondering whether or not this is a concurrency issue related to
> > protocol caching/recycling?
> >
> > Has anyone ever seen anything like this before? Is there any
> > legitimate scenario(s) where Tomcat will *not* parse out the
> > cookies, but still route the request to the web app? Is this
> > possible an edge condition that that might be caused by the use of
> > HTTP/1.0? Could this possibly be caused by the number of maxThreads
> > exceeding the `processorCache` value?
>
> My immediate thought is that the cookie name or value contains a
> character that causes parsing to fail within Tomcat. Do you have any
> information about which cookies appear to be being ignored by Tomcat
> (that is, not passed-on to the application) versus those that ARE
> available to the application?
>
> Tomcat will generally log cookie-parsing errors to catalina.log, and
> possibly to the application's log as well, but it may only do so once
> per Tomcat-launch to avoid filling the disk with logs. Are you seeing
> anything in the Tomcat logs which suggest that cookie-parsing is failing
> ?
>
> Is the client a browser, or some non-human-interface device, such as a
> client-library or something like that?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVyfIACgkQHPApP6U8
> pFhh3BAAgq6+/VHzI6732NX6To6OVTvIwXw/8OB2A/jDLNwFgWfNrci/KmtSsH0w
> acYcA0D08WBsS8bHD+dHUQ2qvY+0ccyIVGCbyMpZk+du/4bsghpb3PIszSZ+Nsbm
> JNuYxeBVfNRxD2DIDT4+98N20rs5t1zX7mCyWzRT1OU31DRFgmfxkF6I0PTdTRSv
> gPzolgEtszgT7wePifE2tcn1/9J47MstEs6QGMOm9t/Q8naGMCI4DEumMeJZzH4L
> BmTXHVL69RTw8NWJ2Rhqy8jhF1ZLazl4ASE59nfXrCHa/EwNkZ6BaVS0pvqJlkQB
> fTZNvbFpx7m0NOaxGzS5m2KCKFtH1R279RnMHRHovy0ljAr4hlW26APlUhlJsYe7
> QMcm0/lyIZQd27pHhjoRzu9N5J01YotZ3rJLMzeBDI4vh1caRFtVAdyTHOdqdr+9
> 95WTTmtVRlcf7iq+9xdgIyPPCiFkdUOKFS0dc7V794yJjqOfW7ToJsEe/hZlCj5H
> 4yJGhJye3dH9rEzEgTPiIQb+mVYG9y5fJXK7XZ25pnvHNZ8+HheHXEUQdTWgW8ZI
> uHa6eitXXd0lp2xNUN2Itt58Isqn1U4cC7DsPZsH+eVSxIBrIUtx2YVDrwx7yywn
> 8K12ByKlxB7bpfBsMvmdhcZYuTp/y8q7W259117ZmCahhSwMm0k=
> =jwba
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*Chad Stansbury*
Principal Engineer | D3 Banking Technology
11837 Miracle Hills Drive Suite 102 | Omaha, NE | 68154
(o)

www.D3Banking.com 

NOTICE: This electronic mail message and any files transmitted with it are
intended exclusively for the individual or entity to which it is addressed.
The 

Re: Tomcat 7 - Sporadic problem re: cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chad,

On 2/27/18 9:44 AM, Chad Stansbury wrote:
> We've been troubleshooting an issue where our web application is
> getting a very occasional request that contains no cookies even
> though a Wireshark on the application server shows those cookies
> coming in on the request.
> 
> I was able to replay the request that was captured via Wireshark,
> and when doing so, everything goes through just fine... so that
> rules out any sort of weird character set / header parsing issues.
> 
> Environment specifics: Tomcat v7.0.77 running the (http-bio)
> connector
> 
> Now here's the twist: Currently something in the site
> infrastructure has been configured to proxy to Tomcat with HTTP/1.0
> instead of 1.1. We're trying to track that down and address that
> issue (for performance reasons), but in the mean time, we're
> wondering whether or not this is a concurrency issue related to
> protocol caching/recycling?
> 
> Has anyone ever seen anything like this before? Is there any
> legitimate scenario(s) where Tomcat will *not* parse out the
> cookies, but still route the request to the web app? Is this
> possible an edge condition that that might be caused by the use of
> HTTP/1.0? Could this possibly be caused by the number of maxThreads
> exceeding the `processorCache` value?

My immediate thought is that the cookie name or value contains a
character that causes parsing to fail within Tomcat. Do you have any
information about which cookies appear to be being ignored by Tomcat
(that is, not passed-on to the application) versus those that ARE
available to the application?

Tomcat will generally log cookie-parsing errors to catalina.log, and
possibly to the application's log as well, but it may only do so once
per Tomcat-launch to avoid filling the disk with logs. Are you seeing
anything in the Tomcat logs which suggest that cookie-parsing is failing
?

Is the client a browser, or some non-human-interface device, such as a
client-library or something like that?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqVyfIACgkQHPApP6U8
pFhh3BAAgq6+/VHzI6732NX6To6OVTvIwXw/8OB2A/jDLNwFgWfNrci/KmtSsH0w
acYcA0D08WBsS8bHD+dHUQ2qvY+0ccyIVGCbyMpZk+du/4bsghpb3PIszSZ+Nsbm
JNuYxeBVfNRxD2DIDT4+98N20rs5t1zX7mCyWzRT1OU31DRFgmfxkF6I0PTdTRSv
gPzolgEtszgT7wePifE2tcn1/9J47MstEs6QGMOm9t/Q8naGMCI4DEumMeJZzH4L
BmTXHVL69RTw8NWJ2Rhqy8jhF1ZLazl4ASE59nfXrCHa/EwNkZ6BaVS0pvqJlkQB
fTZNvbFpx7m0NOaxGzS5m2KCKFtH1R279RnMHRHovy0ljAr4hlW26APlUhlJsYe7
QMcm0/lyIZQd27pHhjoRzu9N5J01YotZ3rJLMzeBDI4vh1caRFtVAdyTHOdqdr+9
95WTTmtVRlcf7iq+9xdgIyPPCiFkdUOKFS0dc7V794yJjqOfW7ToJsEe/hZlCj5H
4yJGhJye3dH9rEzEgTPiIQb+mVYG9y5fJXK7XZ25pnvHNZ8+HheHXEUQdTWgW8ZI
uHa6eitXXd0lp2xNUN2Itt58Isqn1U4cC7DsPZsH+eVSxIBrIUtx2YVDrwx7yywn
8K12ByKlxB7bpfBsMvmdhcZYuTp/y8q7W259117ZmCahhSwMm0k=
=jwba
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 7 - Sporadic problem re: cookies

[Chad Stansbury]

We've been troubleshooting an issue where our web application is getting a
very occasional request that contains no cookies even though a Wireshark on
the application server shows those cookies coming in on the request.

I was able to replay the request that was captured via Wireshark, and when
doing so, everything goes through just fine... so that rules out any sort
of weird character set / header parsing issues.

Environment specifics: Tomcat v7.0.77 running the (http-bio) connector

Now here's the twist: Currently something in the site infrastructure has
been configured to proxy to Tomcat with HTTP/1.0 instead of 1.1. We're
trying to track that down and address that issue (for performance reasons),
but in the mean time, we're wondering whether or not this is a concurrency
issue related to protocol caching/recycling?

Has anyone ever seen anything like this before? Is there any legitimate
scenario(s) where Tomcat will *not* parse out the cookies, but still route
the request to the web app? Is this possible an edge condition that that
might be caused by the use of HTTP/1.0? Could this possibly be caused by
the number of maxThreads exceeding the `processorCache` value?

Thanks in advance, Chad

RE: cookies and webservice

[Caldarale, Charles R]

 From: Diego Monni [mailto:diego.mo...@gmail.com] 
 Subject: cookies and webservice

 I have to use a webservice (tomcat 7.0.0. + axis2 1.5 + jdk 6.0.21)

Try it again on a stable version of Tomcat (7.0.6).

 but in the response there isn't the jsessionid. In the application context
 the flag cookies is set to true and when I browse the application page the
 jsessionid works fine.

Your statements are contradictory: first you say jsessionid isn't in the 
response, then you say it works fine.  What should we believe?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: cookies and webservice

[Diego Monni]

Thanks for the response.
I mean that my application contains jsp pages and webservices. When I call a
jsp page the jsessionid is present. When I invoke a service method in the
response header jsessionid is not present.

diego

2011/1/19 Caldarale, Charles R chuck.caldar...@unisys.com

  From: Diego Monni [mailto:diego.mo...@gmail.com]
  Subject: cookies and webservice

  I have to use a webservice (tomcat 7.0.0. + axis2 1.5 + jdk 6.0.21)

 Try it again on a stable version of Tomcat (7.0.6).

  but in the response there isn't the jsessionid. In the application
 context
  the flag cookies is set to true and when I browse the application page
 the
  jsessionid works fine.

 Your statements are contradictory: first you say jsessionid isn't in the
 response, then you say it works fine.  What should we believe?

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: cookies and webservice

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego,

On 1/19/2011 9:48 AM, Diego Monni wrote:
 Thanks for the response.
 I mean that my application contains jsp pages and webservices. When I call a
 jsp page the jsessionid is present. When I invoke a service method in the
 response header jsessionid is not present.

How are you checking for the response header?

Is your web service client authenticating with the server? If a session
isn't created, then a cookie will never be returned. A session will be
created if you use FORM authentication or if your code explicitly
creates a session.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk03FpsACgkQ9CaO5/Lv0PCrPgCggPmyCzwBKjkgvT/cyMDLMnVw
D1IAoKb+OcFyZRgISMwrN54PJyA553ln
=ELsa
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: cookies and webservice

[Diego Monni]

I use whireshark in order to snif the transaction because de the proxy class
return null

MessageContext inMsgCtx1 =
stub1._getServiceClient().getLastOperationContext().getMessageContexts().get(Out);
String incomingCookie1 =
(String)inMsgCtx.getServiceContext().getProperty(HTTPConstants.COOKIE_STRING);

The web service client use an application authentication (service with login
method) and it doesn't perform any other autentication.

diego

2011/1/19 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Diego,

 On 1/19/2011 9:48 AM, Diego Monni wrote:
  Thanks for the response.
  I mean that my application contains jsp pages and webservices. When I
 call a
  jsp page the jsessionid is present. When I invoke a service method in the
  response header jsessionid is not present.

 How are you checking for the response header?

 Is your web service client authenticating with the server? If a session
 isn't created, then a cookie will never be returned. A session will be
 created if you use FORM authentication or if your code explicitly
 creates a session.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk03FpsACgkQ9CaO5/Lv0PCrPgCggPmyCzwBKjkgvT/cyMDLMnVw
 D1IAoKb+OcFyZRgISMwrN54PJyA553ln
 =ELsa
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: cookies and webservice

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diego,

On 1/19/2011 12:08 PM, Diego Monni wrote:
 MessageContext inMsgCtx1 =
 stub1._getServiceClient().getLastOperationContext().getMessageContexts().get(Out);
 String incomingCookie1 =
 (String)inMsgCtx.getServiceContext().getProperty(HTTPConstants.COOKIE_STRING);

So, what is the value of HTTPConstants.COOKIE_STRING?

I guess it doesn't matter since you are using Wireshark and aren't
seeing the header you want, anyway.

 The web service client use an application authentication (service with login
 method) and it doesn't perform any other autentication.

The only thing I can think of is that the server isn't creating a
session and therefore no session identifier is being returned to the client.

Are you sure a session is being created? If so, how do you know?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk03ZKgACgkQ9CaO5/Lv0PBIkwCeMzj3fuA/srufD8w9lDhMComM
ie8AnjwolCL8EJTEyXq5q18SWNQ3JJlP
=l/oF
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Cookies handling issue

[Rowe, Ciaran]

Hi,

This issue probably won't be given a great deal of attention. There's conflict 
between what the spec says, and what has actually been going on in the 
development world. The de facto reality is that people have been using = 
characters in cookies despite them being prohibited for a long time.

If you want this netscape style cookie to be valid and not quoted by tomcat, 
you should revert to the ServerCookie  Cookies code 
(org.apache.tomcat.util.http.*) from an earlier revision of the 5.5.x series 
(5.5.17 works - 
http://svn.apache.org/repos/asf/tomcat/connectors/tags/tc5.5.x/TOMCAT_5_5_17/util/java/org/apache/tomcat/util/http/)

Be vigilant w.r.t. any bugs/security issues logged against that version. 

-Ciarán


-Original Message-
From: mateo-jl [mailto:mateo...@orange.fr]
Sent: 18 June 2009 14:07
To: users@tomcat.apache.org
Subject: Cookies handling issue

Hi everybody,

recently i've reported a problem, which wasn't a new one, related to the
encoding base64 within cookies (= separator ... only at reading :
request.getCookies) .
I was responded that this problem will probably be corrected  with
Tomcat 6.0.19 or 6.0.20 and 5.5.28. The last one is not yet released and
in the 6.0.20 I do not see any patch for this problem.
Do you think that it will be corrected ?

Thank you

JLM

--
NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error. Morgan Stanley may monitor and store emails to the 
extent permitted by applicable law.

Re: Cookies handling issue

[Mark Thomas]

mateo-jl wrote:
 Hi everybody,
 
 recently i've reported a problem, which wasn't a new one, related to the 
 encoding base64 within cookies (= separator ... only at reading : 
 request.getCookies) .
 I was responded that this problem will probably be corrected  with Tomcat 
 6.0.19 or 6.0.20 and 5.5.28. The last one is not yet released and in the 
 6.0.20 I do not see any patch for this problem.
 Do you think that it will be corrected ?

As per the change log, it is fixed in 6.0.20

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cookies handling issue

[mateo-jl]

Hello Mark,

i do not have any doubt about the fix but i've read all the bugs at the 
ChangeLog (http://tomcat.apache.org/tomcat-6.0-doc/changelog.html) and I did 
not see the one related to this problem. 
Maybe there are not all recorded.

Thank you for the response

JLM




 Message du 19/06/09 13:53
 De : Mark Thomas 
 A : Tomcat Users List 
 Copie à : 
 Objet : Re: Cookies handling issue
 
 
 mateo-jl wrote:
  Hi everybody,
  
  recently i've reported a problem, which wasn't a new one, related to the 
  encoding base64 within cookies (= separator ... only at reading : 
  request.getCookies) .
  I was responded that this problem will probably be corrected with Tomcat 
  6.0.19 or 6.0.20 and 5.5.28. The last one is not yet released and in the 
  6.0.20 I do not see any patch for this problem.
  Do you think that it will be corrected ?
 
 As per the change log, it is fixed in 6.0.20
 
 Mark
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 

Re: Cookies handling issue

[Mark Thomas]

mateo-jl wrote:
 Hello Mark,
 
 i do not have any doubt about the fix but i've read all the bugs at the 
 ChangeLog (http://tomcat.apache.org/tomcat-6.0-doc/changelog.html) and I did 
 not see the one related to this problem. 

You need to read further down the page. They are all there.

 Maybe there are not all recorded.

The spec compliance changes were made in 6.0.15

The workaround for apps using '=' (automatically switching invalid v0
cookies to v1 and quoting them) went in to 6.0.16.

There was an IE related workaround in 6.0.17

Some sync issues were fixed in 6.0.19, httpOnly support was added, a
workaround for an IE/Safari bug was added

The biggest problem with all of this was getting to a cookie
implementation that was:
a) spec compliant (easy)
b) worked with all the major browsers (hard)

I believe we are there now.

Mark


 
 Thank you for the response
 
 JLM
 
 
 
 
 Message du 19/06/09 13:53
 De : Mark Thomas 
 A : Tomcat Users List 
 Copie à : 
 Objet : Re: Cookies handling issue


 mateo-jl wrote:
 Hi everybody,

 recently i've reported a problem, which wasn't a new one, related to the 
 encoding base64 within cookies (= separator ... only at reading : 
 request.getCookies) .
 I was responded that this problem will probably be corrected with Tomcat 
 6.0.19 or 6.0.20 and 5.5.28. The last one is not yet released and in the 
 6.0.20 I do not see any patch for this problem.
 Do you think that it will be corrected ?
 As per the change log, it is fixed in 6.0.20

 Mark



 -
 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

Re: Cookies and values with ':' in them

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre-John,

On 4/16/2009 5:48 PM, Andre-John Mas wrote:
 Will this only be for writing? I depend a cookie set by a third-party
 web application in the same domain, which sends me the cookies this
 way. If it is only for writing, then I will have to find a way of
 convincing the developers of the other application to make the change.

You can always try to parse the header yourself, instead of using the
Cookie part of the servlet API. Then you can allow the embedded colon
regardless of the cookie specification.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAknt1OgACgkQ9CaO5/Lv0PDZ8wCguf4Py6pCzGHLiNj3dP0ljYsf
vEAAoIscMyKFD6sGKW+m0gByV+Ujnm/+
=vieM
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cookies and values with ':' in them

[Andre-John Mas]

On 21-Apr-2009, at 10:15, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre-John,

On 4/16/2009 5:48 PM, Andre-John Mas wrote:

Will this only be for writing? I depend a cookie set by a third-party
web application in the same domain, which sends me the cookies this
way. If it is only for writing, then I will have to find a way of
convincing the developers of the other application to make the  
change.


You can always try to parse the header yourself, instead of using the
Cookie part of the servlet API. Then you can allow the embedded colon
regardless of the cookie specification.


Yup, though not really elegant. We have opted to try to work with the
developers of the application for them to make the necessary changes.

André-John
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cookies and values with ':' in them

[Mark Thomas]

Andre-John Mas wrote:
 Hi,
 
 The company I am working for is in the process of migrating from Tomcat
 5.x.x to Tomcat5.5.27. In doing so we noticed that the any cookie value
 containing a colon will have the value trimmed up to before that
 character. This is new. A work around is to add quotes around the value,
 but we were hoping to avoid such changes:

Using a ':' in a v0 cookie is not legal. You have to use a v1 cookie
which is as simple as using:
cookie.setVersion(1);

5.5.28 will (hopefully - if it gets enough votes) an feature (enabled by
default) to automatically switch invalid v0 cookies to v1 cookies and
quote them.

Mark

 
 To write:
 
 Cookie cookie = new
 Cookie(PROFILE_UPDATE_TS_X,2009-04-16T23:34:19Z);
 cookie.setSecure(true);
 cookie.setPath(/);
 response.addCookie(cookie);
 
 To read:
 
 /**
   * This is a convenience method for getting a cookie by name. If the
   * cookie is not present in the request, a null value will be
 returned.
   */
  protected Cookie getCookie ( String cookieName, HttpServletRequest
 request ) {
  Cookie[] cookies = request.getCookies();
  for ( int i=0; icookies.length; i++ ) {
  if ( cookies[i].getName().equals(cookieName) ) {
  return cookies[i];
  }
  }
  return null;
  }
 
 This is certainly a regression.
 
 André-John-
 
 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

Re: Cookies and values with ':' in them

[Andre-John Mas]

On 16-Apr-2009, at 17:08, Mark Thomas wrote:


Using a ':' in a v0 cookie is not legal. You have to use a v1 cookie
which is as simple as using:
cookie.setVersion(1);

5.5.28 will (hopefully - if it gets enough votes) an feature  
(enabled by

default) to automatically switch invalid v0 cookies to v1 cookies and
quote them.



Will this only be for writing? I depend a cookie set by a third-party
web application in the same domain, which sends me the cookies this
way. If it is only for writing, then I will have to find a way of
convincing the developers of the other application to make the change.

André-John
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cookies and values with ':' in them

[Mark Thomas]

Andre-John Mas wrote:
 
 On 16-Apr-2009, at 17:08, Mark Thomas wrote:
 
 Using a ':' in a v0 cookie is not legal. You have to use a v1 cookie
 which is as simple as using:
 cookie.setVersion(1);

 5.5.28 will (hopefully - if it gets enough votes) an feature (enabled by
 default) to automatically switch invalid v0 cookies to v1 cookies and
 quote them.
 
 
 Will this only be for writing?
Yes.

 I depend a cookie set by a third-party
 web application in the same domain, which sends me the cookies this
 way. If it is only for writing, then I will have to find a way of
 convincing the developers of the other application to make the change.

If that app is running on Tomcat then Tomcat (5.5.28 hopefully) will do
the switch for them. If not, they'll have to do it themselves.

Either way using ':' in a v0 cookie is simply not legal. I would argue
the app is broken and needs fixing.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ken,

Ken Bowen wrote:
 So is it the case that if browser B has
 previously set a cookie at site S (at url uuu), then when B returns to uuu
 (say after many days but before the cookie for uuu has expired), B sends
 the cookies for uuu in the /first/ request?

That's the idea: the cookie in this case is sent even with the first
request.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIjd49CaO5/Lv0PARAkkKAKDAhqqj4YHYtbyWJJ8VK7cqkHb03QCZAUEl
2ykBEqJop6It0K7RVytPqwA=
=Onik
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookies

[Caldarale, Charles R]

 From: Ken Bowen [mailto:[EMAIL PROTECTED] 
 Subject: Cookies
 
 So is it the case that if browser B has previously set a 
 cookie at site S (at url uuu), then when B returns to uuu
 (say after many days but before the cookie for uuu has 
 expired), B sends the cookies for uuu in the /first/ request?

That's the whole idea.  To quote from RFC 2965:

3.3.4  Sending Cookies to the Origin Server

   When it sends a request to an origin server, the user agent
   includes a Cookie request header if it has stored cookies
   that are applicable to the request, based on
  * the request-host and request-port;
  * the request-URI;
  * the cookie's age.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[tony . chamberlain]

Before, I was noticing the cookie getting set when I did Edit-Preferences.
Later I did not, and I noticed my machine was blocked from setting cookies.
I removed the block, tried again and later it was blocked again. I was 
originally
removing the cookie and maybe that made Firefox think I wanted to block it.
Anyway, even when the cookie was being set it wasn't being found.

I tried the path thing but that didn't seem to work either. Even if I tried 
cookie.getPath() and
then set the kill cookie's path.

So I just made a string SpecialLoginCookiePath = /dmaconf and used that for 
all the paths.
I think that works now. It seems to. And the deleting seems to work now. The 
frustrating
thing is, when you change your jsp code, save it, even when you do SHIFT-RELOAD 
and
clear your cache it still has remnants of the old code and reports problems 
that you have fixed
already.

I am going to try that live http headers.

-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Monday, August 6, 2007 05:01 PM
To: 'Tomcat Users List'
Subject: Re: cookies

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony,

[EMAIL PROTECTED] wrote:
 I just did a responses to this and somehow it got lost ;-(

I hate it when that happens. :(

 Cookie oreo;

Very clever ;)

That code looks fine, by the way. The fact that cookies.length is 1
probably means that the cookie was never sent, rather than you writing
bad code. Your code looks fine, too. I was looking to see if you did
anything like if(cookie.getName() == UserLevel) which, of course,
wouldn't work.

 You can see I have a couple debug statements. Length is 1
 and the only cookie is JSESSIONID 034B86006263B7E9E68EE7A660DC728E.
 Though I do see it in the catalina log and the edit-preferences (UserLevel 
 0).

What does that mean?

 The cookie-setting is not mine, but rather the person who left. It is kind of 
 complicated
 so I will just show the relative parts (you can ignore the else part). As I 
 said it shows up
 in the log file and edit-preference
 
 if(err.errcode == 0){
 Cookie cok = new Cookie(UserLevel,sUserLevel);
 System.out.println( Added COOKIE UserLevel:  + sUserLevel );
 response.addCookie(cok);

Hmm... no path set on the cookie.

Did you verify that the cookie is being sent to the client correctly
(after the addCookie call above)? Use something like LiveHTTPHeaders, or
even the RequestDumperValve on the server-side to see what's up.

For good measure, you might want to modify the cookie-setting code to do
this:

Cookie cok = new Cookie(UserLevel, sUserLevel);
cok.setPath(request.getContextPath());
response.addCookie(cok);

The servlet API doesn't require the path, but doesn't say what the
default path is. Perhaps it is effectively /. Observation of the
request and response headers will be requires in order to understand
what's going on.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGt4w/9CaO5/Lv0PARAu6kAJ4mbMDU2cEiTCd3ZTmpOKKgYWyoogCeK4Ds
gJZ6IWEJxTbjuEpYaTDh+Dg=
=i1q5
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony,

[EMAIL PROTECTED] wrote:
 He has something called login.html which uses a login.java compiled
 program to set a cookie (response.addCookie( UserLevel, value) )
 which adds a cookie called UserLevel with a value retrieved from
 logging in. His other java code does a request.getCookies() and goes
 through the cookies to find UserLevel from which he then gets the
 values.

That sounds pretty standard. You ought to be able to replicate this
capability pretty easily.

 My code does the same thing, does
 getCookies[] and looks for UserLevel. Problem is, it does not find
 it. When I do the Edit-Preferences-Show Cookies, UserLevel is
 there with the correct value, but all my java jsp code can find is
 the session ID.

Can you post your cookie finding code? Also, post the portion of your
(new) code that /sets/ the cookie. Often, cookie-related issues are tied
to incorrect setting of the path of the cookie. Also, are you using
SSL at all? If so, please describe any changes from/to SSL requests
during this process.

 Does anyone know what I am doing wrong, or how I can get the
 recently-added cookie?
 
 I am using firefox.

Oh, good. There are several tools available for ff that are useful in
this regard. LiveHTTPHeaders is an add-on that allows you to snoop the
request and response headers of HTTP transactions. Once installed, you
can just open a LiveHTTPHeaders window and then go through your login
process. You can see the headers for all page requests until you clear
the buffer, so you can verify that, at least, the cookies are being sent
correctly.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGt2CH9CaO5/Lv0PARAo7YAJ92cq9fGzFhA4OBH1yJt19PKMHwGQCfecGy
85fW97ugj27ORccs95Rv5pM=
=t321
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[tony . chamberlain]

I just did a responses to this and somehow it got lost ;-(

Can you post your cookie finding code? Also, post the portion of your(new) 
code that /sets/ the cookie. Often, cookie-related issues are tiedto 
incorrect setting of the path of the cookie. Also, are you usingSSL at all? 
If so, please describe any changes from/to SSL requestsduring this process.
Sure. My cookie-finding code is just basically this:

 int UserLevel = 4;

 Cookie cookies[] = request.getCookies();
 if ( cookies != null ) {
%
Length: %=cookies.length%p
%
 int co;
 Cookie oreo;
 for ( co = 0; co  cookies.length; co++ ) {
 oreo = cookies[co];
%
%=oreo.getName()% %=oreo.getValue()%
%
 if ( oreo.getName().equals(UserLevel) ) {
 UserLevel = Integer.parseInt( oreo.getValue() );
 }
 }
}

You can see I have a couple debug statements. Length is 1
and the only cookie is JSESSIONID 034B86006263B7E9E68EE7A660DC728E.
Though I do see it in the catalina log and the edit-preferences (UserLevel 0).

The cookie-setting is not mine, but rather the person who left. It is kind of 
complicated
so I will just show the relative parts (you can ignore the else part). As I 
said it shows up
in the log file and edit-preference

if(err.errcode == 0){
 Cookie cok = new Cookie(UserLevel,sUserLevel);
 System.out.println( Added COOKIE UserLevel:  + sUserLevel );
 response.addCookie(cok);
 response.sendRedirect(/dmaconf/html/dma_config.html);
 }else{
 Cookie cok = new Cookie(UserLevel,);
 response.addCookie(cok);
 tmpl = wm.getTemplate(login.wm);
 err.errmsg += Please try again or contact the adminstrator.;
 c.put(errorcode, err.errcode);
 c.put(errormsg, err.errmsg);
 tmpl.write(out, c);
 out.flush();
 }


-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Monday, August 6, 2007 01:55 PM
To: 'Tomcat Users List'
Subject: Re: cookies

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony,

[EMAIL PROTECTED] wrote:
 He has something called login.html which uses a login.java compiled
 program to set a cookie (response.addCookie( UserLevel, value) )
 which adds a cookie called UserLevel with a value retrieved from
 logging in. His other java code does a request.getCookies() and goes
 through the cookies to find UserLevel from which he then gets the
 values.

That sounds pretty standard. You ought to be able to replicate this
capability pretty easily.

 My code does the same thing, does
 getCookies[] and looks for UserLevel. Problem is, it does not find
 it. When I do the Edit-Preferences-Show Cookies, UserLevel is
 there with the correct value, but all my java jsp code can find is
 the session ID.

Can you post your cookie finding code? Also, post the portion of your
(new) code that /sets/ the cookie. Often, cookie-related issues are tied
to incorrect setting of the path of the cookie. Also, are you using
SSL at all? If so, please describe any changes from/to SSL requests
during this process.

 Does anyone know what I am doing wrong, or how I can get the
 recently-added cookie?

 I am using firefox.

Oh, good. There are several tools available for ff that are useful in
this regard. LiveHTTPHeaders is an add-on that allows you to snoop the
request and response headers of HTTP transactions. Once installed, you
can just open a LiveHTTPHeaders window and then go through your login
process. You can see the headers for all page requests until you clear
the buffer, so you can verify that, at least, the cookies are being sent
correctly.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGt2CH9CaO5/Lv0PARAo7YAJ92cq9fGzFhA4OBH1yJt19PKMHwGQCfecGy
85fW97ugj27ORccs95Rv5pM=
=t321
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]