Thanks. I will investigate the logging and cookie processor configuration.
The SEVERE cookie error does come with a stack trace:
17-Aug-2015 01:13:23.051 SEVERE [catalina-exec-942]
org.apache.coyote.http11.AbstractHttp11Processor.process Error processing
request
java.lang.IllegalArgumentException: Control character in cookie value or
attribute.
at
org.apache.tomcat.util.http.LegacyCookieProcessor.isHttpSeparator(LegacyCookieProcessor.java:732)
at
org.apache.tomcat.util.http.LegacyCookieProcessor.getTokenEndPosition(LegacyCookieProcessor.java:714)
at
org.apache.tomcat.util.http.LegacyCookieProcessor.processCookieHeader(LegacyCookieProcessor.java:554)
at
org.apache.tomcat.util.http.LegacyCookieProcessor.parseCookieHeader(LegacyCookieProcessor.java:273)
at org.apache.catalina.connector.Request.parseCookies(Request.java:2949)
at
org.apache.catalina.connector.Request.getServerCookies(Request.java:2004)
at
org.apache.catalina.connector.CoyoteAdapter.parseSessionCookiesId(CoyoteAdapter.java:1205)
at
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:916)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:513)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
I use an HTTP connector with default configuration (which I think for Tomcat 8
means NIO).
Robert
> On 2015-08-20, at 06:03, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
>
> 2015-08-19 18:21 GMT+03:00 Robert Tupelo-Schneck <schn...@cnri.reston.va.us>:
>> I'm running Tomcat 8.0.24. I see lots of errors in catalina.out with lines
>> like
>>
>> Note: further occurrences of Cookie errors will be logged at DEBUG level.
>> Note: further occurrences of Parameter errors will be logged at DEBUG level.
>> Note: further occurrences of HTTP header parsing errors will be logged at
>> DEBUG level.
>>
>> But, the errors keep showing up at INFO level!
>>
>> I get these many many times a day, but I do not get user complaints, and I
>> have not been able to cause the errors myself.
>>
>> I would like to either
>> (1) Make these errors go away (such as by really having them logged at DEBUG
>> level), or
>> (2) Get detailed information on the client request that caused the error so
>> I can figure out how to make them less frequent.
>
> 1. Both logging level and silencing interval are configurable with
> system properties. See properties with "UserDataHelper" in their name
> on the following page:
>
> http://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Logging
>
> By default suppression period is one day. For performance reasons,
> suppression period may be not effective immediately (so that several
> simultaneous messages can be logged at info level).
>
> 2. There is a way to match log message to a line in access log, by
> using id of the current thread.
>
> At the event logging side, org.apache.juli.OneLineFormatter does
> include thread name in its log message.
>
> At access logging side the AccessLogValve can be configured to log
> thread name (as well as some other detailed information).
>
> 3. If some more detailed information is needed, one need to change
> specific error messages (it is doable, if there is an interest in it,
> but it depends on whether additional information is available in those
> places).
>
>> Can anyone advise on how I could accomplish either of those goals?
>>
>> For completeness, here are the kinds of errors:
>>
>> org.apache.tomcat.util.http.LegacyCookieProcessor.processCookieHeader
>> Cookies: Invalid cookie. Value not a token or quoted value
>
> Some client has a broken cookie, uses a broken browser. E.g. if a
> client is sending 8-bit characters where only 7-bit (aka US-ASCII) are
> allowed.
>
> It is possible to change cookie handling by configuring a different
> CookieProcessor,
> http://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html
>
>
> If client browser has a broken cookie, it will continue sending it
> until the cookie expires or cookies are cleared by user, or server
> sends set-cookie header that clears that cookie.
>
>> org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP
>> request header
>> org.apache.tomcat.util.http.Parameters.processParameters Invalid chunk
>> starting at byte [242] and ending at byte [244] with a value of [=1] ignored
>>
>> I also see a lot of this one, at SEVERE level; I'd like to deal with it the
>> same way as the others:
>>
>> org.apache.coyote.http11.AbstractHttp11Processor.process Error processing
>> request
>> java.lang.IllegalArgumentException: Control character in cookie value or
>> attribute.
>
>
> No stacktrace here? It is odd for a cookie error to be popping up to
> a request processor.
>
> What is your connector configuration:
> protocol (HTTP / AJP),
> implementation (BIO / NIO / NIO2 / APR) ?
>
>
> BTW, Tomcat 8.0.26 is currently being tested and voted. You would like
> to test it, you can find details on dev@ mailing list.
>
> 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
