Issue #102 resolved

Dispatch to different page handlers based on HTTP method

Anonymous created an issue

Comments (14)

  1. Anonymous

    Might be important information about using these verbs:

    ''The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9. '' br ''From: [http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 Hypertext Transfer Protocol -- HTTP/1.1 section 5.1.1]

    we might want to add something for this to. And especially, the 405 and 501 might well become special enough to give them their own Exception or something.

    Also, the RFC states in section 5.1.1: The method is case-sensitive. So it's time for some patching.

  2. Anonymous

    Along with the case-sensitivity the ticket-102 branch now also tests for the lowercased word if the httpverb in it's transfered case wasn't found. br Lowercased is therefor a fallback: method.VERB is tested first (as normally verbs are capital, but this could therefore well be method.VeRb) and if this can't be found, method.verb is searched for.

    This should be about it.

    Unless tests prove there is something wrong, ticket #102 should be solved. But for testing, let's keep it open for a while.

    Changesets involved: changeset [171], changeset [172], changeset [173] , changeset [174]

  3. Anonymous

    Based on an IRC dicussion, we'll have to see if cpg.request.body should be stored every time. or that we can simply skip the reading of the request to a memory buffer before hand.

    It's not a requiredment right now, but things like the [http://code.blogspot.com/archives/atom-docs.html#edit-post blogger api] show examples where it would be neat, to have direct access to this request.

    Seems to me, having to write a filter for everytime this would be used, is harder then writing a filter once to support file uploading. But this could also be used the other way around - i know. . .

  4. Robert Brewer

    Dispatching for HTTP methods via attributes is error-prone. For example, "/app/resource/options/view/123" will deny any dispatching to "/app/resource" with the OPTIONS method, since the two requests will share the same lookup mechanism.

    It was decided (on IRC this morning) that we should wait to implement a builtin method-dispatch system until after 2.1, if ever. Therefore, here is a MethodDispatchRecipe that should work in the interim.

  5. Robert Brewer

    A historical summary:

    • DaveW asked the cp-devel ML about two things: restricting methods and method dispatch.
    • Remi proposed a system for restricting methods: index.exposed = ("GET", "POST").
    • Everyone latched onto dispatch and forgot about restrictions.
    • Remco proposed a dispatch solution.
    • Remi approved of it, reversing his previous recommendation to restrict via the .exposed attribute.
    • I pointed out (above) that the dispatch recipe is error-prone.
    • The topic has been stalled since June.

    Let's go back to Remi's original proposal, and implement at least half of this ticket: let's restrict HTTP methods on a handler via the .exposed attribute. To ease migration, allow .exposed to be True, False, or an iterable of allowed methods (set, tuple, list, generator, etc.). If iterable, some methods are allowed; if True, all methods are allowed; if False (or an empty container), no methods are allowed. If exposed is an iterable, an Allow header will be output. Finally, @cherrypy.expose will have to be rewritten to take a set of methods as an argument (or *args).

    The other half, method dispatch, can very easily be done with a variety of base classes or other strategies, none of which will please everyone; these can all be published on the Wiki or in lib/cptools (or in lib/dispatchers if we go that far).

  6. Log in to comment