-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dennia,
On 1/6/20 07:09, Dennis Rech wrote: > we have an application where HTTP clients have a kind of unclean > way of submitting HTTP POST requests to our tomcat server for data > upload: The |POST| and |Host: xxx| part appears twice in the > request. Yuck. You mean like this? POST /foo HTTP/1.1 POST /foo HTTP/1.1 Host: foo.com Host: foo.com Content-Type: application/x-www-url-encoded Content-Length: 13 q=Hello World ? > Until now this didn't cause any problems with tomcat, but since > the latest release, Tomcat refuses to accept this message and > returns a 400 bad request immediately. Having two "host" headers should be okay. But repeating the request line is a clear violation of the HTTP spec that will be difficult to get over. I can't believe Tomcat ever allowed that, though it may have done so. > Unfortunately we'll not be able to change the client-side code. Is > there any way to tell the tomcat connector "ignore duplicate > headers" or so to make it work again? I guess the rewrite filters > for tomcat won't help as tomcat probably discards the incoming > message before handing it over to rewrite. Tomcat is responsible for reading the request line and routing the request to an application. If the request is broken badly enough, it won't be able to route. Headers are parsed as a part of that, and: POST /foo HTTP/1.1 is not a valid header for at least two reasons: 1. There is no : character (required, even when the header has no value) 2. There are spaces in the "name" (the name is everything before colon ) > Example request: > > |POST /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 POST > /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 [...rest of > the request is ok...] | This got word-wrapped. Was this? > POST /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 POST > /data/upload/test HTTP/1.1 Host: www.myhost.de:8180 [...rest of the > request is ok...] ? Yikes. What kind of client is this? > I wonder if there is a parameter for the |Connector| part in > server.xml or so to workaround this problem and restore the old > behaviour without downgrading. The good news is that the second POST could theoretically be considered to be a "broken" header and ignored. But Tomcat has been getting progressively more strict about what it will accept. There are all kinds of nasty ways to use malformed messages like this to confuse environments where e.g. a reverse-proxy and the origin server behave differently when they see requests like those above. It's better to just fail and fix the software. Why can't you fix the clients? Is this another case of internet-of-things garbage that can't practically be repaired? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4TYrsACgkQHPApP6U8 pFjNyRAAnebbKRBT99Zgk8vfnW4gUOGXYlgX8Xk2W8bUI7UPfqpphS6+t6Lwjti1 SBnS2qKuUXELMI7fca5Iq2NhKD9cCxZhuWrRQ6+jSZESaT6EEGeKYFaJ3Jtn5Dv6 ll6JKASuNTZtaDo+df0xYnDUvk6kT99aM3GY4FwYNLl/FIxv58D6YbUXN0TYLJQy 0IrnalQEQO8b8SiZcOPPAeA8ODZJQ37egAe3kP3xyWQPMl2u/966c0b711qZJ8JY D9JaR0fnVTZMHCHQmK9xLQKqra4T7uOv0UslQVheq47+SuXJea+qz1AmSJf3CU57 bL4zD7XVKkcC/bsOu1uWUSaKjN0KRnIqwxwo2trpPyoMpKJBGY26GdekpM/jeLdU eyh4I8f8fJkJ7GerLZrZSGxKIlTs86fzM96wr/P4pgSclBjgCO3RMf9phl7URmgp rIqT/xjwjIyLWqASWhXUyT7F5EHbZLSvPRbvklAib2pwQU2taaeT4cZaWGB4wfWw +CXQgGj7E4bWmTeq4LsG3skJEVcYcVN/AHSsgWQ5MFsjKx5pxJjq++P+ZooTqQOr GNexi9KVFilovrf1iStoP4OgdPcf2o1l0PXCpbKf5i2woJgRpFS/oSlOno0KQaol hvddVhzgL8PYrcWywdGEIbzI/9eQm54nqOAMRlpOCTOaDPzbeLc= =vIL0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
