https://bz.apache.org/bugzilla/show_bug.cgi?id=64210
Bug ID: 64210
Summary: parsing request headers fail
Product: Tomcat 9
Version: 9.0.31
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: christian.haberm...@gmail.com
Target Milestone: -----
Since we switched to tomcat 9.0.31, a lot of responses fail with HTTP status
400 Bad Request.
org.apache.coyote.http11.Http11Processor tells us, that the requests fail due
to "The HTTP/1.1 request did not provide a host header". But the affected
requests all have a host header.
We found out that this problem occurs when a request is send in multiple
TCP-packets and one packet ends with (CR) an the next starts with (LF).
e.g.
TCP packet 1: "Accept: image/webp,*/*(CR)",
TCP packet 2: "(LF)Host: www.myhost.com(CR)(LF)(CR)(LF)"
As far as I can see, there was a change in header parsing between 9.0.30 and
9.0.31:
https://github.com/apache/tomcat/commit/ae8c82eff96990878e79691819ae941538ee62fd#diff-6d40d03c206f9d0696e5fa2c3b015c2e
My suspicion is that - if the bytebuffer used in
org.apache.coyote.http11.Http11InputBuffer.parseHeader() starts with an (LF),
parsing fails.
In previous version a LF lead to parse status DONE:
} else if (chr == Constants.LF) {
return HeaderParseStatus.DONE;
But now the previous char has to be a (CR), which may be not the case, if the
ByteBuffer just got filled with the part that starts with the (LF)
} else if (prevChr == Constants.CR && chr == Constants.LF) {
return HeaderParseStatus.DONE;
(with the assumption to the new behaviour I'm not 100% sure though)
After having a first look at the parseHeader()-method, it may be useful to
initialize prevChr with the char at ByteBuffer's previous position.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
