Add support for the TRACE HTTP verb?

[webron]

No description provided.

[jharmn]

+1 seems like an easy win.

[webron]

We should do a quick investigation as to which verbs we should add. SEARCH is another, could be others as well.

[fehguy]

agreed

[tomchristie]

HTTPbis: https://tools.ietf.org/html/rfc7231#section-4
Method registry: http://www.iana.org/assignments/http-methods/http-methods.xhtml

The following options would seem valid:

• Just RFC7231.
• All registered methods (not convinced by that, tho).
• Underspecified - RFC7231 must be supported, some clients/readers may support others.

[jharmn]

Covering RFC7231 would also address OPTIONS, which comes up a lot with CORS support (among a myriad of other uses).
I also agree that all registered methods probably doesn't do anyone much good...but I'm also not convinced it hurts anything.
I really like the RFC7231 MUST + IANA MAY option.

[daedeloth]

I also vote for to implenet http://www.iana.org/assignments/http-methods/http-methods.xhtml
This would also fix #480

[darrelmiller]

Adding SEARCH would be nice if it was defined to be simply a safe request with a body that describes the query. But RFC 5323 goes much further than that. It says that a resource that responds to SEARCH method MUST process application/xml and text/xml. Successful responses must return a 207 with a specifically defined response body

Unfortunately, SEARCH is so inextricably intertwined with WebDAV that it is really no use elsewhere. Unless of course you are going to pick and choose the bits of the spec versus the bits you don't but at that point, you might as well invent your own method called FIND or QUERY and write your own spec. At least then you will avoid the ambiguity.

There is not much harm saying that you can use all of the IANA registered methods in OpenAPI, but some of them are less useful than they first appear.

[webron]

TRACE has been there... for a while.