Re: Invalid character found in method name. HTTP method names must be tokens
On Thu, Feb 7, 2019 at 6:57 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sean, > > On 2/7/19 14:01, Sean Dawson wrote: > > Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows > > (2016 Server and above) and here and there we see this in the > > logs... > > > > org.apache.coyote.http11.AbstractHttp11Processor.process Error > > parsing HTTP request header Note: further occurrences of HTTP > > header parsing errors will be logged at DEBUG level. > > java.lang.IllegalArgumentException: Invalid character found in > > method name. HTTP method names must be tokens at > > org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(Abstr > actNioInputBuffer.java:232) > > > > I can provide the full stack trace if needed. But we've determined > > it arises due to requests like this (from the access logs)... > > > > "-" 400 - > > > > I don't know how that happens. Maybe hacking attempt? > > What is the source IP? Many monitoring systems and load-balancers use > weird requests like that, so it might not be an attack. > > I think it was North or South Korea, or China. It was not from somewhere we have customers. Thanks to you and Mark for your replies. > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcxe0ACgkQHPApP6U8 > pFjc3xAAvh/9tv/0CiK42iM+/zq6Nwg2+OZiGKBr5YFC9kj77DlmTz2OZOXKDC8j > oSnhqEp7F1PTQ8vAtUJqCcTkrA/8Ul37mn4oOw8zmSowkQcofhDiMIzo0DwTXGmQ > uJHwKfrwNcb480bF3PhQAydzLN+BsSbmJVMl2YKbpJ9VALj1pG3uqQ9r3/C7hM5a > 6oJkqOLT/9EM8HW5Nu5InlMz6R+j0sNTZEAQhwYBY3S+tNHatQi5j7BXZbKu9J05 > M3UIe49nTYa45FjdybFPRJ5dy9JK4UZPwZGXCgqu4zrKX3XhgIS8LM0EZgN8M92E > IUuIW9ZdbaSB2I4BJUSQu8mrBJYpJJJnM8Ku4oFuh0/YxITniTdykBr+SblAIV4t > fb9aCvWysw/A/LKLvt/8I0Xgxqn1Vxw86iFXIDD4k/Q6hgB8nZPdCzAIt4fvUiwP > zVdv2FzBI1YPpjXF77GMPNamEa711UxsjxlYRkErULwUkhopd+khM0/3QYhgIONw > xCEeAiBQ85h3XnkgQqz/unecAkTi7s7yi09DBHCk52I4LW7/ZlT0jtjelVA/seCa > +Tk2r5xvxhrOJn4wiyTCnLxV0YEucQzZVNErH0NB9Kl2UstaM/bsDNGEJT7HR+QK > egD2Zm89nrwzX+EVS++T7SxX6r1EjZV32Qn5t3jpr2d/djmHGEM= > =jeRq > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Sorry for a rather rude intrusion. On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz wrote: > Chunked encoding is like sending a bunch of small HTTP message-pieces > (I have to be careful about my wording here, since "part" actually > means something in multipart messages May be just "chunks"? :) > Then, you send each chunk with a chunk size (in decimal bytes), a CRLF > pair, then your content, and another CRLF pair. The final chunk has a > length of 0 (zero): > > 32 > [32 bytes of data] > 128 > [128 bytes of data] > 0 Chunk sizes are expressed in hexadecimal notation, though, not decimal. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hi Chuck, Thank for your answer and details explanation. We have requested our customer to fix the wrong client. Are there any logs we can see if the content length does not match? Once again thanks for your help! Thanks, Bhavesh On Thu, Feb 7, 2019 at 4:03 PM Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length > Corrupting > > Parsing logic for Subsequent Request > > > I am stating following when you have request/response on the same TCP > > connection. for example, > > > My understanding (please correct me if my wrong): > > It's wrong. All TCP traffic, including HTTP requests, is a stream of > bytes. > There are no indications where one request ends and another starts other > than the content length in each request. If the malformed request > specifies > a length smaller than the actual content size, the next request will appear > to start somewhere in the content stream. Similarly, if the > request-specified content length is larger than the sent size, the > connector > consumes part of the next request as the content of the prior. There is no > way for a server to correct this client misbehavior, other than by the > server administrator disabling keep-alive - with serious performance > impacts > for well-mannered clients. Fix your broken client. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 19:11, Christopher Schultz wrote: > The Content-Length of the PUT request says "I'm going to send 128 > bytes". The server is required to accept exactly 128 bytes, no more > no less. There is another option, here, but also requires that the client still not be broken. Instead of guessing at the Content-Length and then being wrong about it, you can use "chunked" encoding. Chunked encoding is like sending a bunch of small HTTP message-pieces (I have to be careful about my wording here, since "part" actually means something in multipart messages), each with its own Content-Length . First, you send the request like this: PUT /foo/bar HTTP/1.1 Host: example.com Connection: keep-alive Transfer-Encoding: chunked Then, you send each chunk with a chunk size (in decimal bytes), a CRLF pair, then your content, and another CRLF pair. The final chunk has a length of 0 (zero): 32 [32 bytes of data] 128 [128 bytes of data] 0 (this is the end of the message) This is great for streaming, because you might not know the size of the content before you have generated it all. Buffering the whole message might be impractical. If the client's problem is that it's not sure what the Content-Length should be until the message is sent, then you can use chunked encoding to solve that problem. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyu8ACgkQHPApP6U8 pFhTqg/+Jepl5JnlqViLSh15wyFBYwnBWEiR+d+12B6+21XtJP14yIaw6pnCp0FW cc/SkLeUl4qywcqRp0f3af8Ub3hb9tE7VB8kMwGiNinUvWp0oDe6kRh8fBBXpHPo Q/0Sk0OtZS1cHZt2zmzFe5ml8iWn86YPOUVBKuFRCt9yo8630HG/EVD8TZ181FyJ JbySM+dfkQkhGhow6T59YMR0MxH0FembPnXQ3PQu8NSpmJ+r/7cAbnI0emmNjbNj xne956Wfb9gIINZI7ch7dmpJcwC4yX7jAibt2f/OFwQ1hrp8XFUPBZpvEjEH2JDp Y0+wxJ2pAaedqaLwtkob4xo+R6ZGYuyNEn43jM56CqIZV1qfUhVquUTaWkLi6uKy lwyHTaHxwKQPhdu6y7qQ+aZfoOp6/TLz5Os6OkjTEbixY120jrTPx1FTvq8rSI07 K3V4FvvCQz7cmfv2ya0aUBKnvCT+LytWKDfdLye8TRX0y8QFVC1n+8mGOEdL1vcl SPa/tCXtmhpJ/LS+n+fQPsqhV+niLc2fFhgUeVZGDv/uFo3BH/8rOCLJLo7N5jg3 GXRoLql0NQX2amdkbzPniY4+mvw/8lRwZeH+4JPfJeBeAIfhY4hIb1taNreTcEN7 sPZAl29SogZuARJG8ch9ZJkV8gfpGjZebfgzJLSMh3g7aIOHA9I= =ZG7h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bhavesh, On 2/7/19 18:40, Bhavesh Mistry wrote: > Hi Mark, > > I understand what you are stating the root of issue originated with > the client (wrong client). I am stating following when you have > request/response on the same TCP connection. for example, > > My understanding (please correct me if my wrong): > > Client ---SAME TCP > SOCKET--Server 1)PUT API > Content-Lenght: 419 2)server reads header and content body > > Response 2XX > > 3)Client Read response. > > 4)Client SEND GET Request > > GET API HTTP1/1.1 > > 5) Server reads it (now tomcat reads request GET request due to > the position of previous wrong content) CAN reset position of > reading here? No, Tomcat cannot do this. How does Tomcat know that the previous request has actually NOT ended? What happens if the request looks like this: PUT /foo/bar Host: example.com Connection: keep-alive Content-Length: 128 [64 bytes of whatever] GET /goo/bar Host: example.com Connection: keep-alive Content-Length: [...] That looks like two requests, but it's only one. Why? Because the Content-Length is (in this case, intentionally) wrong. The Content-Length of the PUT request says "I'm going to send 128 bytes". The server is required to accept exactly 128 bytes, no more no less. (Most servers will fail due to a timeout if the content is too *short* and the end of the message never arrives.) That 128 bytes extends beyond the 64 bytes actually sent and into the "next" request. There is no magic "end of file" byte that the client can send to say "yes, I know I said I was going to send you 128 bytes but I changed my mind at the last second and well, sorry". That just doesn't exist in HTTP. The same is true with a pair of requests like this: PUT /foo/bar Host: example.com Connection: keep-alive Content-Length: 32 0123456789abcde 0123456789abcde 0123456789abcde 0123456789abcde GET /goo/bar Host: example.com Connection: keep-alive Content-Length: [...] That's two requests, but the second request starts with the text "0123456789abcde" and not "GET /foo/bar", because the first request sent too much data. The server is *required* to stop after Content-Length bytes, full stop. It is NOT in the spec that the server should ignore text in a request that looks like garbage until it sees something like "GET "... > 6) The server sends 400 with a close connection. 7) Client Read > response. > > So, if you look request/response model, how can tomcat read ahead > on PUT call on a socket the data is not there? It's not reading "ahead". The data is already there, and it looks like a pipelined request from the client. Your problem is that you are thinking that the software is smarter than it is. Just because it's obvious to YOU what is going on doesn't mean that the HTTP specification agrees with your opinion about how things should work. I often call this type of thing "do-what-I-mean semantics". It generally means that the person who wants a job done can't articulate exactly how to do it with instructions for all the edge cases and so they just say "I want it to do the right thing all the time" -- usually by reading the mind of the user. It's tough to implement requirements like that. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcyTMACgkQHPApP6U8 pFiiOg/+LYfuwLdumv9JKCmSU2cSCOt4sAOivGwI3YS+XLX2RUy04GIpYEHQm6kb xHEOmo2krIhnSGqjnZnWJtsJdqlSHxLNtBu53pXxKa72fq6GtsGweCzDqxZUmvS5 iZxKIfSBMqdN8urg8zBTp7WlrP2Gu97F/5XvN9jTX5cgA6FbgHkfhkq0m34rM43K iQ7KetqMzgwVX4kVG9VEt3jJv/1cNNfHIZlhDU2RRlFh3ZV0S0eXnbjDE80jcsfI OkWQDKhqnRKMTunvzYaZ6aCsweQl7VVcw+QQRu8n/LMtvt85p/WVI6sMR//Kjl+T ij+l9v8GVbEFfmAK034hbQCfb+7x/0HH6uEA4U0nAoa090fIQLFk8aScy2gTRnaW 25dJ3kEnqGiD90mGsEpuyTD+kWjW6VtRk0XYxaPmCCXODAiPHPsvTNRYa40V6IJh h3lAVpE3/LGpWgGnjNTcw/yXpRYC33xg0B8HPWdJWB+1EK2IpKcfrIp159vPt5YJ V2ZABGVkd3kQ8qgpCCi7ibM4mIoI6RJrRJddXb2h2U8mhDn7ZaMFFGnaNJZi+rej JGdc0or9av/tZLKQLGYZlYSyU2yw8b3yCXApxjH4uC61mIl6pXjNmI4r1EMHd+58 SmH8dWU5vfXmFwRYr727Zp6NMioqldEM8ET2V1xi8UWPYVM1A0s= =jEde -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
> From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com] > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting > Parsing logic for Subsequent Request > I am stating following when you have request/response on the same TCP > connection. for example, > My understanding (please correct me if my wrong): It's wrong. All TCP traffic, including HTTP requests, is a stream of bytes. There are no indications where one request ends and another starts other than the content length in each request. If the malformed request specifies a length smaller than the actual content size, the next request will appear to start somewhere in the content stream. Similarly, if the request-specified content length is larger than the sent size, the connector consumes part of the next request as the content of the prior. There is no way for a server to correct this client misbehavior, other than by the server administrator disabling keep-alive - with serious performance impacts for well-mannered clients. Fix your broken client. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. smime.p7s Description: S/MIME cryptographic signature
Re: Invalid character found in method name. HTTP method names must be tokens
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 2/7/19 14:01, Sean Dawson wrote: > Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows > (2016 Server and above) and here and there we see this in the > logs... > > org.apache.coyote.http11.AbstractHttp11Processor.process Error > parsing HTTP request header Note: further occurrences of HTTP > header parsing errors will be logged at DEBUG level. > java.lang.IllegalArgumentException: Invalid character found in > method name. HTTP method names must be tokens at > org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(Abstr actNioInputBuffer.java:232) > > I can provide the full stack trace if needed. But we've determined > it arises due to requests like this (from the access logs)... > > "-" 400 - > > I don't know how that happens. Maybe hacking attempt? What is the source IP? Many monitoring systems and load-balancers use weird requests like that, so it might not be an attack. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcxe0ACgkQHPApP6U8 pFjc3xAAvh/9tv/0CiK42iM+/zq6Nwg2+OZiGKBr5YFC9kj77DlmTz2OZOXKDC8j oSnhqEp7F1PTQ8vAtUJqCcTkrA/8Ul37mn4oOw8zmSowkQcofhDiMIzo0DwTXGmQ uJHwKfrwNcb480bF3PhQAydzLN+BsSbmJVMl2YKbpJ9VALj1pG3uqQ9r3/C7hM5a 6oJkqOLT/9EM8HW5Nu5InlMz6R+j0sNTZEAQhwYBY3S+tNHatQi5j7BXZbKu9J05 M3UIe49nTYa45FjdybFPRJ5dy9JK4UZPwZGXCgqu4zrKX3XhgIS8LM0EZgN8M92E IUuIW9ZdbaSB2I4BJUSQu8mrBJYpJJJnM8Ku4oFuh0/YxITniTdykBr+SblAIV4t fb9aCvWysw/A/LKLvt/8I0Xgxqn1Vxw86iFXIDD4k/Q6hgB8nZPdCzAIt4fvUiwP zVdv2FzBI1YPpjXF77GMPNamEa711UxsjxlYRkErULwUkhopd+khM0/3QYhgIONw xCEeAiBQ85h3XnkgQqz/unecAkTi7s7yi09DBHCk52I4LW7/ZlT0jtjelVA/seCa +Tk2r5xvxhrOJn4wiyTCnLxV0YEucQzZVNErH0NB9Kl2UstaM/bsDNGEJT7HR+QK egD2Zm89nrwzX+EVS++T7SxX6r1EjZV32Qn5t3jpr2d/djmHGEM= =jeRq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: current best practices for Tomcat with SSL on port 443
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Garret, On 2/7/19 12:22, Garret Wilson wrote: > On 2/7/2019 3:13 PM, Christopher Schultz wrote: >> … Have a look at this presentation: >> https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encr ypt >> >> %20Apache%20Tomcat.pdf > > The presentation gets two thumbs up, specifically: > > * Great corny grammar ambiguity joke on the title page. If you come to an upcoming ApacheCon, you can hurl rotten fruit at me in person! > * The inferred conclusion of the presentation is: "If I already > have enough complications in my life and I don't want more, I don't > want to try to use Let's Encrypt directly with Tomcat (and > especially not attempt to teach this to students), even if the > complications can be overcome." :D But it's nice and useful to know > what I'm avoiding by not going down that road. When drafting that presentation, I actually configured a production service running on Tomcat to use LE. It was less painful than I thought, honestly. (Actually, restarting the connector was a PITA, but things have improved in Tomcat since I wrote the original draft.) I would argue that adding Apache httpd into the mix (where is it not already there) is more complicated than using Let's Encrypt with Tomcat. Certainly if Apache httpd is already there, it's *way* easier to just add LE. But part of the reason I presented that material was so that someone who works on one of the various certbot-type things would develop a plug-in that makes configuring Tomcat as easy as configuring httpd. Romain Manni-Bucau from the TomEE project built a Tomcat component that does LE for you. It's an inside-out approach, as opposed to an outside-in approach like I took in my presentation. YMMV. You can find his project here on GitHub: https://github.com/rmannibucau/letsencrypt-manager Good luck, and thanks for using a free and open-source product like Tomcat in your class. If anyone has any trouble with the documentation - -- especially a student -- encourage them to figure out what's going (possibly by posting a message here) and contribute a documentation patc h. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcxUgACgkQHPApP6U8 pFhr1Q/7Bs7SmH0xEoN7v/GJyErwvom8TD4GwdhoOtfQmZWrl8C84ByqBCfo1vVw EV7nvauRchPI6FXz7RobJPcUGUMGvH7srnjsMGA2U+sF3SAUkebK9XXT6jlkeOi6 t3wTi206BCThOZV5D0w7+ouKL5nBUAtZsqFyyD8i/qvfvNg3tFrDqF4cNcZwZLU7 CBfAc33GBuMwF2dlsQL0TvZEphSlZOYweRRVA0TlZXAGnF0VZypjFFvQhvqT105G kXBrufJg003zBQQJ7NzznYmqz0zvg1wM0CkeEVkFNbYcPiY4QNtXKtU9fNKP6PQx mla/VODbDuO/BzJfSXj6tHdT8RmVu1Iwp8k7CBFCATi3u2VFrdxoOKBIYumyj2gN rBJHxtmJkWOdypFz1sHbI89vuxrxpoJ2NmidZ1GyGlbsPoTky4DQYAVX7+b2Nuxi 92F1IPJtswykh1X6eB5Dx76ZiBExysj/DiJRxdmH2Ib6hgZOJHNnspVsb0m5voHH La3YhokS6YVxLYQRfOC0OorEuwgd3+l8GbI7UpitU9Rb4dZ7fjrQSz9v2Y+KKuk3 /J0q08RQd08GzJfW00YRIjCvRSETyQOqt/Xe6ji7sNFX/6v47ddw5YfvbCLXKOQd MLeQGbG3z6NnfwyP2d66J9f+vEEiGLeaAQDhTMpkTzDZyd+Qb5g= =oi/V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hi Mark, I understand what you are stating the root of issue originated with the client (wrong client). I am stating following when you have request/response on the same TCP connection. for example, My understanding (please correct me if my wrong): Client ---SAME TCP SOCKET--Server 1)PUT API Content-Lenght: 419 2)server reads header and content body Response 2XX 3)Client Read response. 4)Client SEND GET Request GET API HTTP1/1.1 5) Server reads it (now tomcat reads request GET request due to the position of previous wrong content ) CAN reset position of reading here? 6) The server sends 400 with a close connection. 7) Client Read response. So, if you look request/response model, how can tomcat read ahead on PUT call on a socket the data is not there? Thanks, Bhavesh On Thu, Feb 7, 2019 at 1:51 PM Mark Thomas wrote: > On 07/02/2019 20:05, Bhavesh Mistry wrote: > > Hi Mark, > > > > There is no way to validate the END of a request for PUT call and if > > Content-Lenght does not match what client had sent payload body then > > rejected it and reset position. > > You can't do that. The only way to determine how much data to expect is > from the content-length header. The server has no way to determine (with > any certainty) that the client has stopped sending the previous request > body (or hasn't sent any body at all) and is starting to send a new > request. > > > > > If content length does match then reject PUT request, > > Not possible. > > > and then close the > > connection for PUT call not for subsequent request. How can you read > > ahead from TCP socket that does not have data yet for the next request? > > The server is going to do a blocking read (this is Servlet I/O so it is > blocking) for more data. Again, the server has no way of knowing that > the data that arrives is for a new request rather than the request body > it was expecting. > > > It > > request/response model so PUT request processed with wrong content length > > should not impact the next request. > > HTTP doesn't work like that. > > > Another server like Jetty has no issue. > > The only way to guarantee that is to disable HTTP keep-alive. And I > would be amazed if the Jetty folks did that by default. > > I suspect what you are seeing are the effects of different read > timeouts. If the connection times out waiting for the client to send the > data *before* the client tries to send the next request you'll get the > behaviour you describe. > > The problem is that the server can't differentiate between slow clients > and misbehaving clients so by lowering the timeout to work-around the > broken clients you may end up breaking slower clients unintentionally. > > As I said, your best solution is to fix the broken client. > > Mark > > > > > Our use case: > > Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring > boot). > > > > The failure on the SAME TCP occurs at tomcat, not at Jetty for the same > TCP > > connection. > > > > > > Thanks, > > Bhavesh > > > > > > On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas wrote: > > > >> On 07/02/2019 18:48, Bhavesh Mistry wrote: > >>> Hello Tomcat Developers, > >>> > >>> I have a unique situation about HTTP Protocol PAYLOAD parsing and > >>> Content-Length Header. > >> > >> There is nothing unique here. > >> > >>> When PUT/POST Content-Length is NOT correct > >>> (client send wrong Content-Lenght), the tomcat is able to parse the > >>> request and respond to request with 2xx but subsequent on SAME TCP > >>> connection fails with corrupted HTTP HEADER. > >> > >> As expected. > >> > >> Tomcat can't read minds. If the content length header is not correct, > >> Tomcat can't correctly identify the end of the request so it is going to > >> read too much / too little and - on a keep-alive connection - the next > >> request is going to fail. > >> > >> There is nothing unusual about this. > >> > >> There is no Tomcat bug here. > >> > >> You need to fix the broken client so the content-length is correctly > set. > >> > >> You could disable keep-alive connections. That would limit the failures > >> to the faulty requests but at the cost of reduced performance. > >> > >> Mark > >> > >> - > >> 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 > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
On 07/02/2019 20:05, Bhavesh Mistry wrote: > Hi Mark, > > There is no way to validate the END of a request for PUT call and if > Content-Lenght does not match what client had sent payload body then > rejected it and reset position. You can't do that. The only way to determine how much data to expect is from the content-length header. The server has no way to determine (with any certainty) that the client has stopped sending the previous request body (or hasn't sent any body at all) and is starting to send a new request. > > If content length does match then reject PUT request, Not possible. > and then close the > connection for PUT call not for subsequent request. How can you read > ahead from TCP socket that does not have data yet for the next request? The server is going to do a blocking read (this is Servlet I/O so it is blocking) for more data. Again, the server has no way of knowing that the data that arrives is for a new request rather than the request body it was expecting. > It > request/response model so PUT request processed with wrong content length > should not impact the next request. HTTP doesn't work like that. > Another server like Jetty has no issue. The only way to guarantee that is to disable HTTP keep-alive. And I would be amazed if the Jetty folks did that by default. I suspect what you are seeing are the effects of different read timeouts. If the connection times out waiting for the client to send the data *before* the client tries to send the next request you'll get the behaviour you describe. The problem is that the server can't differentiate between slow clients and misbehaving clients so by lowering the timeout to work-around the broken clients you may end up breaking slower clients unintentionally. As I said, your best solution is to fix the broken client. Mark > > Our use case: > Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot). > > The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP > connection. > > > Thanks, > Bhavesh > > > On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas wrote: > >> On 07/02/2019 18:48, Bhavesh Mistry wrote: >>> Hello Tomcat Developers, >>> >>> I have a unique situation about HTTP Protocol PAYLOAD parsing and >>> Content-Length Header. >> >> There is nothing unique here. >> >>> When PUT/POST Content-Length is NOT correct >>> (client send wrong Content-Lenght), the tomcat is able to parse the >>> request and respond to request with 2xx but subsequent on SAME TCP >>> connection fails with corrupted HTTP HEADER. >> >> As expected. >> >> Tomcat can't read minds. If the content length header is not correct, >> Tomcat can't correctly identify the end of the request so it is going to >> read too much / too little and - on a keep-alive connection - the next >> request is going to fail. >> >> There is nothing unusual about this. >> >> There is no Tomcat bug here. >> >> You need to fix the broken client so the content-length is correctly set. >> >> You could disable keep-alive connections. That would limit the failures >> to the faulty requests but at the cost of reduced performance. >> >> Mark >> >> - >> 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
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hi Mark, There is no way to validate the END of a request for PUT call and if Content-Lenght does not match what client had sent payload body then rejected it and reset position. If content length does match then reject PUT request, and then close the connection for PUT call not for subsequent request. How can you read ahead from TCP socket that does not have data yet for the next request? It request/response model so PUT request processed with wrong content length should not impact the next request. Another server like Jetty has no issue. Our use case: Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot). The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP connection. Thanks, Bhavesh On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas wrote: > On 07/02/2019 18:48, Bhavesh Mistry wrote: > > Hello Tomcat Developers, > > > > I have a unique situation about HTTP Protocol PAYLOAD parsing and > > Content-Length Header. > > There is nothing unique here. > > > When PUT/POST Content-Length is NOT correct > > (client send wrong Content-Lenght), the tomcat is able to parse the > > request and respond to request with 2xx but subsequent on SAME TCP > > connection fails with corrupted HTTP HEADER. > > As expected. > > Tomcat can't read minds. If the content length header is not correct, > Tomcat can't correctly identify the end of the request so it is going to > read too much / too little and - on a keep-alive connection - the next > request is going to fail. > > There is nothing unusual about this. > > There is no Tomcat bug here. > > You need to fix the broken client so the content-length is correctly set. > > You could disable keep-alive connections. That would limit the failures > to the faulty requests but at the cost of reduced performance. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
On 07/02/2019 18:48, Bhavesh Mistry wrote: > Hello Tomcat Developers, > > I have a unique situation about HTTP Protocol PAYLOAD parsing and > Content-Length Header. There is nothing unique here. > When PUT/POST Content-Length is NOT correct > (client send wrong Content-Lenght), the tomcat is able to parse the > request and respond to request with 2xx but subsequent on SAME TCP > connection fails with corrupted HTTP HEADER. As expected. Tomcat can't read minds. If the content length header is not correct, Tomcat can't correctly identify the end of the request so it is going to read too much / too little and - on a keep-alive connection - the next request is going to fail. There is nothing unusual about this. There is no Tomcat bug here. You need to fix the broken client so the content-length is correctly set. You could disable keep-alive connections. That would limit the failures to the faulty requests but at the cost of reduced performance. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Invalid character found in method name. HTTP method names must be tokens
On 07/02/2019 19:01, Sean Dawson wrote: > Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows (2016 > Server and above) and here and there we see this in the logs... > > org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP > request header > Note: further occurrences of HTTP header parsing errors will be logged at > DEBUG level. > java.lang.IllegalArgumentException: Invalid character found in method > name. HTTP method names must be tokens > at > org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:232) > > I can provide the full stack trace if needed. But we've determined it > arises due to requests like this (from the access logs)... > > "-" 400 - > > I don't know how that happens. Maybe hacking attempt? > > If I use Google, all I can find for the exception is that someone is > attempting to use https instead of http (their server is configured for the > latter only). We're using https on our server. > > It's very difficult to search for the request line above. > > What is this from? Like the message says, someone submitted a request with an invalid HTTP method. Something like: AAA:XXX /index.html HTTP/1.1 Host: your.server.com etc. > Or at least, is there a way to stop the exception stack > from showing up in the logs? Thanks. -Dorg.apache.juli.logging.UserDataHelper.CONFIG=DEBUG_ALL moves all messages to debug level. NONE stops them completely. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Invalid character found in method name. HTTP method names must be tokens
Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows (2016 Server and above) and here and there we see this in the logs... org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:232) I can provide the full stack trace if needed. But we've determined it arises due to requests like this (from the access logs)... "-" 400 - I don't know how that happens. Maybe hacking attempt? If I use Google, all I can find for the exception is that someone is attempting to use https instead of http (their server is configured for the latter only). We're using https on our server. It's very difficult to search for the request line above. What is this from? Or at least, is there a way to stop the exception stack from showing up in the logs? Thanks.
Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request
Hello Tomcat Developers,
I have a unique situation about HTTP Protocol PAYLOAD parsing and
Content-Length Header. When PUT/POST Content-Length is NOT correct (client
send wrong Content-Lenght), the tomcat is able to parse the request and
respond to request with 2xx but subsequent on SAME TCP connection fails
with corrupted HTTP HEADER.
For example, I do following raw HTTP Request to tomcat server with
Content-Lenght: 419 (but Client Does not POST content followed by GET
request it get corrupted) : If Content-Length is zero for PUT then
request works. I am attaching sample Spring boot App to reproduce
this issue. With text file and command ( *cat file | nc localhost 8448*)
Please get back to me ASAP. Should I file a bug ? Should PUT reuqest be
BAD REQUEST 400 instead of GET ?
*REQUEST:*
PUT /api/?msg=Test HTTP/1.1
User-Agent: Java/1.8.0_131
X-Real-IP: 96.118.243.182
id: 924
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601484
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9
X-Forwarded-For: 96.118.243.182
X-Forwarded-Proto: https
URI: /nextgen/templates/template-metadata/PostStaging-LBNNPACB81W/override
HTTP_METHOD: PUT
rollback-label: b3f8ec56-33b1-4b27-a64e-5c3d77041332
rollback-comment: ServiceTemplate_b3f8ec56-33b1-4b27-a64e-5c3d77041332
Content-Length: 419
Content-Type: application/json
Host: localhost:8448
Conection: Keep-Alive
GET /api/ HTTP/1.1
HTTP_METHOD: GET
X-Forwarded-For: 96.118.243.182
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
X-Real-IP: 96.118.243.182
X-Forwarded-Proto: https
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601497
override: override-with-referred-template
User-Agent: Java/1.8.0_131
rollback-label: adfb0689-062d-48a2-95ca-f8a9711858f7
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9
URI:
/nextgen/binddata/templateData/template/PostStaging-LBNNPACB81W/devicegroup/DeviceGroup-LBNNPACB81W
rollback-comment: ServiceTemplate_adfb0689-062d-48a2-95ca-f8a9711858f7
Host: localhost:8448
Connection: Keep-Alive
*RESPONSE:*BMs-MacBook-Pro:gs-spring-boot bmistry$ *cat /tmp/testbody.txt |
nc localhost 8448*
HTTP/1.1 200
Content-Type: application/json;charset=UTF-8
Content-Length: 34
Date: Fri, 01 Feb 2019 19:39:20 GMT
Greetings from Spring Boot ! Test
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 800
Date: Fri, 01 Feb 2019 19:39:20 GMT
Connection: close
HTTP Status 400 – Bad
Requesth1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestBMs-MacBook-Pro:gs-spring-boot
bmistry$
*ERROR LOGS:*
2019-02-01 11:39:20.387 DEBUG 14931 --- [nio-8448-exec-5]
o.a.coyote.http11.Http11InputBuffer : Received [PUT /api/?msg=Test
HTTP/1.1
User-Agent: Java/1.8.0_131
X-Real-IP: 96.118.243.182
id: 924
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601484
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9
X-Forwarded-For: 96.118.243.182
X-Forwarded-Proto: https
URI: /nextgen/templates/template-metadata/PostStaging-LBNNPACB81W/override
HTTP_METHOD: PUT
rollback-label: b3f8ec56-33b1-4b27-a64e-5c3d77041332
rollback-comment: ServiceTemplate_b3f8ec56-33b1-4b27-a64e-5c3d77041332
Content-Length: 419
Content-Type: application/json
Host: localhost:8448
Conection: Keep-Alive
GET /api/ HTTP/1.1
HTTP_METHOD: GET
X-Forwarded-For: 96.118.243.182
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
X-Real-IP: 96.118.243.182
X-Forwarded-Proto: https
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601497
override: override-with-referred-template
User-Agent: Java/1.8.0_131
rollback-label: adfb0689-062d-48a2-95ca-f8a9711858f7
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
Re: current best practices for Tomcat with SSL on port 443
On 2/7/2019 3:13 PM, Christopher Schultz wrote: … Have a look at this presentation: https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encrypt %20Apache%20Tomcat.pdf The presentation gets two thumbs up, specifically: * Great corny grammar ambiguity joke on the title page. * The inferred conclusion of the presentation is: "If I already have enough complications in my life and I don't want more, I don't want to try to use Let's Encrypt directly with Tomcat (and especially not attempt to teach this to students), even if the complications can be overcome." :D But it's nice and useful to know what I'm avoiding by not going down that road. Garret
Re: current best practices for Tomcat with SSL on port 443
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Garret, On 2/7/19 11:45, Garret Wilson wrote: > Hi, everyone. In the computer course I'm writing I'm using Tomcat > for the server. (Students learn how to set up CentOS and everything > from scratch. Currently the course has them using Tomcat running on > port 8080.) I'm going back to write the section on security. I want > students to learn to set up their web server to use SSL/TLS on port > 443, with HTTP port 80 redirecting to HTTPS port 443. This should > be a very basic, fundamental configuration, no? > > The last time I did this myself was about 10 or 15 years ago, when > I compiled Apache myself and put it in front of Tomcat using > whatever connectors (I'll have to go look at my configuration from > back then), purchasing outrageously priced SSL certificates and > installing them manually. How I'm sure things are greatly improved. > Recently I've set up Apache (I didn't have to compile it) hosting > static pages directly, and using Let's Encrypt (once I figured out > what I should be doing) for SSL was a breeze. It's working nicely. > So I assume I'd want to use Let's Encrypt in whatever solution I > prescribe to the students. > > So what is the best practice, straightforward, and simple setup > for Tomcat with SSL on port 443 (preferably using Let's Encrypt) > with HTTP port 80 forwarding to HTTPS port 443? Do I still need to > stick Apache (or Nginx?) in front of it? (The last I checked, > letting Tomcat use lower port numbers was a pain, and nobody seemed > to know an easy, straightforward way to do it.) > > Maybe this is a better question of Stack Overflow, but since the > experts are here and I'm already on the list, I thought I'd ask. > Thanks in advance! I'm really wanting to learn here. Have a look at this presentation: https://people.apache.org/~schultz/ApacheCon%20NA%202018/Let's%20Encrypt %20Apache%20Tomcat.pdf Definitely post back if you have any questions. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcZzUACgkQHPApP6U8 pFh2Tg//YcC/8iPC4yDN9zp43XWwmDbCL/eyNv+oU4R3u/UcxrEoTP6QTRXBQrth sDSwSQ05mrrAM72MhPJuUlcjof0UquHaj/OBBOeQlnw0W9U8gsbX6mWgPMkKNJH7 tNokwTnbLe8xXqmf/xU5OUEW4v/OiSl3MmFt3ZpbB7woKYNkadFCueU+xIpIz+OJ QGPWM9kLg5dyOkfHHpi+gIzEqsFVvF4eceHQhqSqx+QiVw4nky5kh/fNstxEF/cD NFBmR2tQIiHwv8CywOC9ngHABnCflzShPD5kg6S1WwiC9cvwNmEleOokqnHryali MAmqGZNo17eYqvACP1S8ZDpfDduVsV3+wPQToNgYhRQHSl461dRr8Iq8HMa67q6D 4tgTUmN0V7gkKhTU9CI6YLHOzXan9QKan29sX6rj9O2oXBqkkGDgk4T9E6M3PUbE tbzq07UMv/LLqr5wiyTfnfX9KLbgAVvuZLbCAe1Px7A8LDFDQUntwF7/4dG2IaII 556RCR7Rws0Gq2y6iV/HoEKtvAnErQaMDPHQiNkx7rVaXVU6npe6/1mtCpJbVduQ TshL7JQtWXiYdsSooRIiTglNT5WNmGBniy+LgT7JupJJABYj8OKP42X3ucEfracE LoL0/A2kiMj6NJATTruEkVAtX+PR5S0/x512jaHetDxd4Dov0Oc= =SaZ9 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TLS 1.0 and "HTTP Security Header Not Detected" on Tomcat 7, running under Java 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 2/6/19 12:21, James H. H. Lampert wrote: > Thanks. I do have some follow up questions > > On 2/6/19, 1:04 AM, Mark Thomas wrote: >> On the TLS Connector: >> >> sslEnabledProtocols="TLSv1.1,TLSv1.2" > > Ok. So the active connector we currently have for this particular > installation (which has multiple IP addresses, hence the "address" > clause) is: >> > protocol="org.apache.coyote.http11.Http11Protocol" >> address="REDACTED" maxThreads="150" SSLEnabled="true" >> scheme="https" secure="true" keystoreFile="REDACTED" >> keyAlias="REDACTED" >> >> ciphers="SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA" >> >> clientAuth="false" sslProtocol="TLS" /> > > So I can just add the sslEnabledProtcols clause to the end of > this? Be careful: specifying a specific list of cipher suites limits what the client+server will allow. You can handshake using TLSv1.2 but then use a crappy cipher which then actually reduces your security. For instance, the SSL_*CBC_SHA ciphers are all considered weak because of the use of CBC. https://crypto.stackexchange.com/a/52568 Unless you really need to be picky about the ciphers you support, you shouldn't use a very short list like this one you have here. When you upgrade from Tomcat 7, you should be able to use OpenSSL-style configuration, which means you don't have to list every single cipher suite you want to support -- you can say "anything that has EDCHE is cool" and let Tomcat figure out what the environment will support, for example. You can even say "anything but MD5" , etc. It's quite expressive and much better than individually whitelisting ciphers. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcZdgACgkQHPApP6U8 pFizZxAAsglgKwMO3aoLxqq+A4rWS8Qn7DKkBgfUGbU+2RXyl3vLhwclvtjoObsh Llvce9LCmjmrZY1yKZcNe8sTU4dAbXQcjGr/Db7uEL8FWVZ8eF5jHZj5lQIt3FxZ qQ7/aEsFgWTvAlRHM5nGv9mkYP0t7MyBSn3YI3xrIrtv5x0bn62jjJHEn9jg+pP9 BLPujVi3qEQMH6lQfd7PM9M3QfRyNyzPHmdt+7KIy53WTDWEYnMo2KuXX8lO3yY/ OUkSiCuSAl1KunHRkt2J70UrEwfgtcEsVi3ZTGgQiBv+GAmVCwPfdm4tsP+4Zxkk Fs0eVKpcD0rcL1mCA6Twmrm0k7qbN07j9fuTsU9N+wyTlyLazGioLshb9TSx4Vws aWtA9m/hfjjNgQXzzEDwrjod+RuN3cEDquHJVIdBh7fSqsz3uCrMYstb4aj36mFK IIqjOfnyqel2TYsGVuSQFCIcDRrjdGEb1Ut4S4WCWtXAnKTHI8jT5X5AVxnS+CEy 4f6A/a3adQAGIc43gMP9kQAPxQOsUphkGk2ryYV5asCg/MBIg2MCk8OV8jxd7i8S TXAe44jgrBQPeMiKARbqzzzdyzMiW1XM/a5YQA5KprndNJf+0/pHZjzXRAWY7c+s dTcIp27HHz12Yi3uAlryidEKEe/rZ7pNFE5zLVWJyxfxSncvBDs= =idYY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: current best practices for Tomcat with SSL on port 443
You can use apache with mod_jk and then just setup the ssl through apache and tomcat will use the 443 port through apache. If you want to use letencrypt you need to add JkUnMount for /.well-known/* directory so that when you run lets encrypt it can create and get to this directory through apache. John On Thu, Feb 7, 2019 at 9:45 AM Garret Wilson wrote: > Hi, everyone. In the computer course I'm writing I'm using Tomcat for > the server. (Students learn how to set up CentOS and everything from > scratch. Currently the course has them using Tomcat running on port > 8080.) I'm going back to write the section on security. I want students > to learn to set up their web server to use SSL/TLS on port 443, with > HTTP port 80 redirecting to HTTPS port 443. This should be a very basic, > fundamental configuration, no? > > The last time I did this myself was about 10 or 15 years ago, when I > compiled Apache myself and put it in front of Tomcat using whatever > connectors (I'll have to go look at my configuration from back then), > purchasing outrageously priced SSL certificates and installing them > manually. How I'm sure things are greatly improved. Recently I've set up > Apache (I didn't have to compile it) hosting static pages directly, and > using Let's Encrypt (once I figured out what I should be doing) for SSL > was a breeze. It's working nicely. So I assume I'd want to use Let's > Encrypt in whatever solution I prescribe to the students. > > So what is the best practice, straightforward, and simple setup for > Tomcat with SSL on port 443 (preferably using Let's Encrypt) with HTTP > port 80 forwarding to HTTPS port 443? Do I still need to stick Apache > (or Nginx?) in front of it? (The last I checked, letting Tomcat use > lower port numbers was a pain, and nobody seemed to know an easy, > straightforward way to do it.) > > Maybe this is a better question of Stack Overflow, but since the experts > are here and I'm already on the list, I thought I'd ask. Thanks in > advance! I'm really wanting to learn here. > > Best, > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
current best practices for Tomcat with SSL on port 443
Hi, everyone. In the computer course I'm writing I'm using Tomcat for the server. (Students learn how to set up CentOS and everything from scratch. Currently the course has them using Tomcat running on port 8080.) I'm going back to write the section on security. I want students to learn to set up their web server to use SSL/TLS on port 443, with HTTP port 80 redirecting to HTTPS port 443. This should be a very basic, fundamental configuration, no? The last time I did this myself was about 10 or 15 years ago, when I compiled Apache myself and put it in front of Tomcat using whatever connectors (I'll have to go look at my configuration from back then), purchasing outrageously priced SSL certificates and installing them manually. How I'm sure things are greatly improved. Recently I've set up Apache (I didn't have to compile it) hosting static pages directly, and using Let's Encrypt (once I figured out what I should be doing) for SSL was a breeze. It's working nicely. So I assume I'd want to use Let's Encrypt in whatever solution I prescribe to the students. So what is the best practice, straightforward, and simple setup for Tomcat with SSL on port 443 (preferably using Let's Encrypt) with HTTP port 80 forwarding to HTTPS port 443? Do I still need to stick Apache (or Nginx?) in front of it? (The last I checked, letting Tomcat use lower port numbers was a pain, and nobody seemed to know an easy, straightforward way to do it.) Maybe this is a better question of Stack Overflow, but since the experts are here and I'm already on the list, I thought I'd ask. Thanks in advance! I'm really wanting to learn here. Best, Garret - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: response sent before request
Hello Mark, Il giorno gio, 07/02/2019 alle 09.49 +, Mark Thomas ha scritto: > On 06/02/2019 17:27, Giuseppe Sacco wrote: [...] > > So, I wonder, what instructs tomcat to start parsing a request? Is > > it > > the newline inbetween the header and the body? How is it possible > > to > > explain this behaviour? > > A 500 response will result in the connection being closed. > > It sounds like something in an application is holding on to a > reference > to the request and/or the response for longer than it should. These > objects are recycled and re-used so retaining references to them will > cause problems. One of the first things to try is: > > -Dorg.apache.catalina.connector.RECYCLE_FACADES=true > > See > https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Secu > rity A few hours ago, we updated tomcat from 8.5.20 to 8.5.37 and it seems the problem is no more present. We will try it on a live environment in a few hours. Thank you, Giuseppe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: response sent before request
On 06/02/2019 17:27, Giuseppe Sacco wrote: > Hello, > I have a tomcat 8.5.20 installation that handle many applications. When > calling one of the URLs of a specific application, sometimes I get > a 500 http error. Please note that this it does not happens always. > > The connector uses SSL, so I setup wireshark and decrypted the traffic. > Finally I found this: an SSL stream that displays the response before > the request, i.e., this is what is shown as decrypted: > *** > HTTP/1.1 500 > Content-Type: text/plain > Content-Length: 57 > Date: Wed, 06 Feb 2019 15:23:46 GMT > Connection: close > > The call failed on the server; see server log for detailsPOST > /lnuiprod/gwtui/persist HTTP/1.1 > Host: srclnprod.mydomain.tld:8445 > Connection: keep-alive > Content-Length: 18118 > X-GWT-Module-Base: https://srclnprod.mydomain.tld:8445/lnuiprod/gwtui > X-GWT-Permutation: 8E921 > Origin: https://srclnprod.mydomain.tld:8445 > User-Agent: Mozilla/.36 > Content-Type: text/x-gwt-rpc; charset=UTF-8 > Accept: */* > Referer: https://srclnprod.mydomain.tld:8445/lnui/servlet/login > Accept-Encoding: gzip, deflate, br > Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7 > Cookie: JSESSIONID=B.2F£ > > 7|1|14|http... (body continues until the end of the stream) > *** > > I see the request in the valve log. I see an exception in the tomcat > log from a servlet that complains about an unparseable request. > > The servlet that logs the message is not the one associated to the URL. > I am not even sure it is from the same context. > > So, I wonder, what instructs tomcat to start parsing a request? Is it > the newline inbetween the header and the body? How is it possible to > explain this behaviour? A 500 response will result in the connection being closed. It sounds like something in an application is holding on to a reference to the request and/or the response for longer than it should. These objects are recycled and re-used so retaining references to them will cause problems. One of the first things to try is: -Dorg.apache.catalina.connector.RECYCLE_FACADES=true See https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Security Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat patch management and patching best practices
The Apache Tomcat project does not provide patches for individual issues and has no plans to change that. The simplest way to manage updates is to separate CATALINA_HOME and CATALINA_BASE as per http://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE or https://tomcat.apache.org/tomcat-9.0-doc/RUNNING.txt Upgrades then become a case of: Unpack new binary distribution Stop Tomcat Update CATALINA_HOME environment variable Start Tomcat Mark On 07/02/2019 02:52, John Larsen wrote: > Thats a really good question. We've simply replaced the entire tomcat > installation and then rerun auto config. > > Be nice if apache provided patches. > > John > > > On Wed, Feb 6, 2019 at 7:39 PM Murtaza Doctor wrote: > >> Dear Support, >> >> We request your help/advice for the Tomcat Patch Management. We have >> installed Tomcat server to host an application which is internally used in >> our organisation. We donot have any current process/procedure to patch >> Tomcat. So we are looking for your advice on this. >> >> Please address my below queries: >> >> 1) What is the best procedure/practice to keep Tomcat up-to-date with >> patches? >> >> 2) How frequently does Tomcat releases patches/updates? If patches are >> available, please advice the link to access the patches and its details >> (including steps to apply it) >> >> 3) Are separate patches released for security vulnerabilities fixed and bug >> fixed in Tomcat application server? >> >> Kindly advice. Your suggestion will help us in building our internal >> processes. Thanks. >> >> Kind Regards, >> Murtaza Doctor. >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTP2 with WebSockets
On 07/02/2019 00:31, Jesse Schulman wrote: > Is it possible for tomcat to run with HTTP2 and WebSockets on the same > connector? I have tried configuring it myself and looked for examples > without success. This works out of the box. I have confirmed the behaviour with my local build of 9.0.x but nothing has changed in this area for a number of releases. First you need an HTTP/2 capable connector. That means: Tomcat 8.5.x or Tomcat 9.0.x NIO or NIO2 + JSSE + Java 9 or later or APR/Native or NIO or NIO2 + OpenSSL (via Tomcat Native) If no explicit Java version is mentioned then any supported version of Java for the version of Tomcat being used is fine. Configure TLS. Browse to http://localhost:8443 Observe in browser that HTTP/2 is used Navigate to https://localhost:8443/examples/websocket/snake.xhtml and you'll see HTTP/2 being used for the static content and wss (not over HTTP/2) being used for the WebSocket traffic. All over the single TLS enabled connector listening on port 8443. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
