Re: Invalid character found in the request target
On 04/06/2024 15:37, Christopher Schultz wrote:
On 6/4/24 09:10, Chuck Caldarale wrote:
The problem is the { and } characters.
My reading of RFC 7230 is that { and } /should/ be allowed, but
Tomcat's code rejects them by default.
My reading is as follows:
RFC 9110:
http-URI = "http" "://" authority path-abempty [ "?" query ]
RFC 3968:
path-abempty = *( "/" segment )
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Neither '{' nor '}' are included in unreserved or sub-delims The are not
pct-encoded. Nor are they ':' or '@'. Therefore, there are not valid for
use in a segment. If you want to use them, they need to be pct-encoded.
While some of the text of RFC 3968, section 2.3 could be read as
suggesting other characters are included in unreserved, my reading of
that section is that the intended definition of unreserved is the
explicit definition I quoted above.
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 the request target
Chuck,
On 6/4/24 09:10, Chuck Caldarale wrote:
On Jun 4, 2024, at 06:07, Christopher Schultz
wrote:
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
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
request target [/sra_{xxx0---yy}/ ]. The valid
characters are defined in RFC 7230 and RFC 3986
The problem is the { and } characters.
My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's code
rejects them by default.
I think it depends on which part of RFC 3986 one looks at. Appendix A should
have the precise URI syntax, where the reserved and unreserved sets are defined
as follows:
unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims= ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Some ASCII characters, notably braces, are simply left out of either set here.
However, section 2.3 declares:
Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.
The use of “include” would seem to imply “not limited to”, but that’s not
explicitly stated here.
Nothing like a little ambiguity to keep things interesting…
Yup. RFC 3986 does not include the { character anywhere in the text. RFC
7230 mentions it as a character not allowed in "field values" which I
think only applies to headers unless you consider the "request line"
to be "header 0" or somesuch.
At any rate, characters such as { and } could be considered "dangerous"
and so, while I would argue the RFC doesn't prohibit them, Tomcat's
refusal to accept them under a default configuration is a reasonable
one... especially because you can simply re-enable them if your
application needs them.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Invalid character found in the request target
> On Jun 4, 2024, at 06:07, Christopher Schultz
> wrote:
>> 04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
>> 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
>> request target [/sra_{xxx0---yy}/ ]. The valid
>> characters are defined in RFC 7230 and RFC 3986
>
> The problem is the { and } characters.
>
> My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's code
> rejects them by default.
I think it depends on which part of RFC 3986 one looks at. Appendix A should
have the precise URI syntax, where the reserved and unreserved sets are defined
as follows:
unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims= ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims= "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Some ASCII characters, notably braces, are simply left out of either set here.
However, section 2.3 declares:
Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.
The use of “include” would seem to imply “not limited to”, but that’s not
explicitly stated here.
Nothing like a little ambiguity to keep things interesting…
- Chuck
> You can override this behavior by using the relaxedPathChars configuration
> attribute on your [1].
>
> -chris
>
> [1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
Re: Invalid character found in the request target
Christoph,
On 6/4/24 05:49, Christoph Kukulies wrote:
I'm getting these when startig tomcat9:
This is a request, not startup. But it's not important.
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
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
request target [/sra_{xxx0---yy}/ ]. The valid
characters are defined in RFC 7230 and RFC 3986
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:829)
Any clues?
The problem is the { and } characters.
My reading of RFC 7230 is that { and } /should/ be allowed, but Tomcat's
code rejects them by default.
You can override this behavior by using the relaxedPathChars
configuration attribute on your [1].
-chris
[1] https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Invalid character found in the request target
I'm getting these when startig tomcat9:
04-Jun-2024 09:49:11.448 INFO [http-nio-8080-exec-6]
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
request target [/sra_{xxx0---yy}/ ]. The valid
characters are defined in RFC 7230 and RFC 3986
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:502)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:829)
Any clues?
System is Ubuntu 64 22.04.
TIA,
Christoph
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Base64 would work. I would suggest the error log makes this explicit, so whoever looks at it knows how to deal with it and diagnose accordingly. *Manuel Dominguez Sarmiento* On 15/04/2020 15:37, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Manuel, On 4/13/20 15:13, Manuel Dominguez Sarmiento wrote: Thanks Mark. Including the request line (encoded if necessary to avoid issues with control characters) should definitely help. Yeah, I was thinking that maybe base64-encoding the request line and logging at DEBUG level would be best. I certainly don't want my log file filled-up with script kiddies all the time. - -chris On 13/04/2020 14:04, Mark Thomas wrote: On 13/04/2020 17:25, Manuel Dominguez Sarmiento wrote: Hi, we're reviewing our logs, are we are ocasionally getting the following stack traces: 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] 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 request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11In putBuffer.java:488) We understand this is a consequence of malformed requests, but we cannot seem to pinpoint the cause. It seems these are clients outside of our control (our servers are public-facing). The AccessLogValve does not log these requests, so we cannot figure out what the request line is. Is there any way logging could be improved in order to find out what is causing this? The stack trace indicates the problem is in the query string if that helps. Yes, I think we should be able to do something here. The tricky part is that as soon as an invalid character is detected we have to be a lot more careful as the payload could be malicious. I'm not sure if we'll be able to get anything into the access log but it should be possible to improve the error message and include the problematic request line in some form. You probably won't see the exact request line as we'll need to encoded things like control characters etc. I'll look at this for the May round of releases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6XVHoACgkQHPApP6U8 pFjIMw/+MwmQMAUxdPGaiQsr87bIOsJjstnZzdePXQkBArV4C4GkxmLA6Mm4lf19 uwFhH2IhlheR3XpL/BJZeRhUGZ6sQtYzmb6fz0kAiY8VlPlUMxCTHhGp0ClL0DjY cwaL4ZZNgQsySD2aUYOzTW6pByURUfVxgkpxCu4W46q7PZ6bOgULtFnTxwoHosCz PJOliwrVUkRFAHps/vaEM87Dye2h644nDYmYDFBClBjOCmnXmGO7nj/hgMvTzA4F guHS8Tulk0ZQc87f7mYsW5XXwff+Ux7AmMzzC8q2COKiMGQv/hSQLuugn14YcKXF tRHImGWdGkYM5GIgV3FO13pb6moO6PHurh9paW6ob/8vW0HHnTcRWrBBfaqtWswx W1Z6hV83bZjiHNVrm4ZG4mlIjWmIf/QRbnl+sZgIbrmOqOsCi5P2FR4Sj0aRrplN H60Y9c0IoWbaoA/eeLA5UdvynRyFq98E4j4nmyIQyjzvDk4udOQGeiRSqmB5fxEh 8MdR+xFjc8dcNb+/mbijBRXqqCbevp5J3zCuJVafCZoYa90fgQvd7LeRjv3OnkW+ NgNzt7XcoZsb/Jp/6gdqWtRqR87acwZc0mlG/Yss/g4/Zq1ZqeCrpHuKLCiVrP1A TFA0dNhuN+ur5WAwFrjawkdVyaCQB4I7IZxtrN2X2houuvY8da4= =d/gj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Manuel, On 4/13/20 15:13, Manuel Dominguez Sarmiento wrote: > Thanks Mark. Including the request line (encoded if necessary to > avoid issues with control characters) should definitely help. Yeah, I was thinking that maybe base64-encoding the request line and logging at DEBUG level would be best. I certainly don't want my log file filled-up with script kiddies all the time. - -chris > On 13/04/2020 14:04, Mark Thomas wrote: >> On 13/04/2020 17:25, Manuel Dominguez Sarmiento wrote: >>> Hi, we're reviewing our logs, are we are ocasionally getting >>> the following stack traces: >>> >>> 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] >>> 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 request target. The valid characters are defined in RFC >>> 7230 and RFC 3986 at >>> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11In putBuffer.java:488) >>> >> >>> >> >>> We understand this is a consequence of malformed requests, but >>> we cannot seem to pinpoint the cause. It seems these are >>> clients outside of our control (our servers are public-facing). >>> The AccessLogValve does not log these requests, so we cannot >>> figure out what the request line is. Is there any way logging >>> could be improved in order to find out what is causing this? >> The stack trace indicates the problem is in the query string if >> that helps. >> >> Yes, I think we should be able to do something here. The tricky >> part is that as soon as an invalid character is detected we have >> to be a lot more careful as the payload could be malicious. I'm >> not sure if we'll be able to get anything into the access log but >> it should be possible to improve the error message and include >> the problematic request line in some form. You probably won't see >> the exact request line as we'll need to encoded things like >> control characters etc. >> >> I'll look at this for the May round of releases. >> >> Mark >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6XVHoACgkQHPApP6U8 pFjIMw/+MwmQMAUxdPGaiQsr87bIOsJjstnZzdePXQkBArV4C4GkxmLA6Mm4lf19 uwFhH2IhlheR3XpL/BJZeRhUGZ6sQtYzmb6fz0kAiY8VlPlUMxCTHhGp0ClL0DjY cwaL4ZZNgQsySD2aUYOzTW6pByURUfVxgkpxCu4W46q7PZ6bOgULtFnTxwoHosCz PJOliwrVUkRFAHps/vaEM87Dye2h644nDYmYDFBClBjOCmnXmGO7nj/hgMvTzA4F guHS8Tulk0ZQc87f7mYsW5XXwff+Ux7AmMzzC8q2COKiMGQv/hSQLuugn14YcKXF tRHImGWdGkYM5GIgV3FO13pb6moO6PHurh9paW6ob/8vW0HHnTcRWrBBfaqtWswx W1Z6hV83bZjiHNVrm4ZG4mlIjWmIf/QRbnl+sZgIbrmOqOsCi5P2FR4Sj0aRrplN H60Y9c0IoWbaoA/eeLA5UdvynRyFq98E4j4nmyIQyjzvDk4udOQGeiRSqmB5fxEh 8MdR+xFjc8dcNb+/mbijBRXqqCbevp5J3zCuJVafCZoYa90fgQvd7LeRjv3OnkW+ NgNzt7XcoZsb/Jp/6gdqWtRqR87acwZc0mlG/Yss/g4/Zq1ZqeCrpHuKLCiVrP1A TFA0dNhuN+ur5WAwFrjawkdVyaCQB4I7IZxtrN2X2houuvY8da4= =d/gj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Thanks Mark. Including the request line (encoded if necessary to avoid issues with control characters) should definitely help. Getting through all the way to AccessLogValve would also help, but the most important bit is improving the error message. *Manuel Dominguez Sarmiento* On 13/04/2020 14:04, Mark Thomas wrote: On 13/04/2020 17:25, Manuel Dominguez Sarmiento wrote: Hi, we're reviewing our logs, are we are ocasionally getting the following stack traces: 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] 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 request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) We understand this is a consequence of malformed requests, but we cannot seem to pinpoint the cause. It seems these are clients outside of our control (our servers are public-facing). The AccessLogValve does not log these requests, so we cannot figure out what the request line is. Is there any way logging could be improved in order to find out what is causing this? The stack trace indicates the problem is in the query string if that helps. Yes, I think we should be able to do something here. The tricky part is that as soon as an invalid character is detected we have to be a lot more careful as the payload could be malicious. I'm not sure if we'll be able to get anything into the access log but it should be possible to improve the error message and include the problematic request line in some form. You probably won't see the exact request line as we'll need to encoded things like control characters etc. I'll look at this for the May round of releases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
On 13/04/2020 17:25, Manuel Dominguez Sarmiento wrote: > Hi, we're reviewing our logs, are we are ocasionally getting the > following stack traces: > > 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] > 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 request target. The valid characters are defined in RFC 7230 and RFC > 3986 > at > org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) > We understand this is a consequence of malformed requests, but we cannot > seem to pinpoint the cause. It seems these are clients outside of our > control (our servers are public-facing). The AccessLogValve does not log > these requests, so we cannot figure out what the request line is. Is > there any way logging could be improved in order to find out what is > causing this? The stack trace indicates the problem is in the query string if that helps. Yes, I think we should be able to do something here. The tricky part is that as soon as an invalid character is detected we have to be a lot more careful as the payload could be malicious. I'm not sure if we'll be able to get anything into the access log but it should be possible to improve the error message and include the problematic request line in some form. You probably won't see the exact request line as we'll need to encoded things like control characters etc. I'll look at this for the May round of releases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Hi, we're reviewing our logs, are we are ocasionally getting the following stack traces: 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] 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 request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) We understand this is a consequence of malformed requests, but we cannot seem to pinpoint the cause. It seems these are clients outside of our control (our servers are public-facing). The AccessLogValve does not log these requests, so we cannot figure out what the request line is. Is there any way logging could be improved in order to find out what is causing this? BTW, we're on Tomcat 9.0.33 *Manuel Dominguez Sarmiento*
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Sorry, I was not aware of that behaviour even when changing the subject. I'll send a new, separate, unrelated message. * Manuel Dominguez Sarmiento* On 12/04/2020 16:08, Mark Thomas wrote: Please don't hijack an existing thread. Start a new message for a new topic. (Replying to an existing message and changing the header is not sufficient.) Mark On 09/04/2020 21:05, Manuel Dominguez Sarmiento wrote: Hi, we're reviewing our logs, are we are ocasionally getting the following stack traces: 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] 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 request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) We understand this is a consequence of malformed requests, but we cannot seem to pinpoint the cause. It seems these are clients outside of our control (our servers are public-facing). The AccessLogValve does not log these requests, so we cannot figure out what the request line is. Is there any way logging could be improved in order to find out what is causing this? BTW, we're on Tomcat 9.0.33 *Manuel Dominguez Sarmiento* - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Please don't hijack an existing thread. Start a new message for a new topic. (Replying to an existing message and changing the header is not sufficient.) Mark On 09/04/2020 21:05, Manuel Dominguez Sarmiento wrote: > Hi, we're reviewing our logs, are we are ocasionally getting the > following stack traces: > > 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] > 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 request target. The valid characters are defined in RFC 7230 and RFC > 3986 > at > org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) > > at > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260) > at > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) > > at > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) > > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594) > > at > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) > > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) > > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > > > We understand this is a consequence of malformed requests, but we cannot > seem to pinpoint the cause. It seems these are clients outside of our > control (our servers are public-facing). The AccessLogValve does not log > these requests, so we cannot figure out what the request line is. Is > there any way logging could be improved in order to find out what is > causing this? > > BTW, we're on Tomcat 9.0.33 > > *Manuel Dominguez Sarmiento* > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Hi, we're reviewing our logs, are we are ocasionally getting the following stack traces: 09-Apr-2020 11:29:19.489 INFO [tomcat-http-81] 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 request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:488) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) We understand this is a consequence of malformed requests, but we cannot seem to pinpoint the cause. It seems these are clients outside of our control (our servers are public-facing). The AccessLogValve does not log these requests, so we cannot figure out what the request line is. Is there any way logging could be improved in order to find out what is causing this? BTW, we're on Tomcat 9.0.33 *Manuel Dominguez Sarmiento*
Re: Tomcat 9.0.31 Invalid character found in the request target
Hi,
On Wed, Mar 4, 2020 at 11:53 PM Bhavesh Mistry
wrote:
> Hi Tomcat Team,
>
> When there is invalid characters, it return error message with
> stacktrace as shown below. 1) is there any way to costmize error
> message ? if yes, please let me know.
>
> 2) Is there any way to spress stack-trace being shown on 400 bad request ?
>
> 3) Based on Accept header (application/json), can JSON error be
> constructed instead of html since client request application/json ?
>
This error is reported by ErrorReportValve.
You can disable it and/or replace it with one that reports the way you need
it.
Martin
> Thank you for help in advance.
>
> Thanks,
>
> Bhavesh
>
> Request :
> ===
> GET
> /API/?where=type*!*%3d1%20UNION%20SELECT%20version(),null,null,null=true=0=10
> HTTP/1.1
> Host: 10.192.58.135
> Connection: close*Accept: application/json*
> Sec-Fetch-Dest: empty
> X-Requested-With: XMLHttpRequest
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122
> Safari/537.36
> Sec-Fetch-Site: same-origin
> Sec-Fetch-Mode: cors
> Accept-Encoding: gzip, deflate
> Accept-Language: en-US,en;q=0.9
>
>
>
>
>
>
>
> Response :
> =
> HTTP/1.1 400
> Content-Type: text/html;charset=utf-8
> Content-Language: en
> Content-Length: 1988
> Date: Sun, 01 Mar 2020 06:09:41 GMT
> Connection: close
>
> HTTP Status 400 – Bad
> Requestbody
> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> {color:black;} .line
>
> {height:1px;background-color:#525D76;border:none;}HTTP
> Status 400 – Bad RequestType
> Exception ReportMessage Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986Description The server cannot or will not process
> the request due to something that is perceived to be a client error
> (e.g., malformed request syntax, invalid request message framing, or
> deceptive request
>
> routing).Exceptionjava.lang.IllegalArgumentException:
> Invalid character found in the request target. The valid characters
> are defined in RFC 7230 and RFC 3986
>
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)
>
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
>
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
>
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
>
> java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> java.basejava.lang.Thread.run(Thread.java:834)
> Note The full stack trace of the root cause is
> available in the server logs.Apache Tomcat
> Version X
>
Tomcat 9.0.31 Invalid character found in the request target
Hi Tomcat Team,
When there is invalid characters, it return error message with
stacktrace as shown below. 1) is there any way to costmize error
message ? if yes, please let me know.
2) Is there any way to spress stack-trace being shown on 400 bad request ?
3) Based on Accept header (application/json), can JSON error be
constructed instead of html since client request application/json ?
Thank you for help in advance.
Thanks,
Bhavesh
Request :
===
GET
/API/?where=type*!*%3d1%20UNION%20SELECT%20version(),null,null,null=true=0=10
HTTP/1.1
Host: 10.192.58.135
Connection: close*Accept: application/json*
Sec-Fetch-Dest: empty
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122
Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Response :
=
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1988
Date: Sun, 01 Mar 2020 06:09:41 GMT
Connection: close
HTTP Status 400 – Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestType
Exception ReportMessage Invalid character found in the
request target. The valid characters are defined in RFC 7230 and RFC
3986Description The server cannot or will not process
the request due to something that is perceived to be a client error
(e.g., malformed request syntax, invalid request message framing, or
deceptive request
routing).Exceptionjava.lang.IllegalArgumentException:
Invalid character found in the request target. The valid characters
are defined in RFC 7230 and RFC 3986
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.basejava.lang.Thread.run(Thread.java:834)
Note The full stack trace of the root cause is
available in the server logs.Apache Tomcat
Version X
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
On 13/03/17 15:23, Chandrashekar H.S wrote:
> Hi All,
> We have recently upgraded tomcat from 8.0.30 to 8.5.11.
>
> The tomcat 8.5.11 rejects the requested URI with below error.
> Requested URI:
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]
There are multiple potential problems:
- '+' is often used to encode ' ' so the telephone number may end up
with a leading ' ' rather than a leading '+'
- '[' and ']' should be encoded but - for now - Tomcat will let you get
away without encoding them
- '"' must be encoded and Tomcat will no longer accept it in unencoded
form due to CVE-2016-6816.
So '"' is your immediate problem and I don't see Tomcat optionally
allowing '"' due to the risk of different servers handling it different
ways creating the possibility request / response injection.
> The server accepts the request if the DQUOTE(") is replaced with text %22 as
> mentioned below
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
> 919742700996%22]
Note that you really need to encode '+', '[' and ']' as well.
> Please help me to fix this at the server side, since the client or URI
> requester is already in production/field.
The best solution is to fix the non-spec compliance in the client. As an
interim solution if you can find a lenient reverse proxy (generally all
HTTP servers are getting stricter over time so any solution you find may
only be temporary) then you should be able to fix the URL in the reverse
proxy before it is passed to Tomcat.
Patching Tomcat locally is another option but going that route needs
very careful consideration of the risks.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
First of all, sorry for the wrapping. Hint - turn on message wrapping
when writing to the mailing list.
Anyway, responses are at the end.
On 3/13/2017 8:23 AM, Chandrashekar H.S wrote:
> Hi All,
> We have recently upgraded tomcat from 8.0.30 to 8.5.11.
>
> The tomcat 8.5.11 rejects the requested URI with below error.
> Requested URI:
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]
>
> Mar 13, 2017 5:05:20 PM org.apache.coyote.http11.Http11Processor service
> INFO: 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 the request
> target. The valid characters are defined in RFC 7230 and RFC 3986
>at
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:471)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> The server accepts the request if the DQUOTE(") is replaced with text %22 as
> mentioned below
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
> 919742700996%22]
>
> Please help me to fix this at the server side, since the client or URI
> requester is already in production/field.
>
> Regards,
> Chandra
>
>
There are two ways to this issue.
1. Front your Apache Tomcat with Apache HTTPD and mod_jk
This is the least invasive to your code. However, it depends on Apache
HTTPD being lenient with RFC 7230 and RFC 3986. How ling that lasts is
up to that project.
a. Read the docs on how to configure Apache HTTPD / Tomcat / mod_jk
https://tomcat.apache.org/connectors-doc/
https://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
b. Use the excellent uriworkers.properties file found in the source at:
[distribution-root]/conf
where [distribution-root] is tomcat-connectors-1.2.42-src as I write this.
c. Note the defaults with respect to encoding
From the second link above:
Using JkOptions ForwardURIProxy, the forwarded URI will be partially
reencoded after processing inside Apache and before forwarding to
Tomcat. This will be compatible with local URL manipulation by
mod_rewrite and with URL encoded session ids.
JkOptions +ForwardURIProxy
This is the default as of version 1.2.24.
This may solve your problem. It solved ours, but our issue is with a
request parameter, not the entire URI.
Note that this is not a fix - and may NOT work for your use case.
2. Fix the code
If you are sending this GET via AJAX and javascript, there is a very
simple solution - encode the URI.
For an entire URL, the following function call is all you need:
var encoded_uri = encodeURI("unencoded uri);
Then use the encoded_uri value to make the request.
As I said above, our issue is with a request parameter, so the
developers will use the following:
var encoded_param = encodeURIComponent("unencoded request paramenter");
Then use the encoded_param value to make the request.
3. If you're not using AJAX / javascript
Then you have a lot of work to do, especially if method 1 above does not
solve your problem.
. . . just my two cents.
/mde/
signature.asc
Description: OpenPGP digital signature
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
Hi All,
We have recently upgraded tomcat from 8.0.30 to 8.5.11.
The tomcat 8.5.11 rejects the requested URI with below error.
Requested URI:
/poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]
Mar 13, 2017 5:05:20 PM org.apache.coyote.http11.Http11Processor service
INFO: 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 the request
target. The valid characters are defined in RFC 7230 and RFC 3986
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:471)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
The server accepts the request if the DQUOTE(") is replaced with text %22 as
mentioned below
/poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
919742700996%22]
Please help me to fix this at the server side, since the client or URI
requester is already in production/field.
Regards,
Chandra
