Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
Hi Christopher,
Thanks for the suggestion. But I don't have the luxury of using a Load
balancer or Proxy. I kind of agree that it would be best to handle outside
tomcat.
At this point, it is working as expected after all changes mentioned in the
thread. Again, I value your opinion and feedback.
Thanks,
Bhavesh
On Mon, Oct 10, 2022 at 7:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Bhavesh,
>
> On 10/10/22 22:05, Bhavesh Mistry wrote:
> > I figured out the issue by default *mapperContextRootRedirectEnabled is
> > true* hence it was redirecting it. By setting it false, I was able to
> get
> > controller to filter.
> >
> > >
> > Mark and everyone thanks for your help!
>
> At the risk of complicating things, if I were you I would handle this
> completely outside of Tomcat. You may not already be using a
> load-balancer, reverse-proxy, or WAF, but IMHO that's the best place to
> do this kind of thing.
>
> In order to do this in Tomcat, you have had to change a few settings and
> one of them -- the one which enforces CONFIDENTIAL transport -- may be
> more easily bypassed within your application than when allowing Tomcat
> to do it for you.
>
> BTW, OPTIONS requests are used for pre-flight AJAX requests. You may
> break your application by disabling OPTIONS. (Also note that
> lb/rev-proxy/WAF can be configured to respond to OPTIONS requests rather
> trivially, and you can still refuse them from your application servers.)
>
> Hope that helps,
> -chris
>
> > On Mon, Oct 10, 2022 at 1:56 PM Bhavesh Mistry <
> mistry.p.bhav...@gmail.com>
> > wrote:
> >
> >> Hi Mark ,
> >>
> >> Thank you for your feedback. I have made all the changes needed and it
> is
> >> working as expected except for ONE use case where the servlet context
> path
> >> does not end with */*. When server context path is given without /
> >> ('/versa'), tomcat seems to do 302 redirect to automatically '/versa/'.
> >> How can I change this behavior so that the OPTIONS method returns 405
> from
> >> the filter instead of tomcat auto-redirecting to the context path?
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa*
> >> HTTP/1.1 302
> >> Location: /versa/
> >> Transfer-Encoding: chunked
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
> >> HTTP/1.1 405
> >> Cache-Control: private
> >> Content-Length: 0
> >>
> >>
> >>
> >> Here is the updated web.xml security containers:
> >>
> >>
> >>
> >> HTTPSOnly
> >> /*
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Thanks in advance for your help.
> >>
> >> Thanks,
> >>
> >> Bhavesh
> >>
> >>
> >>
> >>
> >> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas wrote:
> >>
> >>> On 07/10/2022 19:47, Bhavesh Mistry wrote:
> Hi Mark,
>
> Thank you for your quick response. Your proposed solution works by
> removing the transport-guarantee element. Another quick question, I
> >>> have
> Connection has a property called allowTrace method. Is it possible to
> configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT
> rather
> than having custom logic at the application level?
> >>>
> >>> No.
> >>>
> Do you think it good idea to have Connector Config which method to
> >>> allow and disallow?
> >>>
> >>> No.
> >>>
> >>> I don't think it is a good idea to have an option to disable TRACE at
> >>> the connector level. I'd be quite happy to remove that feature but I'm
> >>> fairly sure I would not be able to get consensus to do that.
> >>>
> >>> My understanding is that TRACE got its poor reputation due to a
> >>> misbehaving browser. Rather than pressure the browser vendor to fix
> >>> their broken browser, the security community decided to pressure the
> >>> server community to disable the functionality the browser didn't handle
> >>> properly. That just seems backwards to me no matter how big the
> >>> browser's market share might have been at the time and how reluctant to
> >>> change the vendor was.
> >>>
> >>> CONNECT returns 405 by default in a Servlet container and none of
> TRACE,
> >>> OPTIONS or HEAD are inherently unsafe.
> >>>
> >>> Mark
> >>>
> >>>
>
> Thanks,
>
> Bhavesh
>
> On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
>
> > On 07/10/2022 18:09, Bhavesh Mistry wrote:
> >> Hi Tomcat Team,
> >>
> >> We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
> > method
> >> on port 80 and 443.
> >>
> >> We have connector definitions as follows:
> >>
> >>
> >> >> port="8080" protocol="HTTP/1.1"
> >> connectionTimeout="2"
> >> redirectPort="8443" />
> >>-->
> >>-->
> >> >> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >> relaxedPathChars="[\\]^`{|}"
> > relaxedQueryChars="[\
Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
Bhavesh,
On 10/10/22 22:05, Bhavesh Mistry wrote:
I figured out the issue by default *mapperContextRootRedirectEnabled is
true* hence it was redirecting it. By setting it false, I was able to get
controller to filter.
At the risk of complicating things, if I were you I would handle this
completely outside of Tomcat. You may not already be using a
load-balancer, reverse-proxy, or WAF, but IMHO that's the best place to
do this kind of thing.
In order to do this in Tomcat, you have had to change a few settings and
one of them -- the one which enforces CONFIDENTIAL transport -- may be
more easily bypassed within your application than when allowing Tomcat
to do it for you.
BTW, OPTIONS requests are used for pre-flight AJAX requests. You may
break your application by disabling OPTIONS. (Also note that
lb/rev-proxy/WAF can be configured to respond to OPTIONS requests rather
trivially, and you can still refuse them from your application servers.)
Hope that helps,
-chris
On Mon, Oct 10, 2022 at 1:56 PM Bhavesh Mistry
wrote:
Hi Mark ,
Thank you for your feedback. I have made all the changes needed and it is
working as expected except for ONE use case where the servlet context path
does not end with */*. When server context path is given without /
('/versa'), tomcat seems to do 302 redirect to automatically '/versa/'.
How can I change this behavior so that the OPTIONS method returns 405 from
the filter instead of tomcat auto-redirecting to the context path?
curl -i -k -X OPTIONS http://10.43.243.8*/versa*
HTTP/1.1 302
Location: /versa/
Transfer-Encoding: chunked
curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
HTTP/1.1 405
Cache-Control: private
Content-Length: 0
Here is the updated web.xml security containers:
HTTPSOnly
/*
Thanks in advance for your help.
Thanks,
Bhavesh
On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas wrote:
On 07/10/2022 19:47, Bhavesh Mistry wrote:
Hi Mark,
Thank you for your quick response. Your proposed solution works by
removing the transport-guarantee element. Another quick question, I
have
Connection has a property called allowTrace method. Is it possible to
configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
than having custom logic at the application level?
No.
Do you think it good idea to have Connector Config which method to
allow and disallow?
No.
I don't think it is a good idea to have an option to disable TRACE at
the connector level. I'd be quite happy to remove that feature but I'm
fairly sure I would not be able to get consensus to do that.
My understanding is that TRACE got its poor reputation due to a
misbehaving browser. Rather than pressure the browser vendor to fix
their broken browser, the security community decided to pressure the
server community to disable the functionality the browser didn't handle
properly. That just seems backwards to me no matter how big the
browser's market share might have been at the time and how reluctant to
change the vendor was.
CONNECT returns 405 by default in a Servlet container and none of TRACE,
OPTIONS or HEAD are inherently unsafe.
Mark
Thanks,
Bhavesh
On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
On 07/10/2022 18:09, Bhavesh Mistry wrote:
Hi Tomcat Team,
We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
method
on port 80 and 443.
We have connector definitions as follows:
-->
-->
relaxedQueryChars="[\\]^`{|}"
address="${tomcat.address}" minSpareThreads="100"
maxThreads="200" SSLEnabled="true"
scheme="https" secure="true" maxSwallowSize="-1"
maxPostSize="-1">
className="org.apache.coyote.http2.Http2Protocol"
readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
overheadContinuationThreshold="0" overheadDataThreshold="0"
overheadWindowUpdateThreshold="0"/>
and we have an application filter to block and return 405. This works
for
HTTPS port 443. But request going to HTTP port 80 always get
redirected
regardless of the method.
curl -i -k -X OPTIONS http://10.43.243.8/versa/
*HTTP/1.1 302*
Cache-Control: private
Location: https://10.43.243.8/versa/
Content-Length: 0
Date: Fri, 07 Oct 2022 16:58:27 GMT
Server: Versa Director
curl -i -k -X OPTIONS https://10.43.243.8/versa/
*HTTP/2 405*
cache-control: private
content-length: 0
date: Fri, 07 Oct 2022 16:58:51 GMT
We wanted to block OPTIONS on port 80 as well, it seems to me that
tomcat
internally (via connector) redirects requests without application
code.
How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods
on
port 80 while redirect is ON for the connector?
Any pointers or help is greatly appreciated.
Tomcat only redirects http to https as the result of an application
defined transport-guarantee element in web.xml.
Securit
Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
I figured out the issue by default *mapperContextRootRedirectEnabled is
true* hence it was redirecting it. By setting it false, I was able to get
controller to filter.
wrote:
> Hi Mark ,
>
> Thank you for your feedback. I have made all the changes needed and it is
> working as expected except for ONE use case where the servlet context path
> does not end with */*. When server context path is given without /
> ('/versa'), tomcat seems to do 302 redirect to automatically '/versa/'.
> How can I change this behavior so that the OPTIONS method returns 405 from
> the filter instead of tomcat auto-redirecting to the context path?
>
> curl -i -k -X OPTIONS http://10.43.243.8*/versa*
> HTTP/1.1 302
> Location: /versa/
> Transfer-Encoding: chunked
>
> curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
> HTTP/1.1 405
> Cache-Control: private
> Content-Length: 0
>
>
>
> Here is the updated web.xml security containers:
>
>
>
> HTTPSOnly
> /*
>
>
>
>
>
>
>
>
> Thanks in advance for your help.
>
> Thanks,
>
> Bhavesh
>
>
>
>
> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas wrote:
>
>> On 07/10/2022 19:47, Bhavesh Mistry wrote:
>> > Hi Mark,
>> >
>> > Thank you for your quick response. Your proposed solution works by
>> > removing the transport-guarantee element. Another quick question, I
>> have
>> > Connection has a property called allowTrace method. Is it possible to
>> > configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
>> > than having custom logic at the application level?
>>
>> No.
>>
>> > Do you think it good idea to have Connector Config which method to
>> allow and disallow?
>>
>> No.
>>
>> I don't think it is a good idea to have an option to disable TRACE at
>> the connector level. I'd be quite happy to remove that feature but I'm
>> fairly sure I would not be able to get consensus to do that.
>>
>> My understanding is that TRACE got its poor reputation due to a
>> misbehaving browser. Rather than pressure the browser vendor to fix
>> their broken browser, the security community decided to pressure the
>> server community to disable the functionality the browser didn't handle
>> properly. That just seems backwards to me no matter how big the
>> browser's market share might have been at the time and how reluctant to
>> change the vendor was.
>>
>> CONNECT returns 405 by default in a Servlet container and none of TRACE,
>> OPTIONS or HEAD are inherently unsafe.
>>
>> Mark
>>
>>
>> >
>> > Thanks,
>> >
>> > Bhavesh
>> >
>> > On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
>> >
>> >> On 07/10/2022 18:09, Bhavesh Mistry wrote:
>> >>> Hi Tomcat Team,
>> >>>
>> >>> We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
>> >> method
>> >>> on port 80 and 443.
>> >>>
>> >>> We have connector definitions as follows:
>> >>>
>> >>>
>> >>> > >>> port="8080" protocol="HTTP/1.1"
>> >>> connectionTimeout="2"
>> >>> redirectPort="8443" />
>> >>> -->
>> >>> -->
>> >>> > >>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> >>> relaxedPathChars="[\\]^`{|}"
>> >> relaxedQueryChars="[\\]^`{|}"
>> >>> address="${tomcat.address}" minSpareThreads="100"
>> >>>maxThreads="200" SSLEnabled="true"
>> >>> scheme="https" secure="true" maxSwallowSize="-1"
>> >>> maxPostSize="-1">
>> >>> > >> className="org.apache.coyote.http2.Http2Protocol"
>> >>> readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
>> >>> overheadContinuationThreshold="0" overheadDataThreshold="0"
>> >>> overheadWindowUpdateThreshold="0"/>
>> >>>
>> >>>
>> >>>
>> >>> and we have an application filter to block and return 405. This works
>> >> for
>> >>> HTTPS port 443. But request going to HTTP port 80 always get
>> redirected
>> >>> regardless of the method.
>> >>>
>> >>> curl -i -k -X OPTIONS http://10.43.243.8/versa/
>> >>> *HTTP/1.1 302*
>> >>> Cache-Control: private
>> >>> Location: https://10.43.243.8/versa/
>> >>> Content-Length: 0
>> >>> Date: Fri, 07 Oct 2022 16:58:27 GMT
>> >>> Server: Versa Director
>> >>>
>> >>> curl -i -k -X OPTIONS https://10.43.243.8/versa/
>> >>> *HTTP/2 405*
>> >>> cache-control: private
>> >>> content-length: 0
>> >>> date: Fri, 07 Oct 2022 16:58:51 GMT
>> >>>
>> >>> We wanted to block OPTIONS on port 80 as well, it seems to me that
>> tomcat
>> >>> internally (via connector) redirects requests without application
>> code.
>> >>> How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods
>> on
>> >>> port 80 while redirect is ON for the connector?
>> >>>
>> >>> Any pointers or help is greatly appreciated.
>> >>
>> >> Tomcat only redirects http to https as the result of an application
>> >> defined transport-guarantee element in web.xml.
>> >>
>> >> Security constraints get processed before Filters.
>> >>
>> >> Y
Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
Hi Mark ,
Thank you for your feedback. I have made all the changes needed and it is
working as expected except for ONE use case where the servlet context path
does not end with */*. When server context path is given without /
('/versa'), tomcat seems to do 302 redirect to automatically '/versa/'.
How can I change this behavior so that the OPTIONS method returns 405 from
the filter instead of tomcat auto-redirecting to the context path?
curl -i -k -X OPTIONS http://10.43.243.8*/versa*
HTTP/1.1 302
Location: /versa/
Transfer-Encoding: chunked
curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
HTTP/1.1 405
Cache-Control: private
Content-Length: 0
Here is the updated web.xml security containers:
HTTPSOnly
/*
Thanks in advance for your help.
Thanks,
Bhavesh
On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas wrote:
> On 07/10/2022 19:47, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > Thank you for your quick response. Your proposed solution works by
> > removing the transport-guarantee element. Another quick question, I have
> > Connection has a property called allowTrace method. Is it possible to
> > configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
> > than having custom logic at the application level?
>
> No.
>
> > Do you think it good idea to have Connector Config which method to
> allow and disallow?
>
> No.
>
> I don't think it is a good idea to have an option to disable TRACE at
> the connector level. I'd be quite happy to remove that feature but I'm
> fairly sure I would not be able to get consensus to do that.
>
> My understanding is that TRACE got its poor reputation due to a
> misbehaving browser. Rather than pressure the browser vendor to fix
> their broken browser, the security community decided to pressure the
> server community to disable the functionality the browser didn't handle
> properly. That just seems backwards to me no matter how big the
> browser's market share might have been at the time and how reluctant to
> change the vendor was.
>
> CONNECT returns 405 by default in a Servlet container and none of TRACE,
> OPTIONS or HEAD are inherently unsafe.
>
> Mark
>
>
> >
> > Thanks,
> >
> > Bhavesh
> >
> > On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
> >
> >> On 07/10/2022 18:09, Bhavesh Mistry wrote:
> >>> Hi Tomcat Team,
> >>>
> >>> We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
> >> method
> >>> on port 80 and 443.
> >>>
> >>> We have connector definitions as follows:
> >>>
> >>>
> >>>>>> port="8080" protocol="HTTP/1.1"
> >>> connectionTimeout="2"
> >>> redirectPort="8443" />
> >>> -->
> >>> -->
> >>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>> relaxedPathChars="[\\]^`{|}"
> >> relaxedQueryChars="[\\]^`{|}"
> >>> address="${tomcat.address}" minSpareThreads="100"
> >>>maxThreads="200" SSLEnabled="true"
> >>> scheme="https" secure="true" maxSwallowSize="-1"
> >>> maxPostSize="-1">
> >>>>> className="org.apache.coyote.http2.Http2Protocol"
> >>> readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
> >>> overheadContinuationThreshold="0" overheadDataThreshold="0"
> >>> overheadWindowUpdateThreshold="0"/>
> >>>
> >>>
> >>>
> >>> and we have an application filter to block and return 405. This works
> >> for
> >>> HTTPS port 443. But request going to HTTP port 80 always get
> redirected
> >>> regardless of the method.
> >>>
> >>> curl -i -k -X OPTIONS http://10.43.243.8/versa/
> >>> *HTTP/1.1 302*
> >>> Cache-Control: private
> >>> Location: https://10.43.243.8/versa/
> >>> Content-Length: 0
> >>> Date: Fri, 07 Oct 2022 16:58:27 GMT
> >>> Server: Versa Director
> >>>
> >>> curl -i -k -X OPTIONS https://10.43.243.8/versa/
> >>> *HTTP/2 405*
> >>> cache-control: private
> >>> content-length: 0
> >>> date: Fri, 07 Oct 2022 16:58:51 GMT
> >>>
> >>> We wanted to block OPTIONS on port 80 as well, it seems to me that
> tomcat
> >>> internally (via connector) redirects requests without application
> code.
> >>> How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods on
> >>> port 80 while redirect is ON for the connector?
> >>>
> >>> Any pointers or help is greatly appreciated.
> >>
> >> Tomcat only redirects http to https as the result of an application
> >> defined transport-guarantee element in web.xml.
> >>
> >> Security constraints get processed before Filters.
> >>
> >> You can't change the either of the above.
> >>
> >> What you could do, is remove the transport-guarantee from web.xml and
> >> perform the http to https redirect in your Filter. Then you'd have the
> >> option to return 405 instead of the redirect.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail
Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
On 07/10/2022 19:47, Bhavesh Mistry wrote:
Hi Mark,
Thank you for your quick response. Your proposed solution works by
removing the transport-guarantee element. Another quick question, I have
Connection has a property called allowTrace method. Is it possible to
configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
than having custom logic at the application level?
No.
Do you think it good idea to have Connector Config which method to allow and
disallow?
No.
I don't think it is a good idea to have an option to disable TRACE at
the connector level. I'd be quite happy to remove that feature but I'm
fairly sure I would not be able to get consensus to do that.
My understanding is that TRACE got its poor reputation due to a
misbehaving browser. Rather than pressure the browser vendor to fix
their broken browser, the security community decided to pressure the
server community to disable the functionality the browser didn't handle
properly. That just seems backwards to me no matter how big the
browser's market share might have been at the time and how reluctant to
change the vendor was.
CONNECT returns 405 by default in a Servlet container and none of TRACE,
OPTIONS or HEAD are inherently unsafe.
Mark
Thanks,
Bhavesh
On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
On 07/10/2022 18:09, Bhavesh Mistry wrote:
Hi Tomcat Team,
We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
method
on port 80 and 443.
We have connector definitions as follows:
-->
-->
relaxedQueryChars="[\\]^`{|}"
address="${tomcat.address}" minSpareThreads="100"
maxThreads="200" SSLEnabled="true"
scheme="https" secure="true" maxSwallowSize="-1"
maxPostSize="-1">
className="org.apache.coyote.http2.Http2Protocol"
readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
overheadContinuationThreshold="0" overheadDataThreshold="0"
overheadWindowUpdateThreshold="0"/>
and we have an application filter to block and return 405. This works
for
HTTPS port 443. But request going to HTTP port 80 always get redirected
regardless of the method.
curl -i -k -X OPTIONS http://10.43.243.8/versa/
*HTTP/1.1 302*
Cache-Control: private
Location: https://10.43.243.8/versa/
Content-Length: 0
Date: Fri, 07 Oct 2022 16:58:27 GMT
Server: Versa Director
curl -i -k -X OPTIONS https://10.43.243.8/versa/
*HTTP/2 405*
cache-control: private
content-length: 0
date: Fri, 07 Oct 2022 16:58:51 GMT
We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
internally (via connector) redirects requests without application code.
How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods on
port 80 while redirect is ON for the connector?
Any pointers or help is greatly appreciated.
Tomcat only redirects http to https as the result of an application
defined transport-guarantee element in web.xml.
Security constraints get processed before Filters.
You can't change the either of the above.
What you could do, is remove the transport-guarantee from web.xml and
perform the http to https redirect in your Filter. Then you'd have the
option to return 405 instead of the redirect.
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: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
Hi Mark,
Thank you for your quick response. Your proposed solution works by
removing the transport-guarantee element. Another quick question, I have
Connection has a property called allowTrace method. Is it possible to
configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
than having custom logic at the application level? Do you think it good
idea to have Connector Config which method to allow and disallow?
Thanks,
Bhavesh
On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas wrote:
> On 07/10/2022 18:09, Bhavesh Mistry wrote:
> > Hi Tomcat Team,
> >
> > We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP
> method
> > on port 80 and 443.
> >
> > We have connector definitions as follows:
> >
> >
> > > port="8080" protocol="HTTP/1.1"
> > connectionTimeout="2"
> > redirectPort="8443" />
> > -->
> > -->
> > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > relaxedPathChars="[\\]^`{|}"
> relaxedQueryChars="[\\]^`{|}"
> > address="${tomcat.address}" minSpareThreads="100"
> > maxThreads="200" SSLEnabled="true"
> > scheme="https" secure="true" maxSwallowSize="-1"
> > maxPostSize="-1">
> > className="org.apache.coyote.http2.Http2Protocol"
> > readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
> > overheadContinuationThreshold="0" overheadDataThreshold="0"
> > overheadWindowUpdateThreshold="0"/>
> >
> >
> >
> > and we have an application filter to block and return 405. This works
> for
> > HTTPS port 443. But request going to HTTP port 80 always get redirected
> > regardless of the method.
> >
> > curl -i -k -X OPTIONS http://10.43.243.8/versa/
> > *HTTP/1.1 302*
> > Cache-Control: private
> > Location: https://10.43.243.8/versa/
> > Content-Length: 0
> > Date: Fri, 07 Oct 2022 16:58:27 GMT
> > Server: Versa Director
> >
> > curl -i -k -X OPTIONS https://10.43.243.8/versa/
> > *HTTP/2 405*
> > cache-control: private
> > content-length: 0
> > date: Fri, 07 Oct 2022 16:58:51 GMT
> >
> > We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
> > internally (via connector) redirects requests without application code.
> > How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods on
> > port 80 while redirect is ON for the connector?
> >
> > Any pointers or help is greatly appreciated.
>
> Tomcat only redirects http to https as the result of an application
> defined transport-guarantee element in web.xml.
>
> Security constraints get processed before Filters.
>
> You can't change the either of the above.
>
> What you could do, is remove the transport-guarantee from web.xml and
> perform the http to https redirect in your Filter. Then you'd have the
> option to return 405 instead of the redirect.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
On 07/10/2022 18:09, Bhavesh Mistry wrote: Hi Tomcat Team, We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP method on port 80 and 443. We have connector definitions as follows: --> --> and we have an application filter to block and return 405. This works for HTTPS port 443. But request going to HTTP port 80 always get redirected regardless of the method. curl -i -k -X OPTIONS http://10.43.243.8/versa/ *HTTP/1.1 302* Cache-Control: private Location: https://10.43.243.8/versa/ Content-Length: 0 Date: Fri, 07 Oct 2022 16:58:27 GMT Server: Versa Director curl -i -k -X OPTIONS https://10.43.243.8/versa/ *HTTP/2 405* cache-control: private content-length: 0 date: Fri, 07 Oct 2022 16:58:51 GMT We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat internally (via connector) redirects requests without application code. How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods on port 80 while redirect is ON for the connector? Any pointers or help is greatly appreciated. Tomcat only redirects http to https as the result of an application defined transport-guarantee element in web.xml. Security constraints get processed before Filters. You can't change the either of the above. What you could do, is remove the transport-guarantee from web.xml and perform the http to https redirect in your Filter. Then you'd have the option to return 405 instead of the redirect. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method
Hi Tomcat Team, We have a unique situation. We wanted to block ALL *OPTIONALS* HTTP method on port 80 and 443. We have connector definitions as follows: --> --> and we have an application filter to block and return 405. This works for HTTPS port 443. But request going to HTTP port 80 always get redirected regardless of the method. curl -i -k -X OPTIONS http://10.43.243.8/versa/ *HTTP/1.1 302* Cache-Control: private Location: https://10.43.243.8/versa/ Content-Length: 0 Date: Fri, 07 Oct 2022 16:58:27 GMT Server: Versa Director curl -i -k -X OPTIONS https://10.43.243.8/versa/ *HTTP/2 405* cache-control: private content-length: 0 date: Fri, 07 Oct 2022 16:58:51 GMT We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat internally (via connector) redirects requests without application code. How can I achieve blocking OPTIONS, TRACE, and CONNECT HTTP methods on port 80 while redirect is ON for the connector? Any pointers or help is greatly appreciated. Thanks, Bhavesh
