Re: HTTPS Invalid character found in method name. HTTP method names must be tokens.
Java 10 - OK Java 11 Oracle or Adopt - Fail Chrome, Edge - OK Firefox 60, Internet explorer 11 - Fail Server is in our test environment on Linux. When I tryed to reproduce this bug on my computer (Windows 10), bug did not occure. On our test environment it occures irregularly, a few tests pass and then a test fail. We will try update Linux on the server and use new tomcat 9.0.17. Do you know, why request in tomcat contains two packets together?: javax.net.ssl|DEBUG|34|https-jsse-nio-8444-exec-1|2019-03-18 15:40:31.201 CET|SSLEngineInputRecord.java:177|Raw read ( : 17 03 03 01 AB 00 00 00 00 00 00 00 01 19 58 D0 ..X. 0010: 9C F7 . encrypted application data ... 01A0: 95 E4 79 AF B8 5C CE C2 36 CB 95 F3 34 FE D3 23 ..y..\..6...4..# 01B0: 14 03 03 00 01 01 16 03 Change cipher spec ... ) When it is separated to two requests, all is ok, but when it is in one request, error occures. Jan Dne 19.03.2019 v 13:26 Mark Thomas napsal(a): Thanks for all that data. Very strange. It is as if the server picks the wrong key to decrypt with. Given you can reproduce this, I suggest trying different versions of Java on the server to see if you can determine a pattern. Also, if you are able to provide a test case that reliably demonstrates this bug, that would be extremely helpful too. Mark On 19/03/2019 09:25, Jan Vomlel wrote: Hello Mark, communication is on https://drive.google.com/open?id=12ZqbgKkHzGKzXk19ssIcJMX6iQBUE4fQ file 18-03-2019-3-filtered-one-connection.pcapng There is also full communication log from wireshark and catalina.out. Critical packet contains data: 17 03 03 01 AB 00 00 00 00 00 00 00 01 19 58 D0 In wireshark it is followed by Change cipher spec, in catalina out are this packets together in one request. Client was firefox 60.5.2esr. Thanks, Jan Dne 18.03.2019 v 12:08 Mark Thomas napsal(a): On 18/03/2019 10:49, Jan Vomlel wrote: Thank you Mark. I enabled the logger org.apache.coyote.http11. I cannot paste line org.apache.coyote.http11.Http11InputBuffer.parseRequestLine here, because it contains not printable characters and copy paste doesnot work. It seems like bug in tomcat or jdk. ??? The client appears to be sending some unexpected binary data. It could be something TLS related although I'd expect JSSE to just handle that. It could be part of a previous request but that would mean a mis-behaving client. Wireshark (or similar) should give us some more info. Can you capture a Wireshark trace of a connection that fails like this from the initial TCP handshake all the way to the point where it fails? If you can put that somewhere we can get it and look at it we might see something relevant. Note you can filter the data just for the one connection. We shouldn't need anything else. Thanks, 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 - 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: HTTPS Invalid character found in method name. HTTP method names must be tokens.
Thanks for all that data. Very strange. It is as if the server picks the wrong key to decrypt with. Given you can reproduce this, I suggest trying different versions of Java on the server to see if you can determine a pattern. Also, if you are able to provide a test case that reliably demonstrates this bug, that would be extremely helpful too. Mark On 19/03/2019 09:25, Jan Vomlel wrote: Hello Mark, communication is on https://drive.google.com/open?id=12ZqbgKkHzGKzXk19ssIcJMX6iQBUE4fQ file 18-03-2019-3-filtered-one-connection.pcapng There is also full communication log from wireshark and catalina.out. Critical packet contains data: 17 03 03 01 AB 00 00 00 00 00 00 00 01 19 58 D0 In wireshark it is followed by Change cipher spec, in catalina out are this packets together in one request. Client was firefox 60.5.2esr. Thanks, Jan Dne 18.03.2019 v 12:08 Mark Thomas napsal(a): On 18/03/2019 10:49, Jan Vomlel wrote: Thank you Mark. I enabled the logger org.apache.coyote.http11. I cannot paste line org.apache.coyote.http11.Http11InputBuffer.parseRequestLine here, because it contains not printable characters and copy paste doesnot work. It seems like bug in tomcat or jdk. ??? The client appears to be sending some unexpected binary data. It could be something TLS related although I'd expect JSSE to just handle that. It could be part of a previous request but that would mean a mis-behaving client. Wireshark (or similar) should give us some more info. Can you capture a Wireshark trace of a connection that fails like this from the initial TCP handshake all the way to the point where it fails? If you can put that somewhere we can get it and look at it we might see something relevant. Note you can filter the data just for the one connection. We shouldn't need anything else. Thanks, 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTPS Invalid character found in method name. HTTP method names must be tokens.
Hello Mark, communication is on https://drive.google.com/open?id=12ZqbgKkHzGKzXk19ssIcJMX6iQBUE4fQ file 18-03-2019-3-filtered-one-connection.pcapng There is also full communication log from wireshark and catalina.out. Critical packet contains data: 17 03 03 01 AB 00 00 00 00 00 00 00 01 19 58 D0 In wireshark it is followed by Change cipher spec, in catalina out are this packets together in one request. Client was firefox 60.5.2esr. Thanks, Jan Dne 18.03.2019 v 12:08 Mark Thomas napsal(a): On 18/03/2019 10:49, Jan Vomlel wrote: Thank you Mark. I enabled the logger org.apache.coyote.http11. I cannot paste line org.apache.coyote.http11.Http11InputBuffer.parseRequestLine here, because it contains not printable characters and copy paste doesnot work. It seems like bug in tomcat or jdk. ??? The client appears to be sending some unexpected binary data. It could be something TLS related although I'd expect JSSE to just handle that. It could be part of a previous request but that would mean a mis-behaving client. Wireshark (or similar) should give us some more info. Can you capture a Wireshark trace of a connection that fails like this from the initial TCP handshake all the way to the point where it fails? If you can put that somewhere we can get it and look at it we might see something relevant. Note you can filter the data just for the one connection. We shouldn't need anything else. Thanks, 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: HTTPS Invalid character found in method name. HTTP method names must be tokens.
On 18/03/2019 10:49, Jan Vomlel wrote: Thank you Mark. I enabled the logger org.apache.coyote.http11. I cannot paste line org.apache.coyote.http11.Http11InputBuffer.parseRequestLine here, because it contains not printable characters and copy paste doesnot work. It seems like bug in tomcat or jdk. ??? The client appears to be sending some unexpected binary data. It could be something TLS related although I'd expect JSSE to just handle that. It could be part of a previous request but that would mean a mis-behaving client. Wireshark (or similar) should give us some more info. Can you capture a Wireshark trace of a connection that fails like this from the initial TCP handshake all the way to the point where it fails? If you can put that somewhere we can get it and look at it we might see something relevant. Note you can filter the data just for the one connection. We shouldn't need anything else. Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HTTPS Invalid character found in method name. HTTP method names must be tokens.
03-15
16:28:59.287 CET|Finished.java:581|Consuming client Finished handshake
message (
"Finished": {
"verify data": {
: 3F C5 0C 9D 0E 38 9D 04 97 92 35 D5
}'}
)
15-Mar-2019 16:28:59.287 FINE [https-jsse-nio-8444-exec-7]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Processing
socket
[org.apache.tomcat.util.net.SecureNioChannel@5d7b5d52:java.nio.channels.SocketChannel[connected
local=/192.168.0.199:8444 remote=/192.168.0.149:54438]] with status
[OPEN_READ]
15-Mar-2019 16:28:59.287 FINE [https-jsse-nio-8444-exec-7]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Found
processor [null] for socket
[org.apache.tomcat.util.net.SecureNioChannel@5d7b5d52:java.nio.channels.SocketChannel[connected
local=/192.168.0.199:8444 remote=/192.168.0.149:54438]]
15-Mar-2019 16:28:59.287 FINE [https-jsse-nio-8444-exec-7]
org.apache.coyote.AbstractProtocol$ConnectionHandler.process Popped
processor [org.apache.coyote.http11.Http11Processor@651076cb] from cache
15-Mar-2019 16:28:59.287 FINE [https-jsse-nio-8444-exec-7]
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine Received [
Non printable characters, in hexa, somethink like:
0100 D0009200 6800700 28004900 ..., i think that 566
characters. ]
15-Mar-2019 16:28:59.288 INFO [https-jsse-nio-8444-exec-7]
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 method
name. HTTP method names must be tokens
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:414)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
Dne 14.03.2019 v 16:19 Mark Thomas napsal(a):
On 13/03/2019 14:41, Jan Vomlel wrote:
We use selenium for our application testing. Our tests sometime fail
with message "Invalid character found in method name" Error occures
only on https and on on firefox 60 and internet explorer 11. Chrome,
edge is OK.
We use Tomcat 9.0.16, Java 11 (Adopt Open JDK 11.0.2+9) on Linux,
browsers are on windows 10.
We think, that there must be some error in https implementation. Log in
these situations always contains request with application_data and
change_cipher_spec together. But we do not understand https in these
details.
That sounds like the previous request did not complete correctly leading
to the next request not being started at the correct point. You can try
enabling debug logging for:
org.apache.coyote.http11.Http11InputBuffer
That should tell you what request lines are being parsed.
Mark
Thanks for any advice, Jan Vomlel
javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
18:03:16.326 CET|SSLEngineInputRecord.java:177|Raw read (
: 17 03 03 02 74 00 00 00 00 00 00 00 01 E5 6A 79 t.jy
0010: CF D2 7A 6E 53 FB B3 97 3B 82 92 E5 7B A8 A2 EA ..znS...;...
0020: 4B B5 70 11 DE CD 7E 8C 89 08 AD 67 47 82 E1 16 K.pgG...
0030: FE 09 9A 1B F6 77 6C 67 80 0E CA 5F 55 4E 2C 2D .wlg..._UN,-
0040: D8 7B D2 71 2E 66 B4 0A DA 8D 8F 11 C6 C3 27 1B ...q.f'.
0050: 18 82 16 FE 82 7C 83 B4 3B 43 D8 81 71 9E 27 22 ;C..q.'"
0060: 76 50 EB C6 4C 11 C1 BE 01 8E B9 6A 3A 0B 6C 6F vP..L..j:.lo
0070: 01 03 74 F1 C4 90 C7 52 A6 8D 4A A8 8D AC EF A0 ..tR..J.
0080: 62 03 3D C7 6E F9 FB 39 C5 FA A6 95 FD 46 C3 51 b.=.n..9.F.Q
0090: FE 67 2E 76 44 7B B1 B6 8C 34 F4 30 EC 93 EC 1D .g.vD4.0
00A0: A1 5B 01 2B C1 DA D3 AA 88 EC E8 31 66 5F 59 CA .[.+...1f_Y.
00B0: 38 9A 53 C5 89 31 FB FF 1D 59 6D 90 08 66 DB 6C 8.S..1...Ym..f.l
00C0: 6F 4A 9C F7 3A BE D8 5D 5C 3C AA 3E 2B A5 A8 E2 oJ..:..]\<.>+...
00D0: 54 50 65 7B 9A BA 92 71 0F 7B AA 58 DF B2 AC 3E TPeq...X...>
00E0: 5B 4E A1 29 9C F2 C6 1A 5E 6B 6A 85 19 DE 1C 73 [N.)^kjs
00F0: EF D2 AC 06 48 50 8D DD 66 F7 78 87 50 00 28 26 HP..f.x.P.(&
0100: FB A7 C1 87 30 67 5B FA C8 B5 C7 41 4A 27 8E 6D 0g[AJ'.m
0110: D8 99 89 BA 32 8A 94 7F 79 2D 66 53 8D F4
Re: HTTPS Invalid character found in method name. HTTP method names must be tokens.
8D 8A E9 98 CA 25 1F AD .H...%..
> 0020: D5 02 FC 0A C9 8E 4D F6 C6 EA 2E D6 24 8C D0 11 ..M.$...
> 0030: DA 78 D3 .x.
> )
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.326 CET|SSLEngineInputRecord.java:214|READ: TLSv1.2
> change_cipher_spec, length = 1
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.326 CET|ChangeCipherSpec.java:143|Consuming ChangeCipherSpec
> message
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.327 CET|SSLEngineInputRecord.java:177|Raw read (
> : 16 03 03 00 28 00 00 00 00 00 00 00 00 17 E8 48 (..H
> 0010: 1B 07 8D 8A E9 98 CA 25 1F AD D5 02 FC 0A C9 8E ...%
> 0020: 4D F6 C6 EA 2E D6 24 8C D0 11 DA 78 D3 M.$x.
> )
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.327 CET|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake,
> length = 40
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.327 CET|SSLCipher.java:1629|Plaintext after DECRYPTION (
> : 14 00 00 0C 0C 1D 2A A3 97 60 B3 E4 72 E3 31 10 ..*..`..r.1.
> )
> javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
> 18:03:16.327 CET|Finished.java:581|Consuming client Finished handshake
> message (
> "Finished": {
> "verify data": {
> 0000: 0C 1D 2A A3 97 60 B3 E4 72 E3 31 10
> }'}
> )
> 27-Feb-2019 18:03:16.328 INFO [https-jsse-nio-8444-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 method
> name. HTTP method names must be tokens
> at
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:414)
>
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
>
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
>
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>
> at java.base/java.lang.Thread.run(Thread.java:834)
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
HTTPS Invalid character found in method name. HTTP method names must be tokens.
-6|2019-02-27
18:03:16.327 CET|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake,
length = 40
javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
18:03:16.327 CET|SSLCipher.java:1629|Plaintext after DECRYPTION (
: 14 00 00 0C 0C 1D 2A A3 97 60 B3 E4 72 E3 31 10 ..*..`..r.1.
)
javax.net.ssl|DEBUG|37|https-jsse-nio-8444-exec-6|2019-02-27
18:03:16.327 CET|Finished.java:581|Consuming client Finished handshake
message (
"Finished": {
"verify data": {
: 0C 1D 2A A3 97 60 B3 E4 72 E3 31 10
}'}
)
27-Feb-2019 18:03:16.328 INFO [https-jsse-nio-8444-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 method
name. HTTP method names must be tokens
at
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:414)
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
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: 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: 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.
