<div>I'm a little confused as to what you mean by 'cookie handling'. Do you mean cookies being set inside redirects for future requests inside the same redirect chain, or users being able to supply cookies to the first HTTP request and pull them out of the last HTTP response?</div>
<div><br></div><div>Clearly, making the original request specify 0 cookies is (will be) trivial. It is up to the caller to determine if he/she wants to pull cookies out of the last server response.</div><div><br></div><div>
As for cookies getting set inside a redirect chain - I believe that the Internet is 'broken' without this. I believe a client which does not set cookies inside a redirect chain is a misbehaving client.</div><div>
<br>
</div><div>Are you suggesting that we have a 'do not obey cookies inside a redirection chain, instead always blindly send this arbitrary (possibly empty) set of cookies' setting? That's fine with me, but we should at least but a big disclaimer around that option saying that its use leads to technically misbehaving client behavior.</div>
<div><br></div><div>Comments?</div><div><br></div><div>--Myles<br><br><div class="gmail_quote">On Sun, Jan 22, 2012 at 11:16 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The only times cookies would be used would be:<br>
<br>
1. If you explicitly use it.<br>
2. If you have redirects turned on, and a page that redirects you also<br>
sets a cookie.<br>
<br>
I would think that we would want (2) to be on regardless of user<br>
setting, do you disagree?<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz<br>
<<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>> wrote:<br>
> Just make sure Cookie handling can be disabled completely.<br>
><br>
> Aristid<br>
><br>
> Am 23.01.2012 07:44 schrieb "Michael Snoyman" <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>>:<br>
>><br>
>> On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield<br>
>> <<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>> wrote:<br>
>> > 1. Oops - I overlooked the fact that the redirectCount attribute of a<br>
>> > Request is exported (it isn't listed on the documentation probably<br>
>> > because<br>
>> > the constructor itself isn't exported. This seems like a flaw in<br>
>> > Haddock...). Silly me. No need to export httpRaw.<br>
>> ><br>
>> > 2. I think that stuffing many arguments into the 'http' function is<br>
>> > ugly.<br>
>> > However, I'm not sure that the number of arguments to 'http' could ever<br>
>> > reach an unreasonably large amount. Perhaps I have bad foresight, but I<br>
>> > personally feel that adding cookies to the http request will be the last<br>
>> > thing that we will need to add. Putting a bound on this growth of<br>
>> > arguments<br>
>><br>
>> I completely disagree here. If we'd followed this approach, rawBody,<br>
>> decompress, redirectCount, and checkStatus all would have been<br>
>> arguments. There'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>
>> > makes me more willing to think about this option. On the other hand,<br>
>> > using a<br>
>> > BrowserAction to modify internal state is very elegant. Which approach<br>
>> > do<br>
>> > you think is best? I think I'm leaning toward the upper-level Browser<br>
>> > module<br>
>> > idea.<br>
>> ><br>
>> > If there was to be a higher-level HTTP library, I would argue that the<br>
>> > redirection code should be moved into it, and the only high-level<br>
>> > function<br>
>> > that the Network.HTTP.Conduit module would export is 'http' (or<br>
>> > httpRaw).<br>
>> > What do you think about this?<br>
>><br>
>> I actually don'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'd<br>
>> be more in favor of just bundling cookies in with the current API,<br>
>> possibly with the IORef approach I'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>
</div></div></blockquote></div><br></div>