Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jetty-users] NotUtf8Exception when using a jetty continuaton


I have a curious error ...  using Jetty 8.1.10

We have a client sending us a request that appears to be badly encoded in some way.  We have a servlet that is making use of a continuation.
So, on the first pass, it appears to handle the request, we capture details from the query params successfully (we are able to grab all of these on the first pass and log them), then we establish a continuation, set a timeout and suspend() it.

However, it seems that upon resuming this continuation, it is then unable to parse the response on this second pass and generates the following stack trace.

2013-10-04 10:07:10,199 85177654 (qtp1195561814-892) WARN  [org.eclipse.jetty.util.UrlEncoded]  org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte 73 in state 4
2013-10-04 10:07:10,199 85177654 (qtp1195561814-892) WARN  []  handle failed
org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte 73 in state 4
    at org.eclipse.jetty.util.Utf8Appendable.appendByte(
    at org.eclipse.jetty.util.Utf8Appendable.append(
    at org.eclipse.jetty.http.HttpURI.toUtf8String(
    at org.eclipse.jetty.http.HttpURI.toString(
    at java.lang.String.valueOf(
    at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(
    at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(
    at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(
    at org.eclipse.jetty.http.HttpParser.parseNext(
    at org.eclipse.jetty.http.HttpParser.parseAvailable(
    at org.eclipse.jetty.server.AsyncHttpConnection.handle(
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
    at org.eclipse.jetty.util.thread.QueuedThreadPool$

The offending request regrettably doesn't make it to the access log (I am hopeful that we will be able to work with the offending client to capture a trace, and can make that available)

Based on the fact that i am initially able to handle the request before the continuation is resumed, i guess there is some inconsistency in the request parsing once the request is re-played by the continuation.

Has anybody seen something simiilar to this? is there a workaround or some known gotcha i may be tripping over here?



Back to the top