[Haskell-cafe] Contributing to http-conduit

[Michael Snoyman]

On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield
<myles.maxfield at gmail.com> wrote:
> Alright, that's fine. I just wanted to be explicit about the interface we'd
> be providing. Taking the Request construction code out of 'http' and putting
> it into its own function should be a quick change - I'll have it to you
> soon. One possible wrench - The existing code copies some fields (like the
> proxy) from the original request. In order to keep this functionality, the
> signature would have to be:
>
> checkRedirect :: Request m -> Response -> Maybe (Request m)
>
> Is that okay with you? I think I'd also like to call the function something
> different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add an
> example to the documentation about how a caller would get the redirection
> chain by re-implementing redirection (by using the example in your previous
> email).

Sounds great.

> As for cookie handling - I think Network.Browser has a pretty elegant
> solution to this. They allow a "CookieFilter" which has type
> of URI -> Cookie -> IO Bool. Cookies are only put in the cookie jar if the
> function returns True. There is a default CookieFilter, which behaves as we
> would expect, but the user can override this function. That way, if you
> don't want to support cookies, you can just pass in (\ _ _ -> return False).

Also sounds good.

> If we're already expecting people that want specific functionality to
> re-implement the redirect-following code, this solution might be
> unnecessary. Do you think that such a concept would be beneficial for
> Network.HTTP.Conduit to implement?

Yes, I can imagine that some people would want more fine-grained
control of which cookies are accepted.

> Either way, I'll probably end up making a solution similar to your
> checkRedirect function that will just allow people to take SetCookies out of
> a Response and put Cookies into a Request. I'll probably also provide a
> default function which converts a SetCookie into a cookie by looking up the
> current time, inspecting the Request, etc. This will allow me to not have to
> change the type of Request or Response - the functions I'll be writing can
> deal with the raw Headers that are already in Requests and Responses.
> Modifying 'http' to use these functions will be straightforward.
>
> How does this sound to you?

Sounds like a good plan to me. I'm not entirely certain how you're
planning on implementing the cookie jar itself. In other words, if I
make a request, have a cookie set, and then make another request
later, where will the cookie be stored in the interim, and how will
the second request know to use it?

Michael