Here is a patch regarding getRedirectedRequest. Comments are very welcome. --Myles C. Maxfield
On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield < [email protected]> wrote: > 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 <[email protected]>wrote: > >> On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield >> <[email protected]> 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 >> > >
getRedirectedRequest.patch
Description: Binary data
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
