Bug 64210

I'll take a look.

What is triggering the headers to split across multiple TCP packets? That seems a little unusual.

It's just some large requests (a lot of cookies).

I have done some wireshark traffic recordings. For example one request was split  into a 2948 bytes TCP packet (ending with CR) and a 539 bytes packet (starting with LF)

Thanks. I'm able to reproduce this. I'm working on some additional test cases and a fix.

Fixed in:
- master for 10.0.0-M3 onwards
- 9.0.x for 9.0.33 onwards
- 8.5.x for 8.5.53 onwards
- 7.0.x for 7.0.102 onwards

Thanks for the fast reaction and fix (y).

I assume this was intentional, but in the event it wasn't, the combination of the patch for this issue and the previous "strict header value parsing" commit have resulted in Tomcat rejecting all requests that use a single LF as a delimiter between HTTP request lines as opposed to the correct delimiter of CRLF.

Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3) it is recommended that applications be tolerant of malformed requests, with HTTP header delimiters called out as a particular area of note:
> The line terminator for message-header fields is the sequence CRLF.
> However, we recommend that applications, when parsing such headers,
> recognize a single LF as a line terminator and ignore the leading CR.

After deploying Tomcat 8.5.53 in our environment, we noticed that our hardware load balancers were sending malformed requests of the following format to perform host liveness checks against our app servers:
GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n

We are able to correct these requests (thankfully) but this behavior wasn't called out in the Tomcat release notes. It also represents a stricter interpretation of RFC 2616 than other major web server software, so I figured I'd at least flag it here.

(In reply to Em Domingues from comment #6)
> I assume this was intentional, but in the event it wasn't, the combination
> of the patch for this issue and the previous "strict header value parsing"
> commit have resulted in Tomcat rejecting all requests that use a single LF
> as a delimiter between HTTP request lines as opposed to the correct
> delimiter of CRLF.
> 
> Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3)
> it is recommended that applications be tolerant of malformed requests, with
> HTTP header delimiters called out as a particular area of note:
> > The line terminator for message-header fields is the sequence CRLF.
> > However, we recommend that applications, when parsing such headers,
> > recognize a single LF as a line terminator and ignore the leading CR.
> 
> After deploying Tomcat 8.5.53 in our environment, we noticed that our
> hardware load balancers were sending malformed requests of the following
> format to perform host liveness checks against our app servers:
> GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n
> 
> We are able to correct these requests (thankfully) but this behavior wasn't
> called out in the Tomcat release notes. It also represents a stricter
> interpretation of RFC 2616 than other major web server software, so I
> figured I'd at least flag it here.

I can't find similar in https://tools.ietf.org/html/rfc7230#section-3.1.1

RFC 2616 is obsolete.

(In reply to Michael Osipov from comment #7)
> (In reply to Em Domingues from comment #6)
> > I assume this was intentional, but in the event it wasn't, the combination
> > of the patch for this issue and the previous "strict header value parsing"
> > commit have resulted in Tomcat rejecting all requests that use a single LF
> > as a delimiter between HTTP request lines as opposed to the correct
> > delimiter of CRLF.
> > 
> > Per RFC 2616 Section 19.3 (https://tools.ietf.org/html/rfc2616#section-19.3)
> > it is recommended that applications be tolerant of malformed requests, with
> > HTTP header delimiters called out as a particular area of note:
> > > The line terminator for message-header fields is the sequence CRLF.
> > > However, we recommend that applications, when parsing such headers,
> > > recognize a single LF as a line terminator and ignore the leading CR.
> > 
> > After deploying Tomcat 8.5.53 in our environment, we noticed that our
> > hardware load balancers were sending malformed requests of the following
> > format to perform host liveness checks against our app servers:
> > GET /foo HTTP/1.0\nHost: host.example.com \nConnection: Close\r\n\r\n
> > 
> > We are able to correct these requests (thankfully) but this behavior wasn't
> > called out in the Tomcat release notes. It also represents a stricter
> > interpretation of RFC 2616 than other major web server software, so I
> > figured I'd at least flag it here.
> 
> I can't find similar in https://tools.ietf.org/html/rfc7230#section-3.1.1
> 
> RFC 2616 is obsolete.

I'm aware. This still runs counter to the robustness principle, no?

For example, the implementation is inconsistent in where it errs on the side of being strict (here) and where it errs on the side of being tolerant (allowing multiple SP or HT between tokens) even when that's similarly against spec: https://github.com/apache/tomcat/blob/ae8c82eff96990878e79691819ae941538ee62fd/java/org/apache/coyote/http11/Http11InputBuffer.java#L404

I don't think the current solution resolved all the header issues.
For example, our project use Socket TCP to monitor Tomcat status like this:
"get /platform HTTP/1.0\n\n" (double \n, no \r) 

Before version 8.5.50 (same for 9.0.30), it response 302 like:
2020-03-09 21:17:12.000 CST DEBUG [18950:140054285395776] childHeartbeat: child reply=HTTP/1.1 302 ^M
Location: http://localhost:8080/platform/^M
Date: Mon, 09 Mar 2020 13:17:12 GMT^M
Connection: close^M
Server: This information has been blocked for security reasons^M
^M

With 8.5.51 (9.0.31), it no response and make my monitor always wrongly restart Tomcat.

With 8.5.53 (9.0.33), it response 400 like:
2020-03-23 18:58:45.000 CST DEBUG [8584:140509820770112] childHeartbeat: child reply=HTTP/1.1 400 ^M
Content-Type: text/html;charset=utf-8^M
Content-Language: en^M
Content-Length: 1823^M
Date: Mon, 23 Mar 2020 10:58:45 GMT^M
Connection: close^M
Server: This information has been blocked for security reasons^M
^M
<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {c

Can I configure any parameters to ignore such situation?
I tried rejectIllegalHeader="false", and relaxedQueryChars="|{}\r\n", relaxedPathChars="|{}\r\n" but no effect.

Thanks
Xing

(In reply to Xing from comment #9)
> I don't think the current solution resolved all the header issues.
> For example, our project use Socket TCP to monitor Tomcat status like this:
> "get /platform HTTP/1.0\n\n" (double \n, no \r) 

That request is invalid and is, therefore, rejected with a 400 response.

You can fix the issue by correcting the broken client.

(In reply to Mark Thomas from comment #10)
> (In reply to Xing from comment #9)
> > I don't think the current solution resolved all the header issues.
> > For example, our project use Socket TCP to monitor Tomcat status like this:
> > "get /platform HTTP/1.0\n\n" (double \n, no \r) 
> 
> That request is invalid and is, therefore, rejected with a 400 response.
> 
> You can fix the issue by correcting the broken client.

No configuration to resolve this?
Then should I remove the "\n" in my request?

Thanks
Xing

The correct line terminator for an HTTP/1.0 request is CRLF ("/r/n"). You should use that.

(In reply to Mark Thomas from comment #12)
> The correct line terminator for an HTTP/1.0 request is CRLF ("/r/n"). You
> should use that.

Thanks a lot, I'm compiling :)

Xing

I'm using tomcat 9.0.38 on windows 10, i'm getting request from a device, and tomcat showing the follow message on console: 

"08-Dec-2020 00:11:11.539 INFO [http-nio-8080-exec-5] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
        java.lang.IllegalArgumentException: Invalid character found in the HTTP protocol [HTTP/1.10x0aHost:]"

This is my server.xml conector section:
    <Connector port="8080" protocol="HTTP/1.1"
				connectionTimeout="20000"
				redirectPort="8443" 
				URIEncoding="UTF-8"
				rejectIllegalHeader="false"
				relaxedPathChars ='[]|'
			   />
i believe that the value 0x0a represent the chracter (LF), but i can't access to modify the device request.

Note: If i test from JavaWebClientSockect or from "Smart Websockect Client" chrome-extension plugin; the tomcat work fine.

Thank in advanced for your support.

I'm using tomcat 9.0.38 on windows 10, when the tomcat server get request from a device, with protocol ws (Websockect), show the following message:
" INFO [http-nio-8080-exec-5] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
        java.lang.IllegalArgumentException: Invalid character found in the HTTP protocol [HTTP/1.10x0aHost:]", and the request is rejected with 400 error number in logs.

My server.xml conector section is :
    <Connector port="8080" protocol="HTTP/1.1"
				connectionTimeout="20000"
				redirectPort="8443" 
				URIEncoding="UTF-8"
				rejectIllegalHeader="false"
				relaxedPathChars ='[]|'
			   />

I can't access to change the device request.

Note: if i try to access the websockect through Smart Websockect client chrome plugin or javaWebClient spring 5, work fine.

Thank in advanced for your comments.

Bugzilla is not a support forum. Please use the users mailing list.