add Methods set field to http trigger configuration options

[michelleN]

[[trigger.http]]
route = "/hello"
methods: ["GET", "POST"]

This way a component will only be executed if route and method matches. Omitting the methods section would result in current behavior of the component being executed regardless of request method.

[vdice]

@michelleN what type of response (status code, etc) would clients receive when they make an unsupported request to an http component? (eg curl -X PUT ... to the example app above)

[lann]

405 Method Not Allowed

[itowlson]

Thinking about cases we need to define...

Longer but ineligible routes

Suppose I have a route /cart/login for method GET only and /cart/... with no method restrictions. How should I interpret a POST to /cart/login?

1. I don't accept POSTs to /cart/login. Reject with a 405.
2. I accept POSTs to /cart/..., and the longer route doesn't match because of method. Accept on /cart/....

My suspicion is that case 1 is more likely what users want, so we can stick to the simple "longest match" rule. But I don't trust myself to pick this one right!

Multiple occurrences of a route

I assume it would be allowed to have separate triggers for GET /cart and POST /cart. And, in such as case, if the method sets overlapped, it would be a validation error.

Would it be allowed to have separate triggers for GET /cart and (unrestricted) /cart (with the more specific one taking priority)?

Anything else we need to ponder?