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&#39;s requests? I don&#39;t really think so.</div><div><br></div><div>--Myles<br><div><br><div class="gmail_quote">On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <span dir="ltr">&lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;</span> wrote:<br>

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