Allow construction of client responses?

[bennofs]

Currently, there is no way to manually construct a client::Response without going through the http Client. It would be nice if it was possible to simply load a response from a file. Right now, the only way to do that would be to write a custom connector that loads the file and ignores the passed Uri, but that seems kind of ugly to me?

Also, in the same vein, it would be nice if there was a way to write a Response to a file. This seems very hard right now. You can do it with a custom connector, but that really does not feel like the right level because you'd have to handle things like reuse of connections and parsing the URL out of the request bytes (so you have one extract parsing step that is unnecessary).

[crackcomm]

Maybe response could be shared between client and server so easily proxied, sharing a single builder.

[bennofs]

Yeah it would also work if client/server Response and Request types were the same.

[seanmonstar]

Currently, there is no way to manually construct a client::Response

This is actually by design, for now. Keeping the construction private allows us to adjust the internal pieces without causing breaking changes.

it would be nice if there was a way to write a Response to a file.

I sympathize with the desire to have something like this, but I'm not sure doing it in hyper is the right place. Looking around in other languages HTTP libraries, they don't typically have this either. Probably because it's not something that everyone needs, and since it can be done in an external library, that's where it typically goes. It'd probably be a nice crate to exist, one that can provide a Connect and custom AsyncRead + AsyncWrite that can pipe the data off to a file!

it would also work if client/server Response and Request types were the same.

Unifying the the client::Request with server::Request and client::Response with server::Response is a definite possibility. There's a few kinks to work out for that, but probably better for a different issue.

[bennofs]

How could saving to files be implemented in another crate? Wouldn't this basically require this other crate to have it's own http parser, to parse the requests and headers out of the stream?

[seanmonstar]

Maybe we're thinking of different things. Why would you need to parse headers? I assumed you meant recording all the raw bytes, so parsing them isn't required. The Connect receives a Uri, which you can use to name some files, and then your returned io can copy bytes to the files while also sending and receiving on the socket.

Do you mean only writing to file the message bodies?

[bennofs]

@seanmonstar Yeah connect receives an URI, but the connection may be re-used if you don't disable connection pooling. And I would like it to work with connection pooling, as it would still make the request after logging it.

[seanmonstar]

In that case, yes, you would need to do some HTTP parsing to be able route the specific requests to specific files. If you're doing to record some data to use for testing, it'd be easier to do so with keep-alive enabled.

[seanmonstar]

The constructors for a Request and Response are now publicly available, so I'm closing.