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
