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:<div>
<br></div><div><span style>checkRedirect :: Request m -> Response -> Maybe (Request m)</span></div><div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">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).</font></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">As for cookie handling - I think Network.Browser has a pretty elegant solution to this. They allow a "CookieFilter" which has type of </font><a href="http://hackage.haskell.org/packages/archive/network/2.2.1.7/doc/html/Network-URI.html#t%3AURI" style="color:rgb(171,105,84);font-family:monospace;background-color:rgb(240,240,240);font-size:medium">URI</a><span style="font-family:monospace;background-color:rgb(240,240,240);font-size:medium"> -> </span><a href="http://hackage.haskell.org/packages/archive/HTTP/3001.0.0/doc/html/Network-Browser.html#t%3ACookie" style="color:rgb(171,105,84);text-decoration:none;font-family:monospace;background-color:rgb(240,240,240);font-size:medium">Cookie</a><span style="font-family:monospace;background-color:rgb(240,240,240);font-size:medium"> -> </span><a href="http://hackage.haskell.org/packages/archive/base/4.2.0.0/doc/html/System-IO.html#t%3AIO" style="color:rgb(171,105,84);text-decoration:none;font-family:monospace;background-color:rgb(240,240,240);font-size:medium">IO</a><span style="font-family:monospace;background-color:rgb(240,240,240);font-size:medium"> </span><a href="http://hackage.haskell.org/packages/archive/base/4.2.0.0/doc/html/Data-Bool.html#t%3ABool" style="color:rgb(171,105,84);text-decoration:none;font-family:monospace;background-color:rgb(240,240,240);font-size:medium">Bool</a>. 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).</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>How does this sound to you?</div><div><br></div><div>Thanks,</div><div>Myles C. Maxfield<br><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 5:10 AM, Aristid Breitkreuz <span dir="ltr"><<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>The nice thing is that this way, nobody can force me to handle cookies. ;-)</p>
<p>Might be that usage patterns emerge, which we can then codify into functions later. </p>
<div class="gmail_quote">Am 25.01.2012 08:09 schrieb "Michael Snoyman" <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield<br>
<<a href="mailto:myles.maxfield@gmail.com" target="_blank">myles.maxfield@gmail.com</a>> wrote:<br>
> Sorry, I think I'm still a little confused about this.<br>
><br>
> From the point of view of a library user, if I use the 'http' function, but<br>
> want to know what final URL I ended up at, I would have to set redirects to<br>
> 0, call http, call checkRedirect, and recurse until checkRedirect returns<br>
> Nothing (or a count runs out). I would be handling the recursion of<br>
> redirects myself.<br>
><br>
> On one hand, this solution is lightweight and easy to implement in the<br>
> library. On the other hand, the caller has to run each individual request<br>
> themselves, keeping track of the number of requests (so there isn't an<br>
> infinite loop). The loop is already implemented in the http function - I<br>
> think it's reasonable to modify the existing loop rather than expect the<br>
> caller to re-implement that logic.<br>
><br>
> However, it's probably just as reasonable to say "if you want to know what<br>
> URL you end up at, you have to re-implement your own redirection-following<br>
> logic."<br>
><br>
> I do agree, however, that including an (possibly long, though explicitly<br>
> bounded) [Ascii] along with every request is arbitrary, and probably not the<br>
> best solution. Can you think of a solution which allows the caller to know<br>
> the url chain (or possibly just the last URL - that's the important one)<br>
> without having to re-implement the redirection-following logic themselves?<br>
><br>
> It sounds like if you had to choose, you would rather force a caller to<br>
> re-implement redirection-following rather than include a URL chain in every<br>
> Response. Is this correct?<br>
<br>
That's correct. I think knowing the final URL is a fairly arbitrary<br>
requirement, in the same boat as wanting redirect handling without<br>
supporting cookies. These to me fall well within the 20%: most people<br>
won't need them, so the API should not be optimized for them.<br>
<br>
There's also the fact that [Ascii] isn't nearly enough information to<br>
properly follow the chain. Next someone's going to want to know if a<br>
request was GET or POST, or whether it was a permanent or temporary<br>
redirect, or the exact text of the location header, or a million other<br>
things involved. If someone wants this stuff, they should reimplement<br>
the redirect logic.<br>
<br>
But I don't really see this as being such a burden. If we had the<br>
checkRedirect function, it would look something like:<br>
<br>
myHttp req = do<br>
let req' = req { redirectCount = 0 }<br>
res <- http req'<br>
case checkRedirect res of<br>
Just req2 -> myHttp req2<br>
Nothing -> return res<br>
<br>
I don't think that's a terrible burden.<br>
<br>
Michael<br>
<br></div></div><div class="im">
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></blockquote></div>
</blockquote></div><br></div>