Hi Konstantin,

1. We're still an Latin-1 shop, primarily... 
.. skip to 
3. We've tried 6.0.24 as well, same result.


We were using 6.0.18 because I've been using in (on my Mac in development, 
other users using Linux in development) for the past 8 months with no real 
issues.

I'll get to work on the logging, see what turns up.

Thanks,

-g.

On Feb 16, 2010, at 2:47 PM, Konstantin Kolinko wrote:

> 2010/2/17 George Baxter <gbax...@shutterfly.com>:
>> Hi Konstantin,
>> 
>> Thanks for your reply.
>> 
>> Yes, the getHeaders("cookie") returns what seems to be a valid set of 
>> cookies, thus we're not losing them in any of the proxies we might have set 
>> up.  (Currently, we're only in development mode for tomcat 6 and we're not 
>> going through any proxies, just directly to the server.)
>> 
>> We get this problem in all sorts of browsers (FF, Safari, IE).
>> 
>> The thing that really bugs me is the inconsistency.  It's almost as if there 
>> were a race condition going on, but the request is basically single 
>> threaded, isn't it?  My only fear is some parser used in the tomcat code is 
>> being used in a non-thread safe manner, but then *everybody* would be having 
>> this problem, neh?
>> 
>> I'm finding out about the connectors, but we may not be using any as :
>> 
>> Jan 28, 2010 6:52:56 PM org.apache.catalina.core.AprLifecycleListener init
>> INFO: The APR based Apache Tomcat Native library which allows optimal 
>> performance in production environments was not found on the 
>> java.library.path: /dist/sfsite/obj
>> 
>> Hopefully, this is just in our development environments!
>> 
>> Thanks,
>> 
>> -George
>> 
>> 
>> On Feb 12, 2010, at 2:32 PM, Konstantin Kolinko wrote:
>> 
>>> 2010/2/13 George Baxter <gbax...@shutterfly.com>:
>>>> 
>>>> Hello,
>>>> 
>>>> We're running into an issue with tomcat 6.0.18 running on solaris.
>>>> Occasionally a request will come through that has cookies in the header, 
>>>> but
>>>> the request.getCookies() returns no cookies.
>>> 
>>> How do you observe that? You mean that it is present in
>>> HttpServletRequest.getHeaders("Cookie") ?
>>> 
>>>>  This causes the user to lose
>>>> session since even the JSESSIONID cookie is not recognized, and of course
>>>> all our custom cookies are lost.  It seems to happen randomly, across our
>>>> web site, and varies in frequency from every 2-3 requests to over 200
>>>> requests before it happens again.
>>>> 
>>>> There's no change to the cookie values (or very little) between requests.
>>>> 
>>>> In addition, this only seems to be a problem on solaris.  Running on MacOSx
>>>> or Linux and we don't see the issue.  Also, we don't have the problem in
>>>> Tomcat 5.5.
>>> 
>>> Any other details on your configuration?
>>> 
>>> What connectors are you using? HTTP/AJP? Nio/Bio/Apr? (usually some
>>> org.apache.coyote.* class is mentioned in the startup log in a
>>> "Starting Coyote .." message)   Do you have Apache HTTPD in front of
>>> Tomcat?   Do you have HTTP proxies around?  Are failing requests
>>> coming from some specific client? Are they coming from some specific
>>> browser?
>>> 
>>> Best regards,
>>> Konstantin Kolinko
>>> 
> 
> 
> 1. What is the default character encoding for your environment?
> 
> 2. Cookies are parsed in
> org.apache.tomcat.util.http.Cookies.processCookies()
> 
> You may
> 1) Look in your logs for a WARN message with the text "Cookies:
> Parsing cookie as String. Expected bytes."
> 
> 2) You can consider enabling FINE logging for the above mentioned
> class. Add this to the logging.properties:
> 
> org.apache.tomcat.util.http.Cookies.level=FINE
> 
> It will log what headers it parsed.
> Though it might be hard to match what is logged to your specific
> request, so it might be useless.
> 
> 3) When an issue is encountered, log the headers.
> Then post them here or try to parse them yourselves,
> copying the code from Cookies.processCookieHeader() for the Tomcat
> version that you are using.
> 
> 3. Have you considered trying it with a more recent Tomcat version?
> 
> 
> Best regards,
> Konstantin Kolinko
> 
> ---------------------------------------------------------------------
> 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

Reply via email to