Support HTTP extensions beyond HTTP 1.1 spec

[veryrusty]

(Following on from @shadowcat-mst's comment in #595)

The current Runner, Request and Route classes limit the requests method to only those allowed under the HTTP 1.1 spec. There are extensions to the HTTP spec such as WebDAV, that allow further request types.

The DSL is flexible enough to to allow users to add support keywords for such extensions. Do we want to limit Dancer2 to HTTP 1.1 request methods only ?

Assuming we want this flexibility; what's the best way to implement it?
(As a possibly leading idea; the changes in #595 looks likes it could easily be reworked into standalone Middleware)

[xsawyerx]

I agree we should support arbitrary methods. My first thoughts are that we could check for allowed methods by going through methods provided by routes. When a route is added, we can add the method to a hash that is then checked.

What do you think?

[shadowcat-mst]

On Sat, May 31, 2014 at 12:27:21PM -0700, Sawyer X wrote:

I agree we should support arbitrary methods. My first thoughts are that we could check for allowed methods by going through methods provided by routes. When a route is added, we can add the method to a hash that is then checked.

What do you think?

Why not fix the dispatcher to check URL first, then method?

That way we could 405 precisely for each entity type within an app.

Also it's better HTTP :)

Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

[omar-m-othman]

In either case, there must be a new DSL keyword. I suggest

route '/', sub { ... }, { method => 'frobnicate' };

And then we can deprecate all the DSL keywords that correspond to HTTP methods slowly, or move them to a plugin.

The problem with @shadowcat-mst 's suggestion of checking the URL first then the method is that we are going to have everything slower just to serve that purpose, which is (correct me if this is wrong) not supposed to be that common of a case. This line in Dancer2::Core::App

foreach my $route ( @{ $self->routes->{$http_method} } ) {

will become

foreach my $route ( @{ $self->routes } ) {

since you can't do anything but loop all the routes because of those routes defined using regular expressions. You'll then check the method existence in O(1), but still, the average number of checked routes will grow.

I'm more inclined to Sawyer's idea (although it is not an exhaustive check, since we still could throw a 405 from inside if we happen to find the method in that global hash but it was not defined for the matched route, so we could still do without that check) combined with adding the 'route' DSL keyword.

What do you think?

[xsawyerx]

A route keyword sounds good to me. It would also help tackle the alias idea raised in #33.

We will not be deprecating the HTTP method-based keywords. That's for sure. :) That's the main syntax for Dancer and it's not going away.

I would research how others have tackled this. We could have used trie except we have regexp paths so that won't work. Caching the methods and routes would help reduce the overhead of every method to every route and we could generate an index when adding new routes.

I didn't disagree with @shadowcat-mst. He is correct. I was just looking for a way to reduce the overhead it will introduce. Worth pointing out we don't know how big of a overhead it will be.

[DavsX]

@omar-m-othman
route '/', sub { ... }, { method => 'frobnicate' }; this kind of general route dsl is incorrect imho, as it lacks the route options, which are used for route matching (Dancer2::Core::Route->validate_options). Or would they go in the last hash? In that case we'd need to separate the HTTP route header options (used for route matching) from the other ones.

[xsawyerx]

What about route $method => '/' => sub { ... }, $possibly_options; ?