http-client

http-client copied to clipboard

Hi there,

I'm using req, which is a higher level package on top of http-client. Using the former, I felt the need to be able to provide URIs with file scheme.

My use case is to be able to mock requests during testing. In my application, the end user provides a URL which then I fetch and parse. As I trust that req and http-client are working correctly, I think I don't need my test suite to depend on external resources that can make it non-deterministic. For that reason, I would like to be able to provide a local file URI instead of an http or httpsschema in my tests. The contents of the file would be the response body.

Following the conversation in req (https://github.com/mrkkrp/req/issues/47), the logical conclusion we have found is that, if it is considered a good idea, it should be added in http-client and then req adapted with the new changes.

How do you see it?

It's a nice idea, though I'm a bit conflicted about it. I can imagine it being a bit surprising that parseRequest will suddenly work on file:///. Other than that, it doesn't seem like it should be a problem, assuming the implementation isn't too invasive. Perhaps having a separate parseFileRequest function could deal with that.

Did you have any thoughts on how you'd go about this?

I haven't look at the internals of http-client, because I have been working only with the upper layer (req). But as I see it, in the case of the feature being added, it should be in the same parseRequest method. Otherwise it would not be useful for my use case: being able to transparently provide a file URI in my tests to a higher function which internally uses parseRequest.

Depending on how everything is implemented, maybe the feature could be imported ad-hoc through a Network.HTTP.Client.File module implementing needed typeclasses for a new scheme. But it is also possible that it simply would crash current API... :)

I'm happy to discuss this as a more concrete proposal, but this isn't a concrete enough proposal yet. I see only two options: turning it on unqualified, and using a different parse function. The former could be very confusing to users of the API, and you've rejected the second.

Thanks @snoyberg . I'll try to find the time to inspect closely http-client implementation and come back with something more conrete.