[Haskell-cafe] Contributing to http-conduit

[Michael Snoyman]

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