<p>Rejecting cookies is not without precedent.</p>
<p>If you must force cookie handling upon us, at least make it possible to selectively reject them.<br></p>
<p>Aristid </p>
<div class="gmail_quote">Am 23.01.2012 08: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">
That&#39;s a violation of the spec. Having a server set a cookie and then<br>
&quot;not really mean it&quot; or something along those lines would be invalid.<br>
And having a server not set a cookie at all means having this feature<br>
would be irrelevant.<br>
<br>
On Mon, Jan 23, 2012 at 9:42 AM, Aristid Breitkreuz<br>
&lt;<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>&gt; wrote:<br>
&gt; Indeed, I disagree on 2. Sometimes there is an API and cookies are just not<br>
&gt; part of it (and redirects are).<br>
&gt;<br>
&gt; Aristid<br>
&gt;<br>
&gt; Am 23.01.2012 08:16 schrieb &quot;Michael Snoyman&quot; &lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;:<br>
&gt;<br>
&gt;&gt; The only times cookies would be used would be:<br>
&gt;&gt;<br>
&gt;&gt; 1. If you explicitly use it.<br>
&gt;&gt; 2. If you have redirects turned on, and a page that redirects you also<br>
&gt;&gt; sets a cookie.<br>
&gt;&gt;<br>
&gt;&gt; I would think that we would want (2) to be on regardless of user<br>
&gt;&gt; setting, do you disagree?<br>
&gt;&gt;<br>
&gt;&gt; Michael<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz<br>
&gt;&gt; &lt;<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Just make sure Cookie handling can be disabled completely.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Aristid<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Am 23.01.2012 07:44 schrieb &quot;Michael Snoyman&quot; &lt;<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>&gt;:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield<br>
&gt;&gt; &gt;&gt; &lt;<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt; 1. Oops - I overlooked the fact that the redirectCount attribute of a<br>
&gt;&gt; &gt;&gt; &gt; Request is exported (it isn&#39;t listed on the documentation probably<br>
&gt;&gt; &gt;&gt; &gt; because<br>
&gt;&gt; &gt;&gt; &gt; the constructor itself isn&#39;t exported. This seems like a flaw in<br>
&gt;&gt; &gt;&gt; &gt; Haddock...). Silly me. No need to export httpRaw.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; 2. I think that stuffing many arguments into the &#39;http&#39; function is<br>
&gt;&gt; &gt;&gt; &gt; ugly.<br>
&gt;&gt; &gt;&gt; &gt; However, I&#39;m not sure that the number of arguments to &#39;http&#39; could<br>
&gt;&gt; &gt;&gt; &gt; ever<br>
&gt;&gt; &gt;&gt; &gt; reach an unreasonably large amount. Perhaps I have bad foresight, but<br>
&gt;&gt; &gt;&gt; &gt; I<br>
&gt;&gt; &gt;&gt; &gt; personally feel that adding cookies to the http request will be the<br>
&gt;&gt; &gt;&gt; &gt; last<br>
&gt;&gt; &gt;&gt; &gt; thing that we will need to add. Putting a bound on this growth of<br>
&gt;&gt; &gt;&gt; &gt; arguments<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I completely disagree here. If we&#39;d followed this approach, rawBody,<br>
&gt;&gt; &gt;&gt; decompress, redirectCount, and checkStatus all would have been<br>
&gt;&gt; &gt;&gt; arguments. There&#39;s a reason we use a settings data type[1] here.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; [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>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt; makes me more willing to think about this option. On the other hand,<br>
&gt;&gt; &gt;&gt; &gt; using a<br>
&gt;&gt; &gt;&gt; &gt; BrowserAction to modify internal state is very elegant. Which<br>
&gt;&gt; &gt;&gt; &gt; approach<br>
&gt;&gt; &gt;&gt; &gt; do<br>
&gt;&gt; &gt;&gt; &gt; you think is best? I think I&#39;m leaning toward the upper-level Browser<br>
&gt;&gt; &gt;&gt; &gt; module<br>
&gt;&gt; &gt;&gt; &gt; idea.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; If there was to be a higher-level HTTP library, I would argue that<br>
&gt;&gt; &gt;&gt; &gt; the<br>
&gt;&gt; &gt;&gt; &gt; redirection code should be moved into it, and the only high-level<br>
&gt;&gt; &gt;&gt; &gt; function<br>
&gt;&gt; &gt;&gt; &gt; that the Network.HTTP.Conduit module would export is &#39;http&#39; (or<br>
&gt;&gt; &gt;&gt; &gt; httpRaw).<br>
&gt;&gt; &gt;&gt; &gt; What do you think about this?<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I actually don&#39;t want to move the redirection code out from where it<br>
&gt;&gt; &gt;&gt; is right now. I think that redirection *is* a basic part of HTTP. I&#39;d<br>
&gt;&gt; &gt;&gt; be more in favor of just bundling cookies in with the current API,<br>
&gt;&gt; &gt;&gt; possibly with the IORef approach I&#39;d mentioned (unless someone wants<br>
&gt;&gt; &gt;&gt; to give a different idea). Having a single API that provides both<br>
&gt;&gt; &gt;&gt; high-level and low-level approaches seems like a win to me.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Michael<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; Haskell-Cafe mailing list<br>
&gt;&gt; &gt;&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;&gt; &gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>