<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 "Michael Snoyman" <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's a violation of the spec. Having a server set a cookie and then<br>
"not really mean it" 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>
<<a href="mailto:aristidb@googlemail.com">aristidb@googlemail.com</a>> wrote:<br>
> Indeed, I disagree on 2. Sometimes there is an API and cookies are just not<br>
> part of it (and redirects are).<br>
><br>
> Aristid<br>
><br>
> Am 23.01.2012 08:16 schrieb "Michael Snoyman" <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>>:<br>
><br>
>> 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>
>><br>
>> Michael<br>
>><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<br>
>> >> > ever<br>
>> >> > reach an unreasonably large amount. Perhaps I have bad foresight, but<br>
>> >> > I<br>
>> >> > personally feel that adding cookies to the http request will be the<br>
>> >> > 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<br>
>> >> > 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<br>
>> >> > 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>
</blockquote></div>