We took a quick look at the cookie parsing code and unfortunately, logging is
dependent not on log4j configuration, but instead on a static final int 'dbg'
variable defined in the Cookies.java.
I'll try copy/paste code into my own class to see how it fairs on the header
value.
-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
