<p>Just make sure Cookie handling can be disabled completely.<br></p>
<p>Aristid </p>
<div class="gmail_quote">Am 23.01.2012 07:44 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 Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield<br>
&lt;<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>&gt; wrote:<br>
&gt; 1. Oops - I overlooked the fact that the redirectCount attribute of a<br>
&gt; Request is exported (it isn&#39;t listed on the documentation probably because<br>
&gt; the constructor itself isn&#39;t exported. This seems like a flaw in<br>
&gt; Haddock...). Silly me. No need to export httpRaw.<br>
&gt;<br>
&gt; 2. I think that stuffing many arguments into the &#39;http&#39; function is ugly.<br>
&gt; However, I&#39;m not sure that the number of arguments to &#39;http&#39; could ever<br>
&gt; reach an unreasonably large amount. Perhaps I have bad foresight, but I<br>
&gt; personally feel that adding cookies to the http request will be the last<br>
&gt; thing that we will need to add. Putting a bound on this growth of arguments<br>
<br>
I completely disagree here. If we&#39;d followed this approach, rawBody,<br>
decompress, redirectCount, and checkStatus all would have been<br>
arguments. There&#39;s a reason we use a settings data type[1] here.<br>
<br>
[1] <a href="http://www.yesodweb.com/blog/2011/10/settings-types" target="_blank">http://www.yesodweb.com/blog/2011/10/settings-types</a><br>
<br>
&gt; makes me more willing to think about this option. On the other hand, using a<br>
&gt; BrowserAction to modify internal state is very elegant. Which approach do<br>
&gt; you think is best? I think I&#39;m leaning toward the upper-level Browser module<br>
&gt; idea.<br>
&gt;<br>
&gt; If there was to be a higher-level HTTP library, I would argue that the<br>
&gt; redirection code should be moved into it, and the only high-level function<br>
&gt; that the Network.HTTP.Conduit module would export is &#39;http&#39; (or httpRaw).<br>
&gt; What do you think about this?<br>
<br>
I actually don&#39;t want to move the redirection code out from where it<br>
is right now. I think that redirection *is* a basic part of HTTP. I&#39;d<br>
be more in favor of just bundling cookies in with the current API,<br>
possibly with the IORef approach I&#39;d mentioned (unless someone wants<br>
to give a different idea). Having a single API that provides both<br>
high-level and low-level approaches seems like a win to me.<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>