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.
<Context *mapperContextRootRedirectEnabled="false"*
Mark and everyone thanks for your help!
Thanks,
Bhavesh
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:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>HTTPSOnly</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> </security-constraint>
> <security-constraint>
> <auth-constraint>
> <!-- empty constraint: forbid all access -->
> </auth-constraint>
> </security-constraint>
>
> Thanks in advance for your help.
>
> Thanks,
>
> Bhavesh
>
>
>
>
> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas <ma...@apache.org> 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 <ma...@apache.org> 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:
>> >>>
>> >>>
>> >>> <Connector executor="tomcatThreadPool"
>> >>> port="8080" protocol="HTTP/1.1"
>> >>> connectionTimeout="20000"
>> >>> redirectPort="8443" />
>> >>> -->
>> >>> -->
>> >>> <Connector port="${tomcat.secure.port}"
>> >>> 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">
>> >>> <UpgradeProtocol
>> >> className="org.apache.coyote.http2.Http2Protocol"
>> >>> readTimeout="50000" streamReadTimeout ="-1" streamWriteTimeout="-1"
>> >>> overheadContinuationThreshold="0" overheadDataThreshold="0"
>> >>> overheadWindowUpdateThreshold="0"/>
>> >>>
>> >>> </Connector>
>> >>>
>> >>> 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
>>
>>
