<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 &quot;Michael Snoyman&quot; &lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;:<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>
&lt;<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>&gt; wrote:<br>
&gt; Sorry, I think I&#39;m still a little confused about this.<br>
&gt;<br>
&gt; From the point of view of a library user, if I use the &#39;http&#39; function, but<br>
&gt; want to know what final URL I ended up at, I would have to set redirects to<br>
&gt; 0, call http, call checkRedirect, and recurse until checkRedirect returns<br>
&gt; Nothing (or a count runs out). I would be handling the recursion of<br>
&gt; redirects myself.<br>
&gt;<br>
&gt; On one hand, this solution is lightweight and easy to implement in the<br>
&gt; library. On the other hand, the caller has to run each individual request<br>
&gt; themselves, keeping track of the number of requests (so there isn&#39;t an<br>
&gt; infinite loop). The loop is already implemented in the http function - I<br>
&gt; think it&#39;s reasonable to modify the existing loop rather than expect the<br>
&gt; caller to re-implement that logic.<br>
&gt;<br>
&gt; However, it&#39;s probably just as reasonable to say &quot;if you want to know what<br>
&gt; URL you end up at, you have to re-implement your own redirection-following<br>
&gt; logic.&quot;<br>
&gt;<br>
&gt; I do agree, however, that including an (possibly long, though explicitly<br>
&gt; bounded) [Ascii] along with every request is arbitrary, and probably not the<br>
&gt; best solution. Can you think of a solution which allows the caller to know<br>
&gt; the url chain (or possibly just the last URL - that&#39;s the important one)<br>
&gt; without having to re-implement the redirection-following logic themselves?<br>
&gt;<br>
&gt; It sounds like if you had to choose, you would rather force a caller to<br>
&gt; re-implement redirection-following rather than include a URL chain in every<br>
&gt; Response. Is this correct?<br>
<br>
That&#39;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&#39;t need them, so the API should not be optimized for them.<br>
<br>
There&#39;s also the fact that [Ascii] isn&#39;t nearly enough information to<br>
properly follow the chain. Next someone&#39;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&#39;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&#39; = req { redirectCount = 0 }<br>
    res &lt;- http req&#39;<br>
    case checkRedirect res of<br>
        Just req2 -&gt; myHttp req2<br>
        Nothing -&gt; return res<br>
<br>
I don&#39;t think that&#39;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>