You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by joeweder <jo...@gmail.com> on 2009/04/02 16:24:33 UTC
Re: How2 Disable PUT response in OPTIONS method
Thanks markt-2. The idea of using a ServletFilter is a good one but will not
work because the application (we've inherited) does not have a single entry
point (dispatch/front-controller) yuck. So I'd have to patch it several
places.
What I wound up doing was making a little custom valve (HttpMethodValve) and
added it to the Engine in our server.xml. The valve allows only the methods
specified (see allow=""), gives a 403 otherwise, and reports only the
allow(ed) methods in response to OPTIONS. Dropped this little jar in
tomcat/lib and rock-n-roll.
<Engine name="Catalina" defaultHost="localhost">
<Valve className="org.apache.catalina.valves.AccessLogValve" ...... />
<Valve className="org.apache.catalina.valves.HttpMethodValve"
allow="GET,POST,OPTIONS"/>
<Host name="localhost"
....
/>
</Engine>
markt-2 wrote:
>
> joeweder wrote:
>> I have PUTs disabled but they are still being published as supported in
>> response to the OPTIONS method.
>
> Which is correct as per the HTTP spec.
>
>> Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
>> Server: Apache-Coyote/1.1
>>
>> Actually doing a PUT returns a 403. But "in-house" security scanner just
>> looks at response from the OPTIONS method.
>
> Then your security scanner needs to be fixed.
>
>> Is there any way to get Tomcat 6 from responding to the OPTIONS that it
>> supports the PUT?
>
> You would need to provide your own DefaultServlet implementation. You
> should be
> able to take Tomcat's and override the appropriate method.
>
> Alternatively, you should be able to achieve the same effect with a Filter
> and a
> wrapped response.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/How2-Disable-PUT-response-in-OPTIONS-method-tp22786288p22849145.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How2 Disable PUT response in OPTIONS method
Posted by Mark Thomas <ma...@apache.org>.
joeweder wrote:
> Thanks markt-2. The idea of using a ServletFilter is a good one but will not
> work because the application (we've inherited) does not have a single entry
> point (dispatch/front-controller) yuck. So I'd have to patch it several
> places.
You can map filters to /*
Mark
>
> What I wound up doing was making a little custom valve (HttpMethodValve) and
> added it to the Engine in our server.xml. The valve allows only the methods
> specified (see allow=""), gives a 403 otherwise, and reports only the
> allow(ed) methods in response to OPTIONS. Dropped this little jar in
> tomcat/lib and rock-n-roll.
>
> <Engine name="Catalina" defaultHost="localhost">
> <Valve className="org.apache.catalina.valves.AccessLogValve" ...... />
> <Valve className="org.apache.catalina.valves.HttpMethodValve"
> allow="GET,POST,OPTIONS"/>
> <Host name="localhost"
> ....
> />
> </Engine>
>
>
> markt-2 wrote:
>> joeweder wrote:
>>> I have PUTs disabled but they are still being published as supported in
>>> response to the OPTIONS method.
>> Which is correct as per the HTTP spec.
>>
>>> Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
>>> Server: Apache-Coyote/1.1
>>>
>>> Actually doing a PUT returns a 403. But "in-house" security scanner just
>>> looks at response from the OPTIONS method.
>> Then your security scanner needs to be fixed.
>>
>>> Is there any way to get Tomcat 6 from responding to the OPTIONS that it
>>> supports the PUT?
>> You would need to provide your own DefaultServlet implementation. You
>> should be
>> able to take Tomcat's and override the appropriate method.
>>
>> Alternatively, you should be able to achieve the same effect with a Filter
>> and a
>> wrapped response.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How2 Disable PUT response in OPTIONS method
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: joeweder [mailto:joeweder@gmail.com]
> Subject: Re: How2 Disable PUT response in OPTIONS method
>
> The idea of using a ServletFilter is a good one but
> will not work because the application does not have
> a single entry point (dispatch/front-controller)
??? I'm confused; filters are configured in WEB-INF/web.xml, and require no changes to the webapp's servlets. Why do you think you'd have to modify the webapp itself?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org