<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">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">
On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield<br>
<<a href="mailto:myles.maxfield@gmail.com">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>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">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>
</blockquote></div>