Indeed, I disagree on 2. Sometimes there is an API and cookies are just not part of it (and redirects are).
Aristid Am 23.01.2012 08:16 schrieb "Michael Snoyman" <[email protected]>: > The only times cookies would be used would be: > > 1. If you explicitly use it. > 2. If you have redirects turned on, and a page that redirects you also > sets a cookie. > > I would think that we would want (2) to be on regardless of user > setting, do you disagree? > > Michael > > On Mon, Jan 23, 2012 at 8:46 AM, Aristid Breitkreuz > <[email protected]> wrote: > > Just make sure Cookie handling can be disabled completely. > > > > Aristid > > > > Am 23.01.2012 07:44 schrieb "Michael Snoyman" <[email protected]>: > >> > >> On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield > >> <[email protected]> wrote: > >> > 1. Oops - I overlooked the fact that the redirectCount attribute of a > >> > Request is exported (it isn't listed on the documentation probably > >> > because > >> > the constructor itself isn't exported. This seems like a flaw in > >> > Haddock...). Silly me. No need to export httpRaw. > >> > > >> > 2. I think that stuffing many arguments into the 'http' function is > >> > ugly. > >> > However, I'm not sure that the number of arguments to 'http' could > ever > >> > reach an unreasonably large amount. Perhaps I have bad foresight, but > I > >> > personally feel that adding cookies to the http request will be the > last > >> > thing that we will need to add. Putting a bound on this growth of > >> > arguments > >> > >> I completely disagree here. If we'd followed this approach, rawBody, > >> decompress, redirectCount, and checkStatus all would have been > >> arguments. There's a reason we use a settings data type[1] here. > >> > >> [1] http://www.yesodweb.com/blog/2011/10/settings-types > >> > >> > makes me more willing to think about this option. On the other hand, > >> > using a > >> > BrowserAction to modify internal state is very elegant. Which approach > >> > do > >> > you think is best? I think I'm leaning toward the upper-level Browser > >> > module > >> > idea. > >> > > >> > If there was to be a higher-level HTTP library, I would argue that the > >> > redirection code should be moved into it, and the only high-level > >> > function > >> > that the Network.HTTP.Conduit module would export is 'http' (or > >> > httpRaw). > >> > What do you think about this? > >> > >> I actually don't want to move the redirection code out from where it > >> is right now. I think that redirection *is* a basic part of HTTP. I'd > >> be more in favor of just bundling cookies in with the current API, > >> possibly with the IORef approach I'd mentioned (unless someone wants > >> to give a different idea). Having a single API that provides both > >> high-level and low-level approaches seems like a win to me. > >> > >> Michael > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> [email protected] > >> http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
