http2 async timeout setting

[Arief Hasani]

Hi Guys,
Seems like AsyncContext.setTimeout is not working if using http2 (clients are 
chome, firefox, safari on mac). It runs well on http1.1
Thanks

Re: override context path for manager application

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 12/4/19 17:32, Konstantin Kolinko wrote:
> чт, 5 дек. 2019 г. в 01:20, Guild, Jason A (DOT)
> :
>> 
>> Hi all:
>> 
>> The context path of the Tomcat manager application is "/manager"
>> by default [0]. I am trying to change this context path from the
>> default using an override configuration.
>> 
>> I am doing the typical creation of a container using makebase.sh
>> and setting CATALINA_BASE before starting it.
>> 
>> To enable the manager application on these containers, I create a
>> file $CATALINA_BASE/conf/[engine]/[host]/manager.xml with the
>> following content:  
>> > docBase="${catalina.home}/webapps/manager"
>> antiResourceLocking="false" privileged="true"> 
> 
> The usage of "path" attribute above is invalid. It must never be
> used in a context xml file and it is ignored there, because the
> path is derived from the name of the file.
> 
> See http://tomcat.apache.org/tomcat-9.0-doc/config/context.html
> 
> If you want to rename the application, you must do the following:
> 
> 1) first, rename the file itself, e.g. to
> 
> $CATALINA_BASE/conf/[engine]/[host]/dev9#manager.xml
> 
> $CATALINA_BASE/conf/[engine]/[host]/mymanager.xml
> 
> etc.
> 
> 2) second, you must move the manager application from 
> "${catalina.home}/webapps/" to some other directory.
> 
> The applications in "webapps/" directory are auto-deployed when
> Tomcat starts. If you keep the manager app there, it will be
> deployed twice, with the new and with the old name.

This should not be necessary. The OP is using a split CATALINA_BASE
and so CATALINA_HOME/webapps/manager will not be auto-deployed.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3oOe8ACgkQHPApP6U8
pFjKpg//aYxvnSSIjh/Lj7J8Ro8jITGiM6O2T5jyYARfKHI3pyEwL6QQKivHlwZe
cO77574BH7IPlnvnHNeX0v3HmHmN0i5ArzIfACHpFCPWC/NMiz0WE2lawjgDpYfA
i8g4/LkNwPIHerf/V3UckjidOx+rjzKqJlZ4O6qXPHbv9/COSslk8Z308HU+W7N5
cJLwO0DCn3iD1WY46aCo/Tp7rdD5SymZp5VZUZwWYLDNVwVgfQAZmTsN3J7qCfZR
DQzIgN8M0vFQIhDRjBzVfPPYmZieHFIv7Zb5fc80JME3WqCzEyplsRKCTKz32vO+
LMWVJ53+RD2ljfYdbdpd6qnXLhzyJQW4TGrV+hSfGhVukV5I5DCTGHt4n5eBj0cX
TLnjX29qKpS7f2r8dglbRVXV4trCh7DNwstWOYSzlLy5csOtIdtS5yIOkKyhj6Uv
ywDzQ5gfB79hdN1zufWjQr6x4fpIDlJrcD4AE0Mp2fNAcFGt0j35nLSiqg2qmFir
iORrhrDB8s4OTdRINq1+K5c4Ot1Hb+e/XtdfhW/OfMxQdPNGEvBvPBPXqEmDxGPA
ifhGkYdJEkrov+IiJb4GIkFerzms0uknXOHlESuAv9CsZU9MuyPN1Ebgn0LVjHsK
OW9d83T2MEVCWjq0BaX+pNK1E5uWZeRXxiJg/SVXP+JP0n1N5wg=
=3TDw
-END PGP SIGNATURE-

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

Re: override context path for manager application

[Guild, Jason A (DOT)]

Konstantin:

Thank you for your point #1 below!
When I remove "path" attribute entirely from my override configuration 
and save it as "dev9#manager.xml" then I get exactly the result I want.

However, I did not need to move the manager application from the 
"${catalina.home}/webapps" directory as in your point #2.
I am running my container from a completely separate directory structure 
with $CATALINA_BASE != $CATALINA_HOME and $CATALINA_BASE/webapps/ does 
NOT contain the manager application.

I think your point #2 would be correct if I simply decompressed the 
Tomcat distribution and ran it with $CATALINA_BASE == $CATALINA_HOME and 
I was just adding a file to 
$CATALINA_HOME/conf/[engine]/[host]/dev9#manager.xml in an attempt to 
override the context path.

Thanks again for your help,
Jason

On 12/4/2019 1:32 PM, Konstantin Kolinko wrote:
> If you want to rename the application, you must do the following:
>
> 1) first, rename the file itself, e.g. to
>
> $CATALINA_BASE/conf/[engine]/[host]/dev9#manager.xml
>
> $CATALINA_BASE/conf/[engine]/[host]/mymanager.xml
>
> etc.
>
> 2) second, you must move the manager application from
> "${catalina.home}/webapps/" to some other directory.
>
> The applications in "webapps/" directory are auto-deployed when Tomcat
> starts. If you keep the manager app there, it will be deployed twice,
> with the new and with the old name.

Re: override context path for manager application

[Konstantin Kolinko]

чт, 5 дек. 2019 г. в 01:20, Guild, Jason A (DOT) :
>
> Hi all:
>
> The context path of the Tomcat manager application is "/manager" by default 
> [0].
> I am trying to change this context path from the default using an override 
> configuration.
>
> I am doing the typical creation of a container using makebase.sh and setting 
> CATALINA_BASE before starting it.
>
> To enable the manager application on these containers, I create a file 
> $CATALINA_BASE/conf/[engine]/[host]/manager.xml with the following content:
> 
>  antiResourceLocking="false" privileged="true">
> 

The usage of "path" attribute above is invalid. It must never be used
in a context xml file and it is ignored there,
because the path is derived from the name of the file.

See
http://tomcat.apache.org/tomcat-9.0-doc/config/context.html

If you want to rename the application, you must do the following:

1) first, rename the file itself, e.g. to

$CATALINA_BASE/conf/[engine]/[host]/dev9#manager.xml

$CATALINA_BASE/conf/[engine]/[host]/mymanager.xml

etc.

2) second, you must move the manager application from
"${catalina.home}/webapps/" to some other directory.

The applications in "webapps/" directory are auto-deployed when Tomcat
starts. If you keep the manager app there, it will be deployed twice,
with the new and with the old name.

> [..]
>
> Why is my override path of "/dev9/manager" ignored?

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

override context path for manager application

[Guild, Jason A (DOT)]

Hi all:

The context path of the Tomcat manager application is "/manager" by default [0].
I am trying to change this context path from the default using an override 
configuration.

I am doing the typical creation of a container using makebase.sh and setting 
CATALINA_BASE before starting it.

To enable the manager application on these containers, I create a file 
$CATALINA_BASE/conf/[engine]/[host]/manager.xml with the following content:



In catalina.out I see the following log output:
04-Dec-2019 12:54:07.063 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of 
deployment descriptor 
[/home/tomcat/servers/dev9/conf/Catalina/localhost/manager.xml] has finished in 
[200] ms
The manager application is mapped into my container at "/manager" and is 
functional in every way.

But if I use a manager.xml to map the manager application into my container 
with an offset path like the following:



I see the following log output in catalina.out instead:
04-Dec-2019 13:08:42.089 WARNING [main] 
org.apache.catalina.startup.HostConfig.deployDescriptor The path attribute with 
value [/dev9/manager] in deployment descriptor 
[/home/tomcat/servers/dev9/conf/Catalina/localhost/manager.xml] has been ignored
04-Dec-2019 13:08:42.333 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of 
deployment descriptor 
[/home/tomcat/servers/dev9/conf/Catalina/dotancappdev1/manager.xml] has 
finished in [245] ms

Why is my override path of "/dev9/manager" ignored?
Can the context path of the manager and host-manager applications be changed?

The documentation implies that "/manager" is only a default, and it seems I 
should be able to change it but have had no success.
My environment is Tomcat 9.0.29 with OpenJDK 1.8.0_232 on Debian Linux.

Thanks,
Jason

[0] 
https://tomcat.apache.org/tomcat-9.0-doc/manager-howto.html#Introduction

Re: Unknown protocol: e on Windows

[Konstantin Kolinko]

ср, 4 дек. 2019 г. в 22:38, Christopher Schultz :
> Konstantin,
>
> On 12/4/19 13:33, Konstantin Kolinko wrote:
> > ср, 4 дек. 2019 г. в 20:28, Christopher Schultz
> > :
> >>
> >> All,
> >>
> >> I feel like I should be able to figure this out on my own, but
> >> I'm drawing a blank.
> >>
> >> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> >> 8.5.35 and I'm getting errors on a certain portion of the
> >> conf/server.xml configuration.
> >>
> >> I copy have a perfect copy/paste of the config file here but
> >> basically this is configuring a keystore for TLS. Something like
> >> this:
> >>
> >> 
> >>
> >> The error is "unknown protocol: e". Clearly,
> >> Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
> >> problem... this has to be a file URL, so let's make it a file
> >> URL: [...]
> >
> > Chris,
> >
> > 1) Do know where that message is produced? (Stacktrace? What
> > version of Tomcat?)
> >
> > E.g. it may be that the code has several attempts to use the value
> > a) as file path, b) as URL,  and you only see the message from the
> > second attempt b), but it is a) that fails.
>
> I can get all that. I don't have access ATM. This was definitely being
> called through createSSLContext() and getStore() while loading the
> keystore. I'll write back when I have that exact info.
>
> > Is your keystoreFile path correct?
>
> Yes, if you ignore the fact that I cannot figure out how to "spell" it
> properly :)
>
> This works without error on the same Java version but using Tomcat 8.0.35.

Looking at the code, Tomcat 8.5 was refactored to use ConfigFileLoader there.
The message produced by ConfigFileLoader is rather misleading.
It is actually a "new File(location).isFile()" call that returns "false".

Looking at the sources of 8.5.x, the call path is probably the following:
o.a.t.util.net.SSLHostConfigCertificate#getCertificateKeystore():

result = SSLUtilBase.getStore(getCertificateKeystoreType(),
getCertificateKeystoreProvider(),
getCertificateKeystoreFile(),
getCertificateKeystorePassword());

o.a.t.util.net.SSLUtilBase#getStore(...) L197

istream = ConfigFileLoader.getInputStream(path);

org.apache.tomcat.util.file.ConfigFileLoader

https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/tomcat/util/file/ConfigFileLoader.java#L79

Best regards,
Konstantin Kolinko

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

Re: Do I really need to use CVS for tomcat8 source management?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

Please put all your posts on the list. We are a volunteer community
and the community benefits from all posts. If you want paid support,
you are welcome to contact me directly.

On 12/4/19 14:09, engelk...@bellsouth.net wrote:
> Chris - actually, I didn't see it, and still don't.  Could you
> re-send? BTW, I didn't intend to post twice; I had some trouble
> with my email & also with subscribing to the list, so I must have
> inadvertently re-sent.

https://markmail.org/thread/v3ayci7l7psqqvmd

- -chris

> -Original Message- From: Christopher Schultz
>  Sent: Monday, December 2, 2019 7:07
> PM To: Tomcat Users List ;
> engelk...@bellsouth.net Subject: Re: Do I really need to use CVS
> for tomcat8 source management?
> 
> Bill,
> 
> On 12/2/19 17:03, engelk...@bellsouth.net wrote:
>> As someone new to working with Tomcat (8), I see that a lot of
>> the introductory documentation suggests to use CVS (and in
>> conjunction with ant) for handling software revisions. However, I
>> have read discussions about the superiority of git for handling
>> software revisions / commits, etc., and also I wish to put my
>> code where it will be publicly accessible, i.e., on github.
> 
>> Will git work just as well as CVS for tomcat app development, or
>> are there specific, important reasons why the Tomcat
>> documentation consistently refers to CVS for this?
> 
> You got a reply to this question earlier today when you first asked
> it. Did you not see the reply?
> 
> -chris
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3oEU0ACgkQHPApP6U8
pFjE4g/+J0D/6DH4pvQlGi9Q6x7ydS61EzJzaz+CqrVNiQV7mkqUrXG+iWoXQOg3
N3HyEj/vVuClvQ9DAoATPxUOzitchNh5nooRSRPK5L6fHWO/TChOIrqO5/PpC/pI
ty+MMM1bL/RTpbj/QEkW8r+CRC61UPotIoLsKrPXIfY/ckGuU5F0mXPerifDB3CS
G7YPM0l14bE0+M8/VcP/u2PLHIN/qD4fRP1R3jyuIRWmZAxWBsDUwiZPKXBFlFC9
FuUd4Ht6xqSBGvpDSik36vY8bxjwLDOKzHHlx9wE7b2C4uvYNvYefOsOerARUSP7
Rq/CnmJmyTrdcf9Ld9V6P/fR+XMvnwlmrBZr5wcqNNKucaCHCrGDKdToMRa1BAeT
iQMU3KAvdvyaL6XtgoL2nDzlxjxbAJ5wbrKXbGhQPHk4HC2dMCWzVzt0S32whevc
hSfeeTHVvFa0+SpBqz4W/7GGsZHKjO6Z2gQAEghb/u74IAIRXY2nQoHclx+ub5iA
X7OUuzGvE0hMn+GuLwcgFcdHsSlXY7CNyMT1zcT5la4LXltTZxohZkocPQdijgSc
Mg9ixJLh59bStsmVnGvtLI5rwep5j8AeXTZmxl5UOLMZyu9sJF0PeJFpkQJ/S+W0
YL+lYYKKtEYMAHRWMEk8YYGEcQ+IU1p6XzfnfJdfIUzDUdD5D2Q=
=QxSP
-END PGP SIGNATURE-

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

Re: Unknown protocol: e on Windows

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

M,

On 12/4/19 13:37, M. Manna wrote:
> Chris,
> 
> On Wed, 4 Dec 2019 at 18:34, Konstantin Kolinko
>  wrote:
> 
>> ср, 4 дек. 2019 г. в 20:28, Christopher Schultz < 
>> ch...@christopherschultz.net>:
>>> 
>>> All,
>>> 
>>> I feel like I should be able to figure this out on my own, but
>>> I'm drawing a blank.
>>> 
>>> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache
>>> Tomcat 8.5.35 and I'm getting errors on a certain portion of
>>> the conf/server.xml configuration.
>>> 
>>> I copy have a perfect copy/paste of the config file here but
>>> basically this is configuring a keystore for TLS. Something
>>> like this:
>>> 
>>> >> />
>>> 
>>> The error is "unknown protocol: e". Clearly,
>>> Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
>>> problem... this has to be a file URL, so let's make it a file
>>> URL: [...]
>> 
>> Chris,
>> 
>> 1) Do know where that message is produced? (Stacktrace? What
>> version of Tomcat?)
>> 
>> E.g. it may be that the code has several attempts to use the
>> value a) as file path, b) as URL,  and you only see the message
>> from the second attempt b), but it is a) that fails.
>> 
>> Is your keystoreFile path correct?
>> 
>> 2) Why the settings are specified on a . They will be 
>> translated into / on the fly, but
>> maybe something is broken.
>> 
>> 
>> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_
- -_Certificate
>>
>> 
It says that certificateKeystoreFile can be an URI.
>> 
>> 3) Does you connector use JSSE or OpenSSL?
>> 
>> There is some code that translates between the two configuration 
>> flavors on the fly, but maybe something is broken.
>> 
>>> I'm using Oracle Java 1.8.0 build 161.
>> 
>> FYI, an up-to-date version of Java 8 for Windows is available
>> from AdoptOpenJDK. https://adoptopenjdk.net/
>> 
>> It is 8u232 now.
>> 
>> Best regards, Konstantin Kolinko
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> I have just launched tomcat 8.5.47 stockpile with the following
> connector config (i generated keystore Jeeks before)
> 
>  port="8443" maxThreads="200" scheme="https" secure="true"
> SSLEnabled="true" keystoreFile="C:/Temp/tomcat.jks"
> keystorePass="changeit" clientAuth="false" sslProtocol="TLS"/>
> 
> And my tomcat cert gen command was:
> 
>> keytool -genkeypair -alias tomcat -keyalg RSA -keystore
>> tomcat.jks
> -keypass changeit -storepass changeit
> 
> It only gave me warning about non-legit cert when I hit 
> https://localhost:8443 but that's expected. Otherwise, no errors.
> 
> I suspect your E:\ drive is a network drive (or virtual) so the
> mapping may be causing issues ? Or may be it's the
> partitioning...?

This is a local device, not a networked one. Everything is
virtualized, but this is a "local drive" on the Windows virtual machine.

Again, Tomcat 8.0 seems to work and Tomcat 8.5 doesn't like it for
some reason. I'm assuming this is all related to the change in how
resources are loaded in Tomcat 8.5.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3oC7cACgkQHPApP6U8
pFilLxAApcWFCpa2qKLDBqYZ4L1ogGHoxkQ9UboJjN6jYmIKinSD+6fuOn2sL+dU
T02+UZF1wgEPoEZvzA365IlUgZwUnKfqox7FWpqVUREcZnjjE/rpiIN52ioq8tHa
eqbE71neKm+WfrZ0ChWCGkjP7hsomeqIMayV6wzY4Fc9qQoOaIc/nja4wmhEHAe+
SsUdHoi4CKUyWHAWmw4kvUPo8E74BJEgbr0CWJs7nIdyIYi+EkK929lk6Jz3KB+8
vfFu+wIWJXl6gfQBW5wENSFYe5IIX/8iBtFjC27WqbIPpc4qVyr+z6IFB5PCZ9X6
rib2kQOXSpAZvQVjgH/E3KpGARxlrgn3MSkf00KCWKamUO4XG5F4lPszfOEAjl5W
YT9xbp2Qh7ioA0UGdjGgHaLYu7/JhMkRLsmzeXFR2IPS7Z05svKq8Zgam+NygXGC
kcEBHMeMmeu4V0AiVNwhzeG54YFUzPBq7LSabmJt3E5WbLhGYPfo8nMV9vFpOCEp
PTxDDzUZwWJX95LkfnjWdOsQhUmeCXYckKrdkgjmr3HaN4G7H0XgC4izWyy6CvWb
kui0dkj6mw1kRCdg7BM9VWlN8L2MfmCo+c7u1oKtuaR1LbKgDtZYmgkUw2NBfVRP
fEfJtmWL+TAkXX9pAXlqdPkSt0jZBF2S5zUrqWsrkGvcgrEbHSc=
=CLq+
-END PGP SIGNATURE-

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

Re: Unknown protocol: e on Windows

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 12/4/19 13:33, Konstantin Kolinko wrote:
> ср, 4 дек. 2019 г. в 20:28, Christopher Schultz
> :
>> 
>> All,
>> 
>> I feel like I should be able to figure this out on my own, but
>> I'm drawing a blank.
>> 
>> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat 
>> 8.5.35 and I'm getting errors on a certain portion of the 
>> conf/server.xml configuration.
>> 
>> I copy have a perfect copy/paste of the config file here but
>> basically this is configuring a keystore for TLS. Something like
>> this:
>> 
>> 
>> 
>> The error is "unknown protocol: e". Clearly,
>> Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
>> problem... this has to be a file URL, so let's make it a file
>> URL: [...]
> 
> Chris,
> 
> 1) Do know where that message is produced? (Stacktrace? What
> version of Tomcat?)
> 
> E.g. it may be that the code has several attempts to use the value
> a) as file path, b) as URL,  and you only see the message from the
> second attempt b), but it is a) that fails.

I can get all that. I don't have access ATM. This was definitely being
called through createSSLContext() and getStore() while loading the
keystore. I'll write back when I have that exact info.

> Is your keystoreFile path correct?

Yes, if you ignore the fact that I cannot figure out how to "spell" it
properly :)

This works without error on the same Java version but using Tomcat 8.0.3
5.

> 2) Why the settings are specified on a . They will be 
> translated into / on the fly, but
> maybe something is broken.
> 
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-
_Certificate
>
> 
It says that certificateKeystoreFile can be an URI.

We wanted to try Tomcat 8.5 with a (nominally) 8.0-compatible
configuration. This was a first-effort test and I was thrown by the
"unknown protocol" error.

> 3) Does you connector use JSSE or OpenSSL?

JSSE

> There is some code that translates between the two configuration 
> flavors on the fly, but maybe something is broken.
> 
>> I'm using Oracle Java 1.8.0 build 161.
> 
> FYI, an up-to-date version of Java 8 for Windows is available from
> AdoptOpenJDK. https://adoptopenjdk.net/
> 
> It is 8u232 now.

Understood. I've been told that upgrading Java is a possibility but I
wanted to see if I could fix this via configuration, first.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3oCy4ACgkQHPApP6U8
pFipwg//dtvDR5Q/ZqoAKoIqJdXKBGnmbqz1rQaq9iiHe3/5PVHE6zseiN+ja4BK
1tUWY1HNgYmTU4kbhtaEHAL8dbbguHGN/g14LIf/hGqXD6A5Srl/ab+/F6rmdY8v
RIgKy3pVx0fputw64cRISg3IzcsV4+eHTdQ2a7B1o6lvwU6fQCrji7Gjf+ZI3Aio
c7laygyfm7WYtBOBkFnb9sjxGH7GydWacXUNnzqcPzi5WfZY2J+N29KHCSfX2OKW
2A2t+I6jBmhLIoMJc9BO5oMC9TzGKwJRwR+gccwxwPUY7z5s0wkHDB56rVWPzkQp
iB1JMH32rMjRYpaPOQYz+LqUenu7gJM9i4rTXPL/uKVoR3CUg5dgD+uOnTLE2AxE
dezASvq3WncW9Lpxnxu8pMp5y/CDrueIHEqoQJy0MG8P01f2clYtIZKvuh+GNQeB
CfpYEe4TaXgdCU1Hlrl54S8L2jbRU7hDtvMJrsYcxsJdA7iIMjMSbkMmlGkQX0pL
9aM8vAQ/3epOeDV1eoqKywiD/AifrmsVa7XkuoGBEeiMEF+bM7I0Yoehrj8tnN+p
uD8ji85gR0YQZysqRQpK6IpsWz9kB8Lh3m+fl7Xe9Ha2tNMXjhIAi3VcZp5Lmh4a
Q5K/nQDEGL9hlfqN5vxTxQ1Wfn65MwzxUAAiPbDBjRP1cij0biE=
=LJMq
-END PGP SIGNATURE-

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

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 18:34, Konstantin Kolinko 
wrote:

> ср, 4 дек. 2019 г. в 20:28, Christopher Schultz <
> ch...@christopherschultz.net>:
> >
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but basically
> > this is configuring a keystore for TLS. Something like this:
> >
> >  > keystoreFile="E:\path\to\keystore.jks"
> > [...]
> > />
> >
> > The error is "unknown protocol: e". Clearly, Tomcat/Java/URL/whatever
> > thinks that "E:" is a protocol. No problem... this has to be a file
> > URL, so let's make it a file URL: [...]
>
> Chris,
>
> 1) Do know where that message is produced? (Stacktrace? What version of
> Tomcat?)
>
> E.g. it may be that the code has several attempts to use the value a)
> as file path, b) as URL,  and you only see the message from the second
> attempt b), but it is a) that fails.
>
> Is your keystoreFile path correct?
>
> 2) Why the settings are specified on a . They will be
> translated into / on the fly, but maybe
> something is broken.
>
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Certificate
> It says that certificateKeystoreFile can be an URI.
>
> 3) Does you connector use JSSE or OpenSSL?
>
> There is some code that translates between the two configuration
> flavors on the fly, but maybe something is broken.
>
> > I'm using Oracle Java 1.8.0 build 161.
>
> FYI, an up-to-date version of Java 8 for Windows is available from
> AdoptOpenJDK.
> https://adoptopenjdk.net/
>
> It is 8u232 now.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
I have just launched tomcat 8.5.47 stockpile with the following connector
config (i generated keystore Jeeks before)



And my tomcat cert gen command was:

>keytool -genkeypair -alias tomcat -keyalg RSA -keystore tomcat.jks
-keypass changeit -storepass changeit

It only gave me warning about non-legit cert when I hit
https://localhost:8443 but that's expected. Otherwise, no errors.

I suspect your E:\ drive is a network drive (or virtual) so the mapping may
be causing issues ? Or may be it's the partitioning...?

Re: Unknown protocol: e on Windows

[Konstantin Kolinko]

ср, 4 дек. 2019 г. в 20:28, Christopher Schultz :
>
> All,
>
> I feel like I should be able to figure this out on my own, but I'm
> drawing a blank.
>
> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> 8.5.35 and I'm getting errors on a certain portion of the
> conf/server.xml configuration.
>
> I copy have a perfect copy/paste of the config file here but basically
> this is configuring a keystore for TLS. Something like this:
>
>  keystoreFile="E:\path\to\keystore.jks"
> [...]
> />
>
> The error is "unknown protocol: e". Clearly, Tomcat/Java/URL/whatever
> thinks that "E:" is a protocol. No problem... this has to be a file
> URL, so let's make it a file URL: [...]

Chris,

1) Do know where that message is produced? (Stacktrace? What version of Tomcat?)

E.g. it may be that the code has several attempts to use the value a)
as file path, b) as URL,  and you only see the message from the second
attempt b), but it is a) that fails.

Is your keystoreFile path correct?

2) Why the settings are specified on a . They will be
translated into / on the fly, but maybe
something is broken.

http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Certificate
It says that certificateKeystoreFile can be an URI.

3) Does you connector use JSSE or OpenSSL?

There is some code that translates between the two configuration
flavors on the fly, but maybe something is broken.

> I'm using Oracle Java 1.8.0 build 161.

FYI, an up-to-date version of Java 8 for Windows is available from AdoptOpenJDK.
https://adoptopenjdk.net/

It is 8u232 now.

Best regards,
Konstantin Kolinko

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

Re: Unknown protocol: e on Windows

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

M,

On 12/4/19 12:44, M. Manna wrote:
>> On Wed, 4 Dec 2019 at 17:38, Christopher Schultz < 
>> ch...@christopherschultz.net> wrote:
>> 
> All,
> 
> I should note that I'm using Oracle Java 1.8.0 build 161.
> 
> I have seen another environment with essentially the same 
> configuration that seems to work. The path is 
> "E:\path\to\keystore.jks" and there are no errors.
> 
> Thanks, -chris
> 
> On 12/4/19 12:27, Christopher Schultz wrote:
> All,
> 
> I feel like I should be able to figure this out on my own,
> but I'm drawing a blank.
> 
> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache
> Tomcat 8.5.35 and I'm getting errors on a certain portion
> of the conf/server.xml configuration.
> 
> I copy have a perfect copy/paste of the config file here
> but basically this is configuring a keystore for TLS.
> Something like this:
> 
>  [...] />
> 
> The error is "unknown protocol: e". Clearly, 
> Tomcat/Java/URL/whatever thinks that "E:" is a protocol.
> No problem... this has to be a file URL, so let's make it a
> file URL:
> 
>  keystoreFile="file:///E:/path/to/keystore.jks" [...] />
> 
> Same error.
> 
> What if I remove the drive letter?
> 
>  keystoreFile="file:///path/to/keystore.jks" [...] />
> 
> Same error (including the "e"!).
> 
> Okay, maybe e:/ looks like a protocol. How about using 
> backslashes?
> 
>  keystoreFile="file:///E:\path\to\keystore.jks" [...] />
> 
> "Illegal character in path" :(
> 
> What's the right way to write a Windows path containing a
> drive letter?
> 
>>> 
>>> Have you tried E:/path/to/cert.jks ?

Yes. It was the second example. Or did you mean without the "file:///"
prefix?

> Also, with Windows \\ escape often has the tricks.

XML doesn't recognize \ as an escape character.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n9XYACgkQHPApP6U8
pFhN1hAAjcmiWr9RAHnC7yEIdUM0HIuAanhWS4IMmASmO4QWnenOH4uHQaY7vgDM
15+SrsjY0J3MoJ4lJBqHI0TyLyxMR982OdfF0TAdLDISF9D9uYFb0IyvKU1RWSGi
5q1dbPg9T/9rwKSyo4oMgBazcU1fXk1yIAP/Y+CXZggGwC8FMq6a0ga7hX3L4ciN
vdvQW09BUfisMeKymM4uSK0OdXaqzrjnqgYHabDQhjDnZYvK42+Snm6/wKKvk4dP
1yS2eLsHylFI+OJnainYlSw6X5Dg75OzMoiQx7ikvoN429fNeiFKohGQufTQUmLQ
8tUYHxKwx9L3yJnkHxPHxW3Kmv1jsxK9jufrlV6gMpRy4teC1Ek8EWoYL82gZAg4
25KIp5ZsCN5k+4cY5joAZYRrbYg6CDEg/KycVrv9lpRBX9dLKvWwRfvDnZK9RoKO
sS0DE/p93CY6DzX/8JyovM1kPmYTXkrOKCm0jI4V4KKv6QZ3+t6Vm4G57ksqlkW2
ah8SmRgIyGPSHTX/jg8NQODZ3d4VaCW3sjp/qKCSJh3uezegVzLW6jS+LrUFF3YY
wv6I/oJC38+doJwk1aWRk9L2nC/40ikP7bS/82uHo6TEyVKAcdYKcl0DH/NCnaVt
2lfzfHr9bxaGaMwuWvAS9pS8vCzPNESSwbr5L9MR7jHWif8MhyM=
=3+Hf
-END PGP SIGNATURE-

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

Re: Unknown protocol: e on Windows

[M. Manna]

Also, with Windows \\ escape often has the tricks.

On Wed, 4 Dec 2019 at 17:43, M. Manna  wrote:

> Chris,
>
> On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> All,
>>
>> I should note that I'm using Oracle Java 1.8.0 build 161.
>>
>> I have seen another environment with essentially the same
>> configuration that seems to work. The path is
>> "E:\path\to\keystore.jks" and there are no errors.
>>
>> Thanks,
>> - -chris
>>
>> On 12/4/19 12:27, Christopher Schultz wrote:
>> > All,
>> >
>> > I feel like I should be able to figure this out on my own, but I'm
>> > drawing a blank.
>> >
>> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
>> > 8.5.35 and I'm getting errors on a certain portion of the
>> > conf/server.xml configuration.
>> >
>> > I copy have a perfect copy/paste of the config file here but
>> > basically this is configuring a keystore for TLS. Something like
>> > this:
>> >
>> > 
>> >
>> > The error is "unknown protocol: e". Clearly,
>> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
>> > problem... this has to be a file URL, so let's make it a file URL:
>> >
>> > > > [...] />
>> >
>> > Same error.
>> >
>> > What if I remove the drive letter?
>> >
>> > > > />
>> >
>> > Same error (including the "e"!).
>> >
>> > Okay, maybe e:/ looks like a protocol. How about using
>> > backslashes?
>> >
>> > > > [...] />
>> >
>> > "Illegal character in path" :(
>> >
>> > What's the right way to write a Windows path containing a drive
>> > letter?
>> >
>> > -chris
>> >
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
>> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
>> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
>> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
>> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
>> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
>> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
>> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
>> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
>> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
>> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
>> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
>> =gJWI
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> Have you tried E:/path/to/cert.jks ?
>

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I should note that I'm using Oracle Java 1.8.0 build 161.
>
> I have seen another environment with essentially the same
> configuration that seems to work. The path is
> "E:\path\to\keystore.jks" and there are no errors.
>
> Thanks,
> - -chris
>
> On 12/4/19 12:27, Christopher Schultz wrote:
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but
> > basically this is configuring a keystore for TLS. Something like
> > this:
> >
> > 
> >
> > The error is "unknown protocol: e". Clearly,
> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
> > problem... this has to be a file URL, so let's make it a file URL:
> >
> >  > [...] />
> >
> > Same error.
> >
> > What if I remove the drive letter?
> >
> >  > />
> >
> > Same error (including the "e"!).
> >
> > Okay, maybe e:/ looks like a protocol. How about using
> > backslashes?
> >
> >  > [...] />
> >
> > "Illegal character in path" :(
> >
> > What's the right way to write a Windows path containing a drive
> > letter?
> >
> > -chris
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
> =gJWI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Have you tried E:/path/to/cert.jks ?

Re: Unknown protocol: e on Windows

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I should note that I'm using Oracle Java 1.8.0 build 161.

I have seen another environment with essentially the same
configuration that seems to work. The path is
"E:\path\to\keystore.jks" and there are no errors.

Thanks,
- -chris

On 12/4/19 12:27, Christopher Schultz wrote:
> All,
> 
> I feel like I should be able to figure this out on my own, but I'm 
> drawing a blank.
> 
> I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat 
> 8.5.35 and I'm getting errors on a certain portion of the 
> conf/server.xml configuration.
> 
> I copy have a perfect copy/paste of the config file here but
> basically this is configuring a keystore for TLS. Something like
> this:
> 
> 
> 
> The error is "unknown protocol: e". Clearly,
> Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
> problem... this has to be a file URL, so let's make it a file URL:
> 
>  [...] />
> 
> Same error.
> 
> What if I remove the drive letter?
> 
>  />
> 
> Same error (including the "e"!).
> 
> Okay, maybe e:/ looks like a protocol. How about using
> backslashes?
> 
>  [...] />
> 
> "Illegal character in path" :(
> 
> What's the right way to write a Windows path containing a drive
> letter?
> 
> -chris
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
=gJWI
-END PGP SIGNATURE-

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

Unknown protocol: e on Windows

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I feel like I should be able to figure this out on my own, but I'm
drawing a blank.

I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
8.5.35 and I'm getting errors on a certain portion of the
conf/server.xml configuration.

I copy have a perfect copy/paste of the config file here but basically
this is configuring a keystore for TLS. Something like this:



The error is "unknown protocol: e". Clearly, Tomcat/Java/URL/whatever
thinks that "E:" is a protocol. No problem... this has to be a file
URL, so let's make it a file URL:



Same error.

What if I remove the drive letter?



Same error (including the "e"!).

Okay, maybe e:/ looks like a protocol. How about using backslashes?



"Illegal character in path" :(

What's the right way to write a Windows path containing a drive letter?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7JAACgkQHPApP6U8
pFiNUA/9HaMb2A+54U47pktVtmtLWtxjV9psMDyDF8LruWTQQMRVUng/OMq8WXqq
VO8APlOnKPoVyQvrdYOK31osv468ZlxqsXGfM7Hswa9fep7/fnRIr9hsGwRKWQJF
EXFIiWSAUC3nbc/PUa5CnLzgVo7fOV7Z4yRVSscKzi1mv39mh8cqnK8pxCmY8tgb
zhZY522e7CHWC+papuss0lkhJHBIcfEKVR6sB33r+0SvpRWhr2yh2p4uBG+V8Bm0
jHiy2i8utfIREwAIA1ddd+PT5WnAyENmF88yxeBgpmi31GDcmzHqaiL4ObfR+0r6
kLPNPpJAsr84EWsKPdZvdkHzg2wY6r1/FV5OInQ71FZXarLeFEaZVH2qzsrYojBq
BA0Fy7O4ku+kC/ZJoAyS3rknJt+MpjfIel7CMIN3KU8H+iZshNhaKdWW4LgSLKeT
QL8ujECtzJ4t4hjk+ZfPTd/heX57QWqu9NBZQUNcVRzZJp9Us62n+4w108gZL2Cj
cruKCYshxowpNjHwgitFlB9DnD92pYa2QJbU5u9NuIDLJ8+qsav+8f9ZSQO7TegR
fUS/VC7utNWrQANysOWtcTzBZBQzMLiuRrC+ReH9gLi5Lb62NYp6dWVakDVF9QLS
mvGO6IejHFBrN2VWv7fKvvEcDVPCznFvZ7YBrkfZqn9C54yjh1k=
=qW8x
-END PGP SIGNATURE-

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

Re: Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Thanks

On Wed, Dec 4, 2019, 5:20 PM Mark Thomas  wrote:

> On 04/12/2019 11:32, Kushagra Bindal wrote:
> > Hi Mark,
> >
> > I am not saying that this is a tomcat issue, I am just asking if there
> is a
> > way by which we can handle this. As maybe in later version of 8.5.24
> Tomcat
> > has take some action to handle such conditions.
>
> If you mean, is there a Tomcat setting that will not cause Tomcat to
> collapse multiple "//" to a single "/", the answer is 'No'.
>
> Mark
>
>
> >
> > On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas  wrote:
> >
> >> On 04/12/2019 05:16, Kushagra Bindal wrote:
> >>> Hi Mark/Manna/Chris,
> >>>
> >>> Do we have any way out to handle this type of behavior?
> >>
> >> All the evidence so far points to an application issue, not a Tomcat
> issue.
> >>
> >> If you are able to create a simple test case that demonstrates a Tomcat
> >> issue we can take a look.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <
> >> bindal.kusha...@gmail.com>
> >>> wrote:
> >>>
>  Chris,
> 
>  If you will check in my early email then you will find that with // it
> >> is
>  throwing 404. But as soon as I removed it manually then it starts
> >> working
>  properly and all these url were working fine in 8.5.24 version.
> 
>  On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
> >>> Kushagra,
> >>>
> >>> On 12/2/19 11:29, Kushagra Bindal wrote:
> >>> I think it should be.
> >>>
> >>> 
> >>> DanglingSessionInvalidateFilter
> >>> DanglingSessionInvalidateFilter
> >>> com.SessionInvalidateFilter 
> >>> 
> >>> DanglingSessionInvalidateFilter
> >>> /restcall/* 
> >>>
> >>> Here in below URL:
> >>>
> >>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
> >>>
> >>> sdm will be the context path.
> >>>
> >>> But in another example that I shared in my last email, one use
> >>> case http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads my
> >>> context path itself contains //.
> >>>
> >>> So, please suggest a viable solution which we can try to solve
> >>> this problem. :)
> >>>
> >>> Thanks in advance for your help & support in resolving this issue.
> >>>
> >>> All of these slashes really should be collapsed into a single slash
> >>> before processing. I don't see an issue. If the client requests:
> >>>
> >>>http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> >>>
> >>> then the filter/servlet at /sdm/restcall/* will respond.
> >>>
> >>> If the client requests:
> >>>
> >>>http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
> >>>
> >>> Then the filter/servlet at /sdm/restcall/* will respond.
> >>>
> >>> It doesn't really matter how many extra slashes the client adds...
> >>> they should all be collapsed by the server and your application should
> >>> not have to make arrangements to handle them, add them back, or worry
> >>> about whether they are there or not.
> >>>
> >>> -chris
> >>>
> >>> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas 
> >>> wrote:
> >>>
>  On 02/12/2019 10:59, Kushagra Bindal wrote:
> > Hi Mark,
> >
> > These are Rest Endpoints, and so will be processed through
> > Filter.
> 
>  That is unusual.
> 
> > Do, you think Servlet mapping will play any role here?
> 
>  If the filter is handling them, no.
> 
>  So I'll change the question. Which URL pattern from the filter
>  mapping do you expect:
> 
>  "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> "
> 
> 
> 
> >>> to match?
> 
>  The Context Path question still needs an answer.
> 
>  Mark
> 
> 
> >
> > On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas 
> > wrote:
> >
> >> On 02/12/2019 04:53, Kushagra Bindal wrote:
> >>> Hi Mark,
> >>>
> >>> Please find the snippet from web.xml
> >>
> >> Which URL pattern do you expect:
> >>
> >> "
> http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> >> "
> >>
> >>
> >>
> >>> to match?
> >>
> >> And what is the Context Path at which the application is
> >> deployed?
> >>
> >> Mark
> >>
> >>
> >>>
> >>>  default
> >>>
> >>>
> >>
> 
> >> org.apache.catalina.servlets.DefaultServlet >>> lass>
> >>>
> 
> >>> 
> >>> debug
> >>> 0  
> >>> listings
> >>> false 
> >>> 1  
> >>> jsp
> >>>
> >>
> >> org.apache.jasper.servlet.JspServlet
> >>>
> >>
> >>> 
> >>> fork
> >>> false 
> >>>  xpoweredBy
> 

Re: Double Slash Support in Tomcat 9.0.27

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kushagra,

On 12/4/19 06:32, Kushagra Bindal wrote:
> I am not saying that this is a tomcat issue, I am just asking if
> there is a way by which we can handle this. As maybe in later
> version of 8.5.24 Tomcat has take some action to handle such
> conditions.

I still don't really see the problem. Your responses have included
tiny bits of information separately and not everything all at once. If
you have a  defined and mapped to a URL pattern, it should
work and not give you a 404.

Try this with the examples application:

http://localhost:8080/examples/servlets/servlet/HelloWorldExample

It will respond no matter how any slashes you put in various places:

http://localhost:8080/examples/servlets/servlet//HelloWorldExample
http://localhost:8080/examples/servlets//servlet//HelloWorldExample
http://localhost:8080/examples/servlets/servlet//HelloWorldExample

There are no 404 errors.

Are you sure your application has deployed correctly?

- -chris

> On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas 
> wrote:
> 
>> On 04/12/2019 05:16, Kushagra Bindal wrote:
>>> Hi Mark/Manna/Chris,
>>> 
>>> Do we have any way out to handle this type of behavior?
>> 
>> All the evidence so far points to an application issue, not a
>> Tomcat issue.
>> 
>> If you are able to create a simple test case that demonstrates a
>> Tomcat issue we can take a look.
>> 
>> Mark
>> 
>> 
>>> 
>>> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <
>> bindal.kusha...@gmail.com>
>>> wrote:
>>> 
 Chris,
 
 If you will check in my early email then you will find that
 with // it
>> is
 throwing 404. But as soon as I removed it manually then it
 starts
>> working
 properly and all these url were working fine in 8.5.24
 version.
 
 On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
>>> Kushagra,
>>> 
>>> On 12/2/19 11:29, Kushagra Bindal wrote:
>>> I think it should be.
>>> 
>>>  
>>> DanglingSessionInvalidateFilter
>>>
>>> 
DanglingSessionInvalidateFilter
>>> com.SessionInvalidateFilter
>>>   
>>> DanglingSessionInvalidateFilter
>>>
>>> 
/restcall/* 
>>> 
>>> Here in below URL:
>>> 
>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthChec
k"
>>>
>>>
>>> 
sdm will be the context path.
>>> 
>>> But in another example that I shared in my last email,
>>> one use case
>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads
>>> my context path itself contains //.
>>> 
>>> So, please suggest a viable solution which we can try
>>> to solve this problem. :)
>>> 
>>> Thanks in advance for your help & support in resolving
>>> this issue.
>>> 
>>> All of these slashes really should be collapsed into a single
>>> slash before processing. I don't see an issue. If the client
>>> requests:
>>> 
>>> http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>>>
>>>
>>> 
then the filter/servlet at /sdm/restcall/* will respond.
>>> 
>>> If the client requests:
>>> 
>>> http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
>>> 
>>> Then the filter/servlet at /sdm/restcall/* will respond.
>>> 
>>> It doesn't really matter how many extra slashes the client
>>> adds... they should all be collapsed by the server and your
>>> application should not have to make arrangements to handle
>>> them, add them back, or worry about whether they are there or
>>> not.
>>> 
>>> -chris
>>> 
>>> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas
>>>  wrote:
>>> 
 On 02/12/2019 10:59, Kushagra Bindal wrote:
> Hi Mark,
> 
> These are Rest Endpoints, and so will be processed
> through Filter.
 
 That is unusual.
 
> Do, you think Servlet mapping will play any role
> here?
 
 If the filter is handling them, no.
 
 So I'll change the question. Which URL pattern from
 the filter mapping do you expect:
 
 "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthChe
ck"



>>>
 
to match?
 
 The Context Path question still needs an answer.
 
 Mark
 
 
> 
> On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas
>  wrote:
> 
>> On 02/12/2019 04:53, Kushagra Bindal wrote:
>>> Hi Mark,
>>> 
>>> Please find the snippet from web.xml
>> 
>> Which URL pattern do you expect:
>> 
>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthC
heck
>>
>> 
"
>> 
>> 
>> 
>>> to match?
>> 
>> And what is the Context Path at which the
>> application is deployed?
>> 
>> Mark
>> 
>> 
>>> 
>>>  default
>>> 
>>> 

Re: Error parsing HTTP request header

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ram,

On 12/4/19 06:02, thulasiram k wrote:
> Hi,
> 
> we recently upgrade our tomcat from 7.0.91 to 7.0.94 in windows
> platform. Post upgrade we are seeing the below exception in logs
> very frequently. can you please suggest to avoid this.
> 
> Dec 02, 2019 1:34:09 PM
> org.apache.coyote.http11.AbstractHttp11Processor process 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.InternalInputBuffer.parseRequestLine(Internal
InputBuffer.java:199)
>
> 
at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
1Processor.java:1050)
>
> 
at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
bstractProtocol.java:637)
>
> 
at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint
.java:319)
>
> 
at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
Executor.java:1128)
>
> 
at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
lExecutor.java:628)
>
> 
at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
ead.java:61)
>
> 
at java.base/java.lang.Thread.run(Thread.java:830)
> 
> And will this effect anything? as I didn't receive any complaints
> from users.

No spec-compliant client should be sending anything in an HTTP header
that causes a problem. Unfortunately, not all clients (browsers) are
actually spec-compliant, and it's very easy to write an application
that also violates the spec.

Each version of Tomcat becomes more and more strict in order to either
improve security or improve the web ecosystem in general or both.

When you get this error, do you see an entry in your access log? Can
you correlate the error with what you see in the access log? You
should see a 400 status code for this request. If you aren't sure
which character is illegal, post the whole line from the request
(perhaps sanitized for hostname, IP address, any secrets it may -- but
shouldn't -- contain) and we'll take a look.

A few years ago, Tomcat changed the way it performs Cookie parsing to
be much more strict and that broke a bunch of applications, including
my own. It turned out that we were writing a cookie value that was
actually not allowed, but Tomcat was allowing it. Upgrading would have
caused my application to break in two places: when writing that Cookie
value and also when reading it. The solution was to fix the
application to encode those cookie values so that they were HTTP-safe.
(In our case, we decided that base64 encoding would be best.)

I'm not saying that this problem is cookie-related. It's just an
example of a situation where the application was the problem and we
didn't notice until Tomcat became more strict. Our application is
actually *safer* now because it is guaranteed to work with all clients
which strictly adhere to the specifications, while before it was
relying on sloppy interpretations[1] of the specifications and luckily
getting away with it.

- -chris

[1] https://whatwg.org/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3nvoQACgkQHPApP6U8
pFhtKw/9FnbzlvWWVYuu+ao7fmleMdNb49elXhAPOTjCF0KAZgTvQlRx0ffhE5Kn
cZyJowghvOh2XLV16J5Q3UQcRulnU5RrAFNrsC/IysEXP6RzeqaYwjynZ0OpgO/K
Vbktg5v6qA6Ipje7UBvufC+WdeMede914JgBd1+aEqt4CQCi8mPbUJhnJcZyOPIL
k1nuxeGiX1pTt/wPG4yXnjnHe/MF/nMJznrxJuDMyPGd21hKfWwOzNyqTDAMRdpo
XZfNp46E5ucVRXJM9MK2WSf06I/gZhQmtXUerQ49Fn/rm+rY0HNTjV6qg+muTbB5
LG+UfloW+Bf938DfMUiMx3Xbnc5CaVLCiwTH/hZzV9+aL4QA3wLG7py6dhWnOF4O
Xpilkc9npxLi205KmP1FU7/75U3IgQGRX7jxPdIxf9rYKOyDvEF8AY4cq0Uw/B/x
v47VZekkw0Ozhq0KwKrhmzu81T/u0+35DtCMj4LJl2hM8fEE4kBNBxibaTUDVYff
c6zjOaI3trDiD+D60i3Ir8lFLSWNK70u0L6ost85itPZUi9IYCZ1B2TURp17/al8
n2BSvZFdME08AIbTXOaCP4J885xmzQJigtmDmqr5OCV9wPgOhAlFbTOgGc5tWdJu
TaiUNlyY1fCK38ZdWpagYiqF3RWIK4DU8Vds65aGO1tABMt6Niw=
=4Bb7
-END PGP SIGNATURE-

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

Re: Double Slash Support in Tomcat 9.0.27

[Mark Thomas]

On 04/12/2019 11:32, Kushagra Bindal wrote:
> Hi Mark,
> 
> I am not saying that this is a tomcat issue, I am just asking if there is a
> way by which we can handle this. As maybe in later version of 8.5.24 Tomcat
> has take some action to handle such conditions.

If you mean, is there a Tomcat setting that will not cause Tomcat to
collapse multiple "//" to a single "/", the answer is 'No'.

Mark


> 
> On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas  wrote:
> 
>> On 04/12/2019 05:16, Kushagra Bindal wrote:
>>> Hi Mark/Manna/Chris,
>>>
>>> Do we have any way out to handle this type of behavior?
>>
>> All the evidence so far points to an application issue, not a Tomcat issue.
>>
>> If you are able to create a simple test case that demonstrates a Tomcat
>> issue we can take a look.
>>
>> Mark
>>
>>
>>>
>>> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <
>> bindal.kusha...@gmail.com>
>>> wrote:
>>>
 Chris,

 If you will check in my early email then you will find that with // it
>> is
 throwing 404. But as soon as I removed it manually then it starts
>> working
 properly and all these url were working fine in 8.5.24 version.

 On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
 ch...@christopherschultz.net> wrote:

>>> Kushagra,
>>>
>>> On 12/2/19 11:29, Kushagra Bindal wrote:
>>> I think it should be.
>>>
>>> 
>>> DanglingSessionInvalidateFilter
>>> DanglingSessionInvalidateFilter
>>> com.SessionInvalidateFilter 
>>> 
>>> DanglingSessionInvalidateFilter
>>> /restcall/* 
>>>
>>> Here in below URL:
>>>
>>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
>>>
>>> sdm will be the context path.
>>>
>>> But in another example that I shared in my last email, one use
>>> case http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads my
>>> context path itself contains //.
>>>
>>> So, please suggest a viable solution which we can try to solve
>>> this problem. :)
>>>
>>> Thanks in advance for your help & support in resolving this issue.
>>>
>>> All of these slashes really should be collapsed into a single slash
>>> before processing. I don't see an issue. If the client requests:
>>>
>>>http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>>>
>>> then the filter/servlet at /sdm/restcall/* will respond.
>>>
>>> If the client requests:
>>>
>>>http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
>>>
>>> Then the filter/servlet at /sdm/restcall/* will respond.
>>>
>>> It doesn't really matter how many extra slashes the client adds...
>>> they should all be collapsed by the server and your application should
>>> not have to make arrangements to handle them, add them back, or worry
>>> about whether they are there or not.
>>>
>>> -chris
>>>
>>> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas 
>>> wrote:
>>>
 On 02/12/2019 10:59, Kushagra Bindal wrote:
> Hi Mark,
>
> These are Rest Endpoints, and so will be processed through
> Filter.

 That is unusual.

> Do, you think Servlet mapping will play any role here?

 If the filter is handling them, no.

 So I'll change the question. Which URL pattern from the filter
 mapping do you expect:

 "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;



>>> to match?

 The Context Path question still needs an answer.

 Mark


>
> On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas 
> wrote:
>
>> On 02/12/2019 04:53, Kushagra Bindal wrote:
>>> Hi Mark,
>>>
>>> Please find the snippet from web.xml
>>
>> Which URL pattern do you expect:
>>
>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>> "
>>
>>
>>
>>> to match?
>>
>> And what is the Context Path at which the application is
>> deployed?
>>
>> Mark
>>
>>
>>>
>>>  default
>>>
>>>
>>

>> org.apache.catalina.servlets.DefaultServlet>> lass>
>>>

>>> 
>>> debug
>>> 0  
>>> listings
>>> false 
>>> 1  
>>> jsp
>>>
>>
>> org.apache.jasper.servlet.JspServlet
>>>
>>
>>> 
>>> fork
>>> false 
>>>  xpoweredBy
>>> false 
>>> 3   
>>> default
>>> /   
>>> jsp
>>> *.jsp
>>> *.jspx 
>>> 
>>> PatternTemplateLaunchServlet
>>> PatternTemplateLaunchServlet
>>>
>>>
>>> 
>>> 
>>> MyReportsLaunchServlet
>>> MyReportsLaunchServlet
>>>  
>>> PatternTemplateLaunchServlet
>>> 

Re: Double Slash Support in Tomcat 9.0.27

[Kushagra Bindal]

Hi Mark,

I am not saying that this is a tomcat issue, I am just asking if there is a
way by which we can handle this. As maybe in later version of 8.5.24 Tomcat
has take some action to handle such conditions.

On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas  wrote:

> On 04/12/2019 05:16, Kushagra Bindal wrote:
> > Hi Mark/Manna/Chris,
> >
> > Do we have any way out to handle this type of behavior?
>
> All the evidence so far points to an application issue, not a Tomcat issue.
>
> If you are able to create a simple test case that demonstrates a Tomcat
> issue we can take a look.
>
> Mark
>
>
> >
> > On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <
> bindal.kusha...@gmail.com>
> > wrote:
> >
> >> Chris,
> >>
> >> If you will check in my early email then you will find that with // it
> is
> >> throwing 404. But as soon as I removed it manually then it starts
> working
> >> properly and all these url were working fine in 8.5.24 version.
> >>
> >> On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>
> > Kushagra,
> >
> > On 12/2/19 11:29, Kushagra Bindal wrote:
> > I think it should be.
> >
> > 
> > DanglingSessionInvalidateFilter
> > DanglingSessionInvalidateFilter
> > com.SessionInvalidateFilter 
> > 
> > DanglingSessionInvalidateFilter
> > /restcall/* 
> >
> > Here in below URL:
> >
> > "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
> >
> > sdm will be the context path.
> >
> > But in another example that I shared in my last email, one use
> > case http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads my
> > context path itself contains //.
> >
> > So, please suggest a viable solution which we can try to solve
> > this problem. :)
> >
> > Thanks in advance for your help & support in resolving this issue.
> >
> > All of these slashes really should be collapsed into a single slash
> > before processing. I don't see an issue. If the client requests:
> >
> >http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> >
> > then the filter/servlet at /sdm/restcall/* will respond.
> >
> > If the client requests:
> >
> >http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
> >
> > Then the filter/servlet at /sdm/restcall/* will respond.
> >
> > It doesn't really matter how many extra slashes the client adds...
> > they should all be collapsed by the server and your application should
> > not have to make arrangements to handle them, add them back, or worry
> > about whether they are there or not.
> >
> > -chris
> >
> > On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas 
> > wrote:
> >
> >> On 02/12/2019 10:59, Kushagra Bindal wrote:
> >>> Hi Mark,
> >>>
> >>> These are Rest Endpoints, and so will be processed through
> >>> Filter.
> >>
> >> That is unusual.
> >>
> >>> Do, you think Servlet mapping will play any role here?
> >>
> >> If the filter is handling them, no.
> >>
> >> So I'll change the question. Which URL pattern from the filter
> >> mapping do you expect:
> >>
> >> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
> >>
> >>
> >>
> > to match?
> >>
> >> The Context Path question still needs an answer.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas 
> >>> wrote:
> >>>
>  On 02/12/2019 04:53, Kushagra Bindal wrote:
> > Hi Mark,
> >
> > Please find the snippet from web.xml
> 
>  Which URL pattern do you expect:
> 
>  "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> "
> 
> 
> 
> > to match?
> 
>  And what is the Context Path at which the application is
>  deployed?
> 
>  Mark
> 
> 
> >
> >  default
> >
> >
> 
> >>
> org.apache.catalina.servlets.DefaultServlet > lass>
> >
> >>
> > 
> > debug
> > 0  
> > listings
> > false 
> > 1  
> > jsp
> >
> 
> org.apache.jasper.servlet.JspServlet
> >
> 
> > 
> > fork
> > false 
> >  xpoweredBy
> > false 
> > 3   
> > default
> > /   
> > jsp
> > *.jsp
> > *.jspx 
> > 
> > PatternTemplateLaunchServlet
> > PatternTemplateLaunchServlet
> >
> >
> > 
> > 
> > MyReportsLaunchServlet
> > MyReportsLaunchServlet
> >  
> > PatternTemplateLaunchServlet
> > /patterntemplatelaunch
> >  
> > MyReportsLaunchServlet
> > /MyReportsLaunchServlet
> > 
> >
> > Please let me know if you need anyother details from our
> > side.
> 

Re: Double Slash Support in Tomcat 9.0.27

[Mark Thomas]

On 04/12/2019 05:16, Kushagra Bindal wrote:
> Hi Mark/Manna/Chris,
>
> Do we have any way out to handle this type of behavior?

All the evidence so far points to an application issue, not a Tomcat issue.

If you are able to create a simple test case that demonstrates a Tomcat
issue we can take a look.

Mark


>
> On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal 
> wrote:
>
>> Chris,
>>
>> If you will check in my early email then you will find that with // it is
>> throwing 404. But as soon as I removed it manually then it starts working
>> properly and all these url were working fine in 8.5.24 version.
>>
>> On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
> Kushagra,
> 
> On 12/2/19 11:29, Kushagra Bindal wrote:
> I think it should be.
>
> 
> DanglingSessionInvalidateFilter
> DanglingSessionInvalidateFilter
> com.SessionInvalidateFilter 
> 
> DanglingSessionInvalidateFilter
> /restcall/* 
>
> Here in below URL:
>
> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
>
> sdm will be the context path.
>
> But in another example that I shared in my last email, one use
> case http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads my
> context path itself contains //.
>
> So, please suggest a viable solution which we can try to solve
> this problem. :)
>
> Thanks in advance for your help & support in resolving this issue.
> 
> All of these slashes really should be collapsed into a single slash
> before processing. I don't see an issue. If the client requests:
> 
>http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
> 
> then the filter/servlet at /sdm/restcall/* will respond.
> 
> If the client requests:
> 
>http://backend_tomcat:8080//sdm/restcall/foo/file_uploads
> 
> Then the filter/servlet at /sdm/restcall/* will respond.
> 
> It doesn't really matter how many extra slashes the client adds...
> they should all be collapsed by the server and your application should
> not have to make arrangements to handle them, add them back, or worry
> about whether they are there or not.
> 
> -chris
> 
> On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas 
> wrote:
>
>> On 02/12/2019 10:59, Kushagra Bindal wrote:
>>> Hi Mark,
>>>
>>> These are Rest Endpoints, and so will be processed through
>>> Filter.
>>
>> That is unusual.
>>
>>> Do, you think Servlet mapping will play any role here?
>>
>> If the filter is handling them, no.
>>
>> So I'll change the question. Which URL pattern from the filter
>> mapping do you expect:
>>
>> "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;
>>
>>
>>
> to match?
>>
>> The Context Path question still needs an answer.
>>
>> Mark
>>
>>
>>>
>>> On Mon, Dec 2, 2019 at 2:33 PM Mark Thomas 
>>> wrote:
>>>
 On 02/12/2019 04:53, Kushagra Bindal wrote:
> Hi Mark,
>
> Please find the snippet from web.xml

 Which URL pattern do you expect:

 "http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck;



> to match?

 And what is the Context Path at which the application is
 deployed?

 Mark


>
>  default
>
>

>> org.apache.catalina.servlets.DefaultServlet lass>
>
>>
> 
> debug
> 0  
> listings
> false 
> 1  
> jsp
>
 org.apache.jasper.servlet.JspServlet
>

> 
> fork
> false 
>  xpoweredBy
> false 
> 3   
> default
> /   
> jsp
> *.jsp
> *.jspx 
> 
> PatternTemplateLaunchServlet
> PatternTemplateLaunchServlet
>
>
> 
> 
> MyReportsLaunchServlet
> MyReportsLaunchServlet
>  
> PatternTemplateLaunchServlet
> /patterntemplatelaunch
>  
> MyReportsLaunchServlet
> /MyReportsLaunchServlet
> 
>
> Please let me know if you need anyother details from our
> side.
>
> On Mon, Dec 2, 2019 at 3:07 AM Mark Thomas
>  wrote:
>
>> On 01/12/2019 07:11, Kushagra Bindal wrote:
>>> Hi Manna/Mark,
>>>
>>> Below are the sample URL which we are passing to
>>> Tomcat.
>>>
>>> http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads
>>>
>>>
> http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck
>>>
>>> As from the above example you can see that // location
>>> may vary case
>> by
>>> case.
>>>
>>> So, you guys have a probable solution to handle such

Re: Async file upload server has 33% less throughput compared to the sync version

[Mark Thomas]

On 04/12/2019 02:23, Behrang Saeedzadeh wrote:
> I am not expecting it to take less time, but to provide better throughput.

Despite what you appear to think, you have written two synchronous,
blocking I/O upload servlets. Not one synchronous and one
non-synchronous. With synchronous I/O less time == more throughput.

> With 1000 concurrent users, the sync version was still performing better
> (mean req/second).

Entirely as expected.

An asynchronous approach is not magic pixie dust that automatically
improves performance. In some scenarios it will make performance
(throughput and time per request) worse.

Neither is writing an asynchronous upload servlet as simple as taking
all the code from your synchronous doPost() method and surrounding it with:
asyncContext.start(() -> {

});

All that does is start a separate thread to do the synchronous, blocking
I/O you had in the original method. i.e. more server side work to
achieve exactly the same result.

For an asynchronous file upload servlet to provide improved throughput:

1. It needs to use non-blocking I/O. Your doesn't.

2. The clients need to be sending data sufficiently slowly that a thread
reading the upload with blocking I/O spends a reasonable amount of time
blocking, waiting for more data to arrive. Your tests don't do that.

Mark

> 
> 
> Best regards,
> Behrang Saeedzadeh
> (Sent from my cellphone.)
> 
> On Mon, 2 Dec. 2019, 8:44 am Mark Thomas,  wrote:
> 
>> On 01/12/2019 02:17, Behrang Saeedzadeh wrote:
>>
>> 
>>
>>> Any ideas what am I missing here?
>>
>> Async provides scalability, not raw performance.
>>
>> You haven't written a async file upload servlet. That would require
>> non-blocking I/O and look more like this:
>>
>> https://github.com/apache/tomcat/blob/master/webapps/examples/WEB-INF/classes/nonblocking/ByteCounter.java
>>
>> Step back from your code for a second. The async version does exactly
>> the same thing as the sync version apart from it does a bunch of *extra*
>> stuff (creating the Runnable and dispatching it to a different thread).
>> Why would you expect the code that does extra stuff, to take less time
>> when it does more?
>>
>> 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

Error parsing HTTP request header

[thulasiram k]

Hi,

we recently upgrade our tomcat from 7.0.91 to 7.0.94 in windows platform.
Post upgrade we are seeing the below exception in logs very frequently. can
you please suggest to avoid this.

Dec 02, 2019 1:34:09 PM org.apache.coyote.http11.AbstractHttp11Processor
process
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.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:199)
 at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1050)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
 at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:319)
 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:830)

And will this effect anything? as I didn't receive any complaints from
users.

Thanks
Ram

Re: host [:] is not valid error in catalina.out

[Mark Thomas]

On 04/12/2019 05:19, Kushagra Bindal wrote:
> Hi,
> 
> I tried to upgrade my tomcat on OpenAM from 8.5.24 to 9.0.29 version and I
> got below error in catalina.out during startup itself.

That stack trace shows that this error is in response to an incoming
request, not part of the start-up sequence.

> [http-nio-8080-exec-7] org.apache.coyote.AbstractProcessor.parseHost The
> host [:] is not valid

You have a broken client that is presenting an invalid Host header. If
you want the error to go away, fix the broken client.

Mark

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