Set status to 405 when the method is wrong but route matches

[casualjim]

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.6

Set status to 405
Set Allow header

[rossabaker]

For the Allow header, where GET is allowed, HEAD should be too. That one would be easy forget.

[rossabaker]

wfaler mentions both servlets and filters. Servlet is straightforward, but filter is trickier: if we don't find a route, then we call the filter chain, which may or may not support the method. How does the filter know what the servlet supported without a working response.getStatusCode? Do we need to make GetResponseStatusWrapper standard? And what if different methods are supported by different filters in the chain? Do we need to support aggregating allowed methods through the chain?

[rossabaker]

Even if we had response.getStatusCode, the servlet would have already committed the 404. There's no good way for a filter to call the chain and then set the 405 only if the chain did nothing useful.

Maybe we should have a methodNotAllowed hook. Default implementation sends a 405, but ScalatraFilters are welcome to override and call the chain, just like notFound does.

[rossabaker]

Not closed yet due to corner cases:

• GET implies HEAD
• Servlet gives us TRACE for free.
• Servlet gives us naive implementation of OPTION for free. Now that we're trawling through other methods anyway, we could provide a smarter implementation of OPTION.

These free methods from the servlet spec will all need to be kept in mind in SSGI. As Cinderella once sang, "You don't know what you've got, 'til it's gone." Yeah, it's 2:30am, and I'm quoting Cinderella.

[rossabaker]

We don't actually call the servlet's default OPTION and TRACE, so those other corner cases don't actually exist yet.