[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Mark Thomas --- Bugzilla is not a support forum. Please use the users mailing list. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 Alberto Linares changed: What|Removed |Added Resolution|FIXED |--- OS||All Status|RESOLVED|REOPENED --- Comment #15 from Alberto Linares --- 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 : 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. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 Alberto Linares changed: What|Removed |Added OS|All |Windows 10 Version|9.0.31 |9.0.38 Hardware|All |PC --- Comment #14 from Alberto Linares --- 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: 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. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210
--- Comment #13 from Xing ---
(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
--
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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210
--- Comment #12 from Mark Thomas ---
The correct line terminator for an HTTP/1.0 request is CRLF ("/r/n"). You
should use that.
--
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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #11 from Xing --- (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 -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #10 from Mark Thomas --- (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. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #9 from Xing --- 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 HTTP Status 400 – Bad
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 david.keel...@tylertech.com changed: What|Removed |Added CC||david.keel...@tylertech.com -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #8 from Em Domingues --- (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 -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #7 from Michael Osipov --- (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. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #6 from Em Domingues --- 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. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #5 from Christian H. --- Thanks for the fast reaction and fix (y). -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Thomas --- 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 -- 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
Re: [Bug 64210] parsing request headers fail
On 10/03/2020 13:58, Christopher Schultz wrote: > Mark, > > On 3/10/20 08:52, Mark Thomas wrote: >> On 10/03/2020 10:14, bugzi...@apache.org wrote: >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 >>> >>> --- Comment #3 from Mark Thomas --- Thanks. >>> I'm able to reproduce this. I'm working on some additional test >>> cases and a fix. >>> > >> Moving to the dev@ list as this isn't really related to fixing this >> issue. > >> This is a regression in the HTTP header parsing fixes fir CRLF >> added in the recent release round. > >> I'm leaning towards cancelling the current set of releases to pick >> up this fix. > >> Thoughts? > > +1 for cancelling There seems to be consensus for this position. I'll proceed on that basis. I've just pushed the commits that fix this (and expand the tests). Extra pairs of eyes welcome. I'll probably be tagging later today. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 64210] parsing request headers fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/10/20 08:52, Mark Thomas wrote: > On 10/03/2020 10:14, bugzi...@apache.org wrote: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 >> >> --- Comment #3 from Mark Thomas --- Thanks. >> I'm able to reproduce this. I'm working on some additional test >> cases and a fix. >> > > Moving to the dev@ list as this isn't really related to fixing this > issue. > > This is a regression in the HTTP header parsing fixes fir CRLF > added in the recent release round. > > I'm leaning towards cancelling the current set of releases to pick > up this fix. > > Thoughts? +1 for cancelling - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5nnSAACgkQHPApP6U8 pFhOZg/9GiyGE2nrmczvuFnse3jgKmPUVcShLRZPOwOrzUexD7RFQbS5kFYSm7E1 rQs6ZhtM3NHSx9A1DHiKbqv9Rf7sutZ+2Ia510EQQgRXnlMUaP8oSCbW7+wXwEFP CDXj/fQznxBlpTH38TnyUyu8FMXFZjxwFbtS3BO05jMVHtfTs+4/37yK2aee1Dbd 8VxQg7W7ZayEdix9hWk/PIhqswgwU0HhnJFTF6s6CGa4UkLcoUvNXyFPbgi0c7/c frLZiIW+j9JPRzEkDOi++TmtSm7Y//vTeKpGhKI8alWKp90u2xVkOKH/UX/J0QAw sOC09DJAF914LZvIXGk18xnyP2uiDNLpl2vEMK7tUeEl+7Gzard77DtBumyt6Yo6 CX+GgIH3MgNjt1IFoEmFwhunbZyn3bBaycyYj9xGfTvBetsSIhDzGN0heoFhZqbQ bbrPHFsDvtDFf1vuf6e+2aP/MRg32D0bZ5q4/Y4jQXbeChKYM67+NdY8r4vhbSRi 9TS2dNBGyK5eb0+eFPi0iwB6t8Eh5+mnd14RcCgNkAbBoDOazsP78ca+wavai740 9FFaBKKqb+/X34yhuZfvuWn3MxLWg4wObfdfgH5+2BFuBy4J2EEuKsKZ+pwWJ/DS SC0MMmyR00QhvJ1NRdXrFzrBmjqEjOSnzP3NeR5q8tCh2S/TfHE= =HDUa -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 64210] parsing request headers fail
На вт, 10.03.2020 г. в 14:52 Mark Thomas написа: > > On 10/03/2020 10:14, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 > > > > --- Comment #3 from Mark Thomas --- > > Thanks. I'm able to reproduce this. I'm working on some additional test cases > > and a fix. > > > > Moving to the dev@ list as this isn't really related to fixing this issue. > > This is a regression in the HTTP header parsing fixes fir CRLF added in > the recent release round. > > I'm leaning towards cancelling the current set of releases to pick up > this fix. > > Thoughts? +1 having in mind that I do not release Tomcat 7 as often as you release Tomcat 8.5 & 9 I'm ready to cancel Tomcat 7 voting. Regards, Violeta
Re: [Bug 64210] parsing request headers fail
On Tue, Mar 10, 2020 at 2:52 PM Mark Thomas wrote: > On 10/03/2020 10:14, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 > > > > --- Comment #3 from Mark Thomas --- > > Thanks. I'm able to reproduce this. I'm working on some additional test > cases > > and a fix. > > > > Moving to the dev@ list as this isn't really related to fixing this issue. > > This is a regression in the HTTP header parsing fixes fir CRLF added in > the recent release round. > > I'm leaning towards cancelling the current set of releases to pick up > this fix. > > Thoughts? > Agreed! > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Bug 64210] parsing request headers fail
On Tue, Mar 10, 2020 at 1:52 PM Mark Thomas wrote: > On 10/03/2020 10:14, bugzi...@apache.org wrote: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 > > > > --- Comment #3 from Mark Thomas --- > > Thanks. I'm able to reproduce this. I'm working on some additional test > cases > > and a fix. > > > > Moving to the dev@ list as this isn't really related to fixing this issue. > > This is a regression in the HTTP header parsing fixes fir CRLF added in > the recent release round. > > I'm leaning towards cancelling the current set of releases to pick up > this fix. > > Thoughts? > Ok, although it's probably not that common. Rémy > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: [Bug 64210] parsing request headers fail
On 10/03/2020 10:14, bugzi...@apache.org wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 > > --- Comment #3 from Mark Thomas --- > Thanks. I'm able to reproduce this. I'm working on some additional test cases > and a fix. > Moving to the dev@ list as this isn't really related to fixing this issue. This is a regression in the HTTP header parsing fixes fir CRLF added in the recent release round. I'm leaning towards cancelling the current set of releases to pick up this fix. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #3 from Mark Thomas --- Thanks. I'm able to reproduce this. I'm working on some additional test cases and a fix. -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #2 from Christian H. --- 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) -- 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
[Bug 64210] parsing request headers fail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #1 from Mark Thomas --- I'll take a look. What is triggering the headers to split across multiple TCP packets? That seems a little unusual. -- 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
