[Haskell-cafe] Contributing to http-conduit
michael at snoyman.com
Thu Jan 26 06:28:30 CET 2012
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
> 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?
More information about the Haskell-Cafe