Re: [Haskell-cafe] Contributing to http-conduit

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? 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. 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. 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. Comments? --Myles On Sun, Jan 22, 2012 at 11:16 PM, Michael Snoyman wrote:

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 wrote:

...

Just make sure Cookie handling can be disabled completely.

Aristid

Am 23.01.2012 07:44 schrieb "Michael Snoyman" :

...

On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe