Support more HTTP methods/verbs

[devnoname120]

Summary

hurl only supports a very limited subset of the available HTTP methods. See:

hurl/packages/hurl_core/src/parser/parsers.rs

Lines 137 to 147 in 6fc568a

	let available_methods = vec![
	("GET", Method::Get),
	("HEAD", Method::Head),
	("POST", Method::Post),
	("PUT", Method::Put),
	("DELETE", Method::Delete),
	("CONNECT", Method::Connect),
	("OPTIONS", Method::Options),
	("TRACE", Method::Trace),
	("PATCH", Method::Patch),
	];

But there are many more HTTP methods defined HTTP Method Registry: https://www.iana.org/assignments/http-methods/http-methods.xhtml

The problem

Many APIs such as the WebDAV protocol require methods that hurl rejects, such as PROPFIND: https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/basic.html#testing-requests-with-curl

Solution

Don't restrict the HTTP methods that can be used, support any string instead.

Many APIs use custom methods that are not even part of the HTTP Method Registry that I linked to. So while adding the methods from this registry would already be a very nice step forward, it wouldn't solve everything.

[jcamiel]

Thanks for this good feedback, I myself wasn't aware of the other HTTP methods 😓...

One thing to take note is that being explicit in the fileformat (having a whitelist of method) helps the parser. For instance, we really want to improve the tooling around Hurl. Having well known "syncing" point, like a known list of HTTP method, will make the parser work easier, specially for recovery in case of syntax error.

Right away, we can at least add other HTTP methods (for instance Postman support GET, POST, PUT, PATCH, DELETE, COPY, HEAD, OPTIONS, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND and VIEW) and give us some time to think on this issue.

[devnoname120]

@jcamiel Sounds good to me. This is a first easy step that solves 99% of the limitations: custom methods outside of this list aren't frequently used.

---

I see hurl as a convenient tool to run frequently-used HTTP requests, using a syntax that is more eye-friendly than cURL. From my perspective, hurl should ideally do as much as it can to accommodate malformed requests without getting in the way of the user (unless it can't parse them at all). Some obscure APIs violate the HTTP standard — it would be nice if hurl could interact with them anyway.

A potential solution would be to display warnings instead of erroring out when a slightly-malformed request is run (just like HTML parsers which are very resilient). I'm not sure it's a priority at this stage of the project though — just wanted to share my thoughts. :)

[gladykov]

Hi guys, I'm trying to solve one mystery. Where does VIEW method comes from?

Postman forums does not know it https://community.postman.com/t/what-is-view-method/11053/2 , HTTP Method Registry does not now it, Google does not know it. Any clues / ideas?

[jcamiel]

I have no idea! I shamelessly took the methods supported by Postman...

[gladykov]

Haha, all shame then on Postman ;)

[jcamiel]

Hi @gladykov your comment makes me think!

I don't like that we perpetuate an "unknown" HTTP method in Hurl (VIEW).
Going back to @devnoname120's initial need, we wanted a way to make a request with any possible method (like curl). I think we can have a better syntax to really support any method:

• use keyword for "classic" HTTP methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
  In a Hurl file:

GET https://foo.com
HEAD https://foo.com
POST https://foo.com
PUT https://foo.com
# etc...
PATCH https://foo.com

• use METHOD key work followed by a string to support any other method like PROPFIND, VIEWetc..

METHOD "VIEW" https://foo.com
METHOD "LINK" https://foo.com

These have the followings advantages:

• do not encumbered the current Hurl file format with "legacy" methods
• support any custom method like curl
• support "out-of-the-box" for potential new methods (like QUERY method, see this discussion)

I like it a lot (obviously 😊), we could deprecate (or remove) LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND, VIEW in favor of METHOD "xxx" in a next Hurl version.

[jcamiel]

Another syntax (maybe better) for custom methods:

• "classic" :

GET https://foo.com
HEAD https://foo.com
POST https://foo.com
PUT https://foo.com
# etc...
PATCH https://foo.com

• custom:

"VIEW" https://foo.com
"PROPFIND" https://foo.com
"GET" https://foo.com
"QUERY" https://foo.com

[gladykov]

Happy that I could be an inspiration :) Happy coding!

[jcamiel]

What we've finally implemented: the method can be any word ([A-Z]+) without quotes. We've added the only constraint of being uppercase (for parsing reason with edge case). In the doc, we're going to only reference the "standard" HTTP method and make clear that a custom (new or legacy) HTTP method is possible:

POST https://foo.com

QUERY https://foo.com

BAR https://foo.com

No file format change except more custom method are allowed.