Well.. we parsed the header that failed, and it parsed just fine.

Note that we're parsing via the 'old deprecated' parse by string entity.  I 
guess I'll try parsing by bytes next.

-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