Here is a patch regarding getRedirectedRequest. Comments are very welcome.<div><br></div><div>--Myles C. Maxfield<br><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield <span dir="ltr"><<a href="mailto:myles.maxfield@gmail.com" target="_blank">myles.maxfield@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div>
<br>
</div><div>Do you think that Network.HTTP.Conduit should have a persistent cookie jar between caller's requests? I don't really think so.</div><span><font color="#888888"><div><br></div></font></span><div>
<span><font color="#888888">--Myles</font></span><div><div><br><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield<br>
<<a href="mailto:myles.maxfield@gmail.com" target="_blank">myles.maxfield@gmail.com</a>> wrote:<br>
> Alright, that's fine. I just wanted to be explicit about the interface we'd<br>
> be providing. Taking the Request construction code out of 'http' and putting<br>
> it into its own function should be a quick change - I'll have it to you<br>
> soon. One possible wrench - The existing code copies some fields (like the<br>
> proxy) from the original request. In order to keep this functionality, the<br>
> signature would have to be:<br>
><br>
> checkRedirect :: Request m -> Response -> Maybe (Request m)<br>
><br>
> Is that okay with you? I think I'd also like to call the function something<br>
> different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add an<br>
> example to the documentation about how a caller would get the redirection<br>
> chain by re-implementing redirection (by using the example in your previous<br>
> email).<br>
<br>
</div>Sounds great.<br>
<div><br>
> As for cookie handling - I think Network.Browser has a pretty elegant<br>
> solution to this. They allow a "CookieFilter" which has type<br>
> of URI -> Cookie -> IO Bool. Cookies are only put in the cookie jar if the<br>
> function returns True. There is a default CookieFilter, which behaves as we<br>
> would expect, but the user can override this function. That way, if you<br>
> don't want to support cookies, you can just pass in (\ _ _ -> return False).<br>
<br>
</div>Also sounds good.<br>
<div><br>
> If we're already expecting people that want specific functionality to<br>
> re-implement the redirect-following code, this solution might be<br>
> unnecessary. Do you think that such a concept would be beneficial for<br>
> Network.HTTP.Conduit to implement?<br>
<br>
</div>Yes, I can imagine that some people would want more fine-grained<br>
control of which cookies are accepted.<br>
<div><br>
> Either way, I'll probably end up making a solution similar to your<br>
> checkRedirect function that will just allow people to take SetCookies out of<br>
> a Response and put Cookies into a Request. I'll probably also provide a<br>
> default function which converts a SetCookie into a cookie by looking up the<br>
> current time, inspecting the Request, etc. This will allow me to not have to<br>
> change the type of Request or Response - the functions I'll be writing can<br>
> deal with the raw Headers that are already in Requests and Responses.<br>
> Modifying 'http' to use these functions will be straightforward.<br>
><br>
> How does this sound to you?<br>
<br>
</div>Sounds like a good plan to me. I'm not entirely certain how you're<br>
planning on implementing the cookie jar itself. In other words, if I<br>
make a request, have a cookie set, and then make another request<br>
later, where will the cookie be stored in the interim, and how will<br>
the second request know to use it?<br>
<span><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>