geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Sportes (JIRA)" <...@geronimo.apache.org>
Subject [jira] Commented: (GERONIMO-2420) No support of WebDAV http-methods (MKCOL ...) in web-app with security-constraint
Date Fri, 22 Sep 2006 07:58:22 GMT
    [ http://issues.apache.org/jira/browse/GERONIMO-2420?page=comments#action_12436776 ] 
            
Daniel Sportes commented on GERONIMO-2420:
------------------------------------------

Of course David you are pretty much obligated to validate the web.xml against the "official"
spec.
I patched this schema locally just for testing if your implementation was related to it: it
seems that it is not, at least not with the external file reachable in the %install%/schema
directory.
The Servlet 2.5 spec has the same list of http-method (I checked this morning): as consequence
the Servlet spec is NOT compliant with the WebDAV spec and the implementation done for example
by the Slide project is not compliant with the Servlet spec (however working in Tomcat).
It could be a first track to add in the geronimo-web.xml an element http-method-list as sub
element of security for allowing (actual and future) extensions of the http protocol.
It could also be a track in changing a bit your interpretation of that list when empty. When
there is NO http-method element at all in the security-constraint element, ALL methods are
concerned. it is exactly what I wished as any WebDAV implementers: however in this case you
do not route all methods on the service() method of the servlet but only some of them (GET,
POST, PUT ...). Why checking anything there, and only in case of security-constraint ? When
I remove the security-constraint applicable to the servlet path, the service() method receives
correctly ALL methods (even MKCOL, PROPFIND, etc.). Just align the checking implemented on
the most open (the one you implemented without security-constraint), without changing anything
else in the deployment part. This kind of change would not appear as a regression for actual
existing developments.
You can find out WebDAV spec at http://www.webdav.org/specs/. It was probably not the best
way to extend http method lists (new headers for a POST would be simpler) but they did and
several implementations (typically of Explorer in Windows) are largely used.
I do not know if some other specs as WebDAV also extend the HTTP method list.


> No support of WebDAV http-methods (MKCOL ...) in web-app with security-constraint
> ---------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2420
>                 URL: http://issues.apache.org/jira/browse/GERONIMO-2420
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: deployment
>         Environment: Release in WASCE (probably 1.0) - Windows XP - Java 1.5
>            Reporter: Daniel Sportes
>         Attachments: err.log, server-Bug-Deployment.log, web-app_2_4b.xsd, web.xml
>
>
> The schema web-app_2_4.xsd does not accept WebDAV http-method as PROPFIND, MKCOL, etc.
in security-constraint (in web.xml).
> As consequence as I develop a business server based on WebDAV, I cannot require an authentication
for accessing the WebDAV servlet. Just observe it is possible with Tomcat.
> As the error message indicates the web-app_2_4.xsd schema, I patched this schema in the
directory %install%/schema.
> Eclipse is now happy and does not mark anymore my web.xml in error.
> However, this causes an exception at deployment in the server.
> If I remove all forbidden http-method, no more deployment exception of course, but I
do not receive PROPFIND method calls in my servlet.
> If I completely remove the security-constraint section, PROPFIND methods are correctly
received in my servlet ... but the user authentication is no more required (that is not an
acceptable solution for a business server). The method list seems to be coded somewhere else
than in the schema.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message