Grokbase Groups Tomcat users May 2010
FAQ
What do most people use to restrict PUT and DELETE http methods?

1. Using a security-constraint with no roles specified in a auth-constraint, with a url-pattern of /* (or appropriate URI) and list the http methods to restrict

OR

2. Set the attribute "readonly" to true in the default servlet in web.xml

Leo

Search Discussions

  • Caldarale, Charles R at May 13, 2010 at 10:14 pm

    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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
  • Leo Donahue - PLANDEVX at May 13, 2010 at 10:22 pm
    Thanks.

    Security audit day. Spent 3 hours making changes - waiting for results, when the tool ended up reporting a false-positive for DELETE.
    Now I know I could have done nothing. Great. I still don't have warm fuzzies about this.

    I think they used IBM Rational App Scan, not sure though.

    Leo

    -----Original Message-----
    From: Caldarale, Charles R
    Sent: Thursday, May 13, 2010 3:13 PM
    To: Tomcat Users List
    Subject: RE: Restrict http methods
    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 13, 2010 at 11:29 pm
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose for
    Tomcat.

    In other words, it is for these methods to actually do something that
    you would have to configure a handler (or a servlet) that contains code
    which handles these methods and does something.

    Actually, I just looked at what the Servlet Spec 3.0 has to say about
    this (2.1), and it does not say much. In particular, it does not say
    exactly what should happen when the servlet does not contain doPut
    and/or doDelete methods.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a "501
    Not Implemented" error code, but I am not sure what it does really.


    Leo Donahue - PLANDEVX wrote:
    Thanks.

    Security audit day. Spent 3 hours making changes - waiting for results, when the tool ended up reporting a false-positive for DELETE.
    Now I know I could have done nothing. Great. I still don't have warm fuzzies about this.

    I think they used IBM Rational App Scan, not sure though.

    Leo

    -----Original Message-----
    From: Caldarale, Charles R
    Sent: Thursday, May 13, 2010 3:13 PM
    To: Tomcat Users List
    Subject: RE: Restrict http methods
    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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


    ---------------------------------------------------------------------
    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
  • Mark Thomas at May 14, 2010 at 7:44 am

    On 14/05/2010 00:28, André Warnier wrote:
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose for
    Tomcat.
    Nope. The default servlet supports both PUT and DELETE but they are
    blocked by default.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a "501
    Not Implemented" error code, but I am not sure what it does really.
    It returns a 403.

    Mark

    Leo Donahue - PLANDEVX wrote:
    Thanks.

    Security audit day. Spent 3 hours making changes - waiting for
    results, when the tool ended up reporting a false-positive for DELETE.
    Now I know I could have done nothing. Great. I still don't have warm
    fuzzies about this.

    I think they used IBM Rational App Scan, not sure though.

    Leo
    -----Original Message-----
    From: Caldarale, Charles R Sent:
    Thursday, May 13, 2010 3:13 PM
    To: Tomcat Users List
    Subject: RE: Restrict http methods
    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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


    ---------------------------------------------------------------------
    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



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 14, 2010 at 8:06 am

    Mark Thomas wrote:
    On 14/05/2010 00:28, André Warnier wrote:
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose for
    Tomcat.
    Nope. The default servlet supports both PUT and DELETE but they are
    blocked by default.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a "501
    Not Implemented" error code, but I am not sure what it does really.
    It returns a 403.

    Mark
    Thanks.
    Just for further information really :
    If there is a webapp context say at /abc, with a servlet url-mapping of
    "/*", and this servlet does not have a doPut() method, does a PUT
    request to /abc get remapped to the default servlet ?

    Leo Donahue - PLANDEVX wrote:
    Thanks.

    Security audit day. Spent 3 hours making changes - waiting for
    results, when the tool ended up reporting a false-positive for DELETE.
    Now I know I could have done nothing. Great. I still don't have warm
    fuzzies about this.

    I think they used IBM Rational App Scan, not sure though.

    Leo
    -----Original Message-----
    From: Caldarale, Charles R Sent:
    Thursday, May 13, 2010 3:13 PM
    To: Tomcat Users List
    Subject: RE: Restrict http methods
    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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


    ---------------------------------------------------------------------
    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



    ---------------------------------------------------------------------
    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
  • Mark Thomas at May 14, 2010 at 8:15 am

    On 14/05/2010 09:06, André Warnier wrote:
    Mark Thomas wrote:
    On 14/05/2010 00:28, André Warnier wrote:
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose for
    Tomcat.
    Nope. The default servlet supports both PUT and DELETE but they are
    blocked by default.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a "501
    Not Implemented" error code, but I am not sure what it does really.
    It returns a 403.

    Mark
    Thanks.
    Just for further information really :
    If there is a webapp context say at /abc, with a servlet url-mapping of
    "/*", and this servlet does not have a doPut() method, does a PUT
    request to /abc get remapped to the default servlet ?
    No. All requests, regardless of HTTP method, get passed to a Servlet's
    service() method. From the reference to doPut(), I assume that the
    servlet in question is extending javax.servlet.http.HttpServlet

    Rather than me describe what that code does:
    http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/HttpServlet.java?view=annotate

    Mark
    Leo Donahue - PLANDEVX wrote:
    Thanks.

    Security audit day. Spent 3 hours making changes - waiting for
    results, when the tool ended up reporting a false-positive for DELETE.
    Now I know I could have done nothing. Great. I still don't have warm
    fuzzies about this.

    I think they used IBM Rational App Scan, not sure though.

    Leo
    -----Original Message-----
    From: Caldarale, Charles R Sent:
    Thursday, May 13, 2010 3:13 PM
    To: Tomcat Users List
    Subject: RE: Restrict http methods
    From: Leo Donahue - PLANDEVX
    Subject: Restrict http methods

    What do most people use to restrict PUT and DELETE http methods?

    2. Set the attribute "readonly" to true in the default servlet in
    web.xml
    The readonly attribute defaults to true, so most people do ... nothing.

    - 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


    ---------------------------------------------------------------------
    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



    ---------------------------------------------------------------------
    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



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Honey Bajaj at May 14, 2010 at 9:22 am
    Hi All,

    I have enabled manager application on tomcat 5.5.9 added the required context and security options. I am able to logon to the manager application both the status and jmxproxy are accessible but jmxproxy didn't contain any details related to java.lang:type (such as java.lang:type=GarbageCollector,name=Copy=GarbageCollector,name=Copy or java.lang:type=OperatingSystem)

    $CATALINA_HOME/conf/Tomcat-users.xml
    <role rolename="manager"/>
    <user username="admin" password="admin" roles="manager"/>

    $CATALINA_HOME/conf/Server.xml
    <Context path="/manager" debug="0" privileged="true"
    docBase="/usr/local/Be-tomcat-5.5.9/server/webapps/manager">
    </Context>

    ${CATALINA_HOME}/conf/Catalina/localhost/manager.xml
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="<localhost IP Address>"/>

    Please could you advise what can be done to resolve this issue.

    Thanks
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at May 14, 2010 at 9:51 am
    Please post a new message, rather than replying to an existing message
    and editing the subject/body - which is called 'thread hijacking'.


    p
    On 14/05/2010 10:17, Honey Bajaj wrote:
    Hi All,

    I have enabled manager application on tomcat 5.5.9 added the required context and security options. I am able to logon to the manager application both the status and jmxproxy are accessible but jmxproxy didn't contain any details related to java.lang:type (such as java.lang:type=GarbageCollector,name=Copy=GarbageCollector,name=Copy or java.lang:type=OperatingSystem)

    $CATALINA_HOME/conf/Tomcat-users.xml
    <role rolename="manager"/>
    <user username="admin" password="admin" roles="manager"/>

    $CATALINA_HOME/conf/Server.xml
    <Context path="/manager" debug="0" privileged="true"
    docBase="/usr/local/Be-tomcat-5.5.9/server/webapps/manager">
    </Context>

    ${CATALINA_HOME}/conf/Catalina/localhost/manager.xml
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="<localhost IP Address>"/>

    Please could you advise what can be done to resolve this issue.

    Thanks
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 14, 2010 at 12:07 pm

    Mark Thomas wrote:
    On 14/05/2010 09:06, André Warnier wrote:
    Mark Thomas wrote:
    On 14/05/2010 00:28, André Warnier wrote:
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose for
    Tomcat.
    Nope. The default servlet supports both PUT and DELETE but they are
    blocked by default.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a "501
    Not Implemented" error code, but I am not sure what it does really.
    It returns a 403.

    Mark
    Thanks.
    Just for further information really :
    If there is a webapp context say at /abc, with a servlet url-mapping of
    "/*", and this servlet does not have a doPut() method, does a PUT
    request to /abc get remapped to the default servlet ?
    No. All requests, regardless of HTTP method, get passed to a Servlet's
    service() method. From the reference to doPut(), I assume that the
    servlet in question is extending javax.servlet.http.HttpServlet

    Rather than me describe what that code does:
    http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/HttpServlet.java?view=annotate
    Allright, I think I get it now. My mindset is just not Java- or
    object-enough oriented for me to think of that right away.
    So a servlet subclasses (or implements) HttpServlet, and if it does not
    itself override the doPut and doDelete methods, the ones from the base
    class (or interface) apply.
    And these return 403.

    Thanks for enlightening me.

    Leo, are you still with us ?
    ;-)

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Leo Donahue - PLANDEVX at May 14, 2010 at 2:39 pm
    -----Original Message-----
    From: André Warnier
    Sent: Friday, May 14, 2010 5:07 AM
    To: Tomcat Users List
    Subject: Re: Restrict http methods

    Mark Thomas wrote:
    On 14/05/2010 09:06, André Warnier wrote:
    Mark Thomas wrote:
    On 14/05/2010 00:28, André Warnier wrote:
    Leo,

    normally in the default config of a webserver, these methods are by
    default disabled, for the simple reason that there is no "handler"
    defined for them. That is the case for Apache httpd, and I suppose
    for Tomcat.
    Nope. The default servlet supports both PUT and DELETE but they are
    blocked by default.
    I suppose that Tomcat could return a "405 Method Not Allowed" or a
    "501 Not Implemented" error code, but I am not sure what it does really.
    It returns a 403.

    Mark
    Thanks.
    Just for further information really :
    If there is a webapp context say at /abc, with a servlet url-mapping
    of "/*", and this servlet does not have a doPut() method, does a PUT
    request to /abc get remapped to the default servlet ?
    No. All requests, regardless of HTTP method, get passed to a Servlet's
    service() method. From the reference to doPut(), I assume that the
    servlet in question is extending javax.servlet.http.HttpServlet

    Rather than me describe what that code does:
    http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/http/Http
    Servlet.java?view=annotate

    Allright, I think I get it now. My mindset is just not Java- or object-enough oriented for me to think of that right away.
    So a servlet subclasses (or implements) HttpServlet, and if it does not itself override the doPut and doDelete methods, the ones from the base class (or interface) >apply.
    And these return 403.
    Thanks for enlightening me.
    Leo, are you still with us ?
    ;-)

    Yes. I wasn't implementing doPUT or doDELETE and was scratching my head trying to figure out how the security scan was able to indicate those methods were available.

    Pid - see, I told you I have a lot to learn....

    Btw, I had no idea that the code is published on the web. Very cool. Now you've got me on a diversion... So many questions....


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 14, 2010 at 3:29 pm
    Leo Donahue - PLANDEVX wrote:
    ...
    Yes. I wasn't implementing doPUT or doDELETE and was scratching my head trying to figure out how the security scan was able to indicate those methods were available.
    Then it very much looks right now as if it is the scanner which is faulty.
    Being mainly a perl guy, I know this tool which would tell you how the
    Tomcat reacts : lwp-request
    It is a perl command-line tool which allows to create and send a HTTP
    request to a server, and see the returned answer in detail.
    lwp-request --help will tell you all about it.
    e.g.

    # lwp-request -m PUT -Sed http://localhost:8180/some-url
    Please enter content (text/plain) to be PUTed:
    abcdef
    ^D
    PUT http://localhost:8180/some-url --> 403 Forbidden
    Connection: close
    Date: Fri, 14 May 2010 15:24:55 GMT
    Server: Apache-Coyote/1.1
    Content-Length: 958
    Content-Type: text/html;charset=utf-8
    Client-Date: Fri, 14 May 2010 15:24:55 GMT
    Client-Peer: 127.0.0.1:8180
    Client-Response-Num: 1
    Title: Apache Tomcat/5.0 - Error report

    So, it does respond 403.
    Mark was right. How does he know these things ?

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Caldarale, Charles R at May 14, 2010 at 3:53 pm

    From: André Warnier
    Subject: Re: Restrict http methods

    So, it does respond 403.
    Mark was right. How does he know these things ?
    Because he writes a bunch of the Tomcat code... and reads nearly all of the rest of it.

    - 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
  • Hassan Schroeder at May 14, 2010 at 4:06 pm

    On Fri, May 14, 2010 at 8:28 AM, André Warnier wrote:

    trying to figure out how the security scan was able to indicate those
    methods were available.
    Then it very much looks right now as if it is the scanner which is faulty.
    A client of mine (at a VeryLargeCo) had to have a "security scan" of
    the project done by an internal group using some automated tool from
    AnotherVeryLargCo.

    It produced pages and pages of the most laughably irrelevant crap.
    Most of it was so wildly wrong I would have sworn it was run against
    some other server, on some other planet, in some other dimension.

    Seriously, a complete waste of time and energy all the way around.

    --
    Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
    twitter: @hassan

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Mark Thomas at May 14, 2010 at 4:07 pm

    On 14/05/2010 16:28, André Warnier wrote:
    Leo Donahue - PLANDEVX wrote:
    ...
    Yes. I wasn't implementing doPUT or doDELETE and was scratching my
    head trying to figure out how the security scan was able to indicate
    those methods were available.
    Then it very much looks right now as if it is the scanner which is faulty.
    Scanners usually do an OPTIONS request and then complain when the PUT,
    DELETE or TRACE are included in the Allow header of the reponse.

    <rant>Putting to one side that TRACE is only considered a security risk
    due to the non-spec compliant behaviour of a certain browser and
    therefore the software the scanners should be complaining about is the
    browser not a 100% secure, spec compliant web server
    implementation</rant> the scanners don't try a PUT, DELETE or TRACE
    request to see whether or not the request will be permitted. The
    scanners do this to test in a non-destructive way. If they actually
    tried a DELETE and it worked folks may get upset.

    TRACE & PUT could be tested safely but it is hard to test DELETE without
    causing some damage if it is permitted.

    Mark



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 14, 2010 at 6:43 pm
    Mark Thomas wrote:
    ...
    TRACE & PUT could be tested safely but it is hard to test DELETE without
    causing some damage if it is permitted.
    Well, you could DELETE http://localhost/some-highly-unlikely-url
    and check if you get a 404, couldn't you ?


    Although I do remember writing once a URL-checker program and its test
    suite, where I used domain names like
    http://unknown-domain.com
    http://inexistant.com
    etc..
    and be surprised as to how many of those actually do exist.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at May 15, 2010 at 8:42 am

    On 14/05/2010 19:43, André Warnier wrote:
    Mark Thomas wrote:
    ...
    TRACE & PUT could be tested safely but it is hard to test DELETE without
    causing some damage if it is permitted.
    Well, you could DELETE http://localhost/some-highly-unlikely-url
    and check if you get a 404, couldn't you ?
    ... accidentally triggering an obscure bug, which <insert massive FAIL
    here>.
    Although I do remember writing once a URL-checker program and its test
    suite, where I used domain names like
    http://unknown-domain.com
    http://inexistant.com
    etc..
    and be surprised as to how many of those actually do exist.
    exactly.


    p
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • André Warnier at May 15, 2010 at 11:25 am

    Pid wrote:
    On 14/05/2010 19:43, André Warnier wrote:
    Mark Thomas wrote:
    ...
    TRACE & PUT could be tested safely but it is hard to test DELETE without
    causing some damage if it is permitted.
    Well, you could DELETE http://localhost/some-highly-unlikely-url
    and check if you get a 404, couldn't you ?
    ... accidentally triggering an obscure bug, which <insert massive FAIL
    here>.
    Tomcat being Open Source, there cannot be obscure bugs. They are all
    very visible.
    But I recant. The request above should have been
    DELETE http://localhost/program%20files/internet%20explorer
    So that if by any chance it works, one wouldn't lose anything essential.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Pid at May 15, 2010 at 11:41 am

    On 15/05/2010 12:25, André Warnier wrote:
    Pid wrote:
    On 14/05/2010 19:43, André Warnier wrote:
    Mark Thomas wrote:
    ...
    TRACE & PUT could be tested safely but it is hard to test DELETE
    without
    causing some damage if it is permitted.
    Well, you could DELETE http://localhost/some-highly-unlikely-url
    and check if you get a 404, couldn't you ?
    ... accidentally triggering an obscure bug, which <insert massive FAIL
    here>.
    Tomcat being Open Source, there cannot be obscure bugs. They are all
    very visible.
    Of course, I meant in an application servlet implementing a DELETE method...
    But I recant. The request above should have been
    DELETE http://localhost/program%20files/internet%20explorer
    So that if by any chance it works, one wouldn't lose anything essential.
    Quite.


    p
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
  • Konstantin Kolinko at May 14, 2010 at 12:45 pm

    2010/5/14 Leo Donahue - PLANDEVX <LeoDonahue@mail.maricopa.gov>:
    What do most people use to restrict PUT and DELETE http methods?
    Besides what was already said here, you can always write a Filter and
    configure it in ${catalina.base}/conf/web.xml -- it will be present
    in all web application on your Tomcat instance. (In assumption that
    none of them actually needs DELETE).

    Best regards,
    Konstantin Kolinko

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriestomcat
postedMay 13, '10 at 10:10p
activeMay 15, '10 at 11:41a
posts20
users8
websitetomcat.apache.org
irc#tomcat

People

Translate

site design / logo © 2021 Grokbase