[Haskell-cafe] Contributing to http-conduit

[Myles C. Maxfield]

I was planning on making the caller deal with keeping track of cookies
between requests. My cookie idea only solves the problem of cookies
persisting through a redirect chain - not between subsequent request chains.

Do you think that Network.HTTP.Conduit should have a persistent cookie jar
between caller's requests? I don't really think so.

--Myles

On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <michael at snoyman.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120125/3a4e43cb/attachment.htm>