Hi Christopher,
Am 06.01.20 um 17:39 schrieb Christopher Schultz:
-----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
?
No, rather like that:
POST /foo HTTP/1.1
Host: foo.com
POST /foo HTTP/1.1
Host: foo.com
Content-[stuff] [...]
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.
I read in the changelog that since Tomcat 8.5.22 it will also reply with
Bad request 400 if there are two Host fields in the header. But I guess
the double "POST" is even worse.
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 )
Well, "POST"... is the actual request followed by the HTTP headers. POST
is not part of the actual header. Maybe I haven't pointed that out.
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?
Yes I copied it from a formatted document, the pipes probably indicate
that this text was preformatted in the original document, sorry. Also
the newlines are missing.
POST /data/upload/test HTTP/1.1
Host: www.myhost.de:8180
POST/data/upload/test HTTP/1.1
Host: www.myhost.de:8180
[...here comes the remaining header with Content-Length etc followed by the
body...]
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?
It's a remote unit transmitting data to a server using POST file uploads
with - obviously - a little bug in the firmware that builds the HTTP
request manually as there is no curl library for the unit etc. which can
be used to generate the requests.
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?
Something like that. The devices could be updated in theory but probably
not over-the-air and many of them are already deployed somewhere in the
"wild" so we don't have physical access to them anymore. Unfortunately
we did not notice that in the past as tomcat always accepted these
requests until the latest update for debian came out.
I totally agree that the best solution would be to let those devices
send proper HTTP protocol but I guess we'll have to find a workaround on
server-side.
- -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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
