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 <mich...@snoyman.com>wrote: > On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield > <myles.maxfi...@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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe