[Haskell-cafe] Contributing to http-conduit

[Myles C. Maxfield]

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 <michael at snoyman.com>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
> <aristidb at googlemail.com> wrote:
> > Just make sure Cookie handling can be disabled completely.
> >
> > Aristid
> >
> > Am 23.01.2012 07:44 schrieb "Michael Snoyman" <michael at snoyman.com>:
> >>
> >> On Mon, Jan 23, 2012 at 8:31 AM, Myles C. Maxfield
> >> <myles.maxfield at gmail.com> 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 at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120122/4143d29c/attachment.htm>