Routes restricted to HEAD fail to be matched

"It makes no sense to restrict a route to just HEAD requests."

That's a bit dogmatic (or should I say "opinionated"?). I need a low- cost action/resource that allows a (mobile web service) client to periodically authenticate or confirm authentication via HTTP_AUTH. Sure, I could make the client GET an existing resource (expensive for the server), but why? So we have a simple action (no DB, no calcs, no nothing!) that is only capable of returning header data.

Once you accept that such a method deserves to live, it's easy to accept that it should be restricted to HEAD -it allows buggy clients to be spotted at the server with an exception being raised.

It's my understanding that a HEAD request to a URI should always return exactly the same headers as a GET request to the same URI. By restricting methods allowed on the URI to only HEAD you would break this rule. A HEAD request would return either status code 200 or 401, while a GET request would return 405.

I agree that your cheap authentication action deserves to exist, but it doesn't follow that it should be restricted to only handle HEAD. Instead, you should also handle GET, returning either a very simple body (such as just 'OK') or no body at all if you prefer. This would be just as cheap, without breaking the implicit HTTP contract.

Tom,

Thanks for taking the time to look at this ticket a second time. I accept that this request is not going to be implemented, and I can live with it.

It might be a good idea to document this restriction because it is accepted when routes are built, but then fails with a contradictory error message at run time.

Now that sounds like a valid bug which should certainly be fixed.

Lawrence, good find. I guess that really puts a nail in the coffin.