Am 03.12.2016 um 20:51 schrieb Mark Thomas:
On 03/12/2016 19:46, i...@flyingfischer.ch wrote:
Am 03.12.2016 um 20:29 schrieb Mark Thomas:
On 03/12/2016 13:28, i...@flyingfischer.ch wrote:
Between Tomcat 8.38 und 8.39 there seems to be a change in handling URL
parameters:

&paramxy=1|2

This will cause Tomcat to return a 400 error since 8.39. It is the
character "|" that causes the new behaviour. I suspect these changes:

https://github.com/apache/tomcat/commit/516bda676ac8d0284da3e0295a7df70391315360



First thing to know:

Is this intended?
Yes.

Second:

Anyway to restore the previous behaviour of 8.38 with a config option.
No, since the changes were in response to a security issue.

'|' is not a valid character in any part of an HTTP/1.1 request-target.
You need to fix whatever broken client is sending '|' without %
encoding it.

Mark
Unfortunately (for me) this will not be possible: This is a kind of a
proxy/rewriter situation where I cannot control the input being sent. I
need to be able to deal with any kind of request you will see out there
in the wild.
If a request contains and unencoded '|' in the request-target, the
correct way to deal with it is to return a 400.

Mark

Thanks for the reply. I do not question the behaviour to be correct. I still will need to deal with it. I need kind of a browser compliant behaviour, since this is an URL-Rewriter, running Tomcat in front. 400 is not an option in my scenario.

No better way than patch and rebuild?

Markus


I assume it is this part, responsible for the new behaviour?

             // Not valid for request target.
             // Combination of multiple rules from RFC7230 and RFC 3986.
Must be
             // ASCII, no controls plus a few additional characters excluded
             if (IS_CONTROL[i] || i > 127 ||
                     i == ' ' || i == '\"' || i == '#' || i == '<' || i
== '>' || i == '\\' ||
                     i == '^' || i == '`'  || i == '{' || i == '|' || i
== '}') {
                 IS_NOT_REQUEST_TARGET[i] = true;
             }

Do you see any better way to influence this, instead of patching and
rebuilding from scratch?

Thanks!
Markus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to