Url parsing: align parsing implementation with grammar

[jcamiel]

In the Hurl grammar, URL is parsed as:

request:
  lt*
  method sp value-string lt
  header*
  request-section*
  body?

Where value-string is a "common" token : in particular, as value-string, URL should accept Hurl unicode literals (ex: \u{7b}), or curly braces ({). Related to discussion https://github.com/Orange-OpenSource/hurl/discussions/3243, we should accept the following Hurl file where the URL contains {and }without being URL encoded:

GET https://www.example.com/index.html?foo={bar}
HTTP 200

[fabricereix]

@jcamiel @lepapareil Related to using a standard Hurl string value for url, do we also apply the following changes?

• http:// or https:// protocol prefix not checked anymore at parse-time
• https:// will be added at runtime as a default

[jcamiel]

Both seem OK! You can also do some "git blaming" on the function that checks the http/https prefix to see why we added it: I remember adding an integration test for it but don't remember what has triggered it...

[muffl0n]

Can't we just outsource the validation to curl? Just give it to curl and see if it accepts it. After replacing the vars, of course.

[jcamiel]

There are some logic regarding redirection where we must transform the value of the url to an URL structure so I think we can't simply accept any value and pass it to libcurl.

[fabricereix]

I think the http:// prefix check was simply here to fail as early as possible with nice error message.