port not part of Url about req HOT 12 CLOSED

Ah well I wrote this issue because a colleague complained about having to put the port number in the options :-)

IMO it would make more sense to put everything that is in the RFC URL in the req Url. Otherwise why not put the protocol in the options, or the host or especially the path? If you are going to separate them then at least separate only the things that change, i.e. the path and params. Port definitely belongs with the host and protocol. IMO :)

from req.

I can see how it makes sense, but the Url type is rather a convenient way to pass certain pieces of information (scheme, host, path) to the req function, it does not represent a URL as per RFC.

The question to ask here: is this way of constructing a request is more convenient for end user, compared to what we have right now (options passed in the last monoid argument to req). I would think that the current approach is more handy and flexible, keeping Url construction relatively lightweight.

from req.

I'm also running into this issue. It's fairly often for me that URL construction happens at a different place than HTTP calls, and req is awkward in those situations. Right now I define type HttpsUrl = (Url 'Https, Options 'Https) and pass HttpsUrls around, but that's not a great long term solution.

I think it really comes down to the goal of this library. Is it to have an easy way to construct and make an HTTP request in one function call? If so it's definitely doing a great job, but isn't going to be the right choice in my case. Or is it to be a great high-level HTTP library? If that's the case it will need a URL type. It would be cool to provide a safer alternative to uri-bytestring, but that's getting ahead of ourselves until the earlier question is answered.

from req.

Are you aware of https://hackage.haskell.org/package/modern-uri BTW?

from req.

Nope, that looks amazing. Is there a suggested way to make HTTP requests with modern-uri?

from req.

Not yet, but I'll think about this.

from req.

Awesome, that seems like the last piece of the puzzle.

from req.

OK, I think we could have a bridge package that would allow to turn a URI into a pair of (Url scheme, Option scheme) like what we have for parsing of URLs from ByteStrings:

https://hackage.haskell.org/package/req-1.0.0/docs/Network-HTTP-Req.html#v:parseUrlHttp

I however do not intend to write it at this time, if you like, you can write it, it's quite trivial.

from req.

I'm currently using:

convertUriHttps :: URI -> Maybe (Url 'Https, Option scheme)
convertUriHttps = parseUrlHttps . renderBs

It would be nice if these two packages used the same URL types, but this'll do for now.

from req.

I can understand the sentiment and I considered it myself, but there are some points that prevent me from using modern-uri in req directly:

• URI from modern-uri is too general. It allows any scheme, not just HTTP(S) schemes. With the level of safety we want in req, it's not acceptable.

• URI is not tagged at the type level with Http vs Https.

• Automatic conversion of values of types that are instances of ToHttpApiData to Text is super nice and the whole system of combinators for building of URIs in req is well-suited for what the package tries to achieve. URI wouldn't be so good in this role.

So helper conversion functions is the best way so far to make modern-uri and req play nicely together, I think.

from req.

I just threw this together: https://hackage.haskell.org/package/req-url-extra. Maybe it will be useful to others. The functions are now named toUrlHttp and toUrlHttps.

from req.

I think we can close this. URL type provided by this library is not a general-purpose URL/URI type, but a part of API of this specific library. These things should not be confused as they serve different purposes and satisfy different requirements.

from req.