[Haskell-cafe] Contributing to http-conduit

[Aristid Breitkreuz]

Rejecting cookies is not without precedent.

If you must force cookie handling upon us, at least make it possible to
selectively reject them.

Aristid
Am 23.01.2012 08:44 schrieb "Michael Snoyman" <michael at snoyman.com>:

> That's a violation of the spec. Having a server set a cookie and then
> "not really mean it" or something along those lines would be invalid.
> And having a server not set a cookie at all means having this feature
> would be irrelevant.
>
> On Mon, Jan 23, 2012 at 9:42 AM, Aristid Breitkreuz
> <aristidb at googlemail.com> wrote:
> > 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" <michael at snoyman.com>:
> >
> >> 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/20120123/01b5f865/attachment.htm>