[Haskell-cafe] Contributing to http-conduit

[Michael Snoyman]

I'm a little worried about the use of `fromJust`, it will give users a
very confusing error message, and the error might be trigged at the
wrong point in the computation. I'd feel better if checkRedirect lived
in either some Failure, an Either, or maybe even in IO itself. IO
might make sense if we want to implement some cookie jar functionality
in the future via mutable references.

Michael

On Thu, Jan 26, 2012 at 10:29 AM, Myles C. Maxfield
<myles.maxfield at gmail.com> wrote:
> Here is a patch regarding getRedirectedRequest. Comments are very welcome.
>
> --Myles C. Maxfield
>
>
> On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield
> <myles.maxfield at gmail.com> wrote:
>>
>> I was planning on making the caller deal with keeping track of cookies
>> between requests. My cookie idea only solves the problem of cookies
>> persisting through a redirect chain - not between subsequent request chains.
>>
>> Do you think that Network.HTTP.Conduit should have a persistent cookie jar
>> between caller's requests? I don't really think so.
>>
>> --Myles
>>
>>
>> On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>>>
>>> On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield
>>> <myles.maxfield at gmail.com> wrote:
>>> > Alright, that's fine. I just wanted to be explicit about the interface
>>> > we'd
>>> > be providing. Taking the Request construction code out of 'http' and
>>> > putting
>>> > it into its own function should be a quick change - I'll have it to you
>>> > soon. One possible wrench - The existing code copies some fields (like
>>> > the
>>> > proxy) from the original request. In order to keep this functionality,
>>> > the
>>> > signature would have to be:
>>> >
>>> > checkRedirect :: Request m -> Response -> Maybe (Request m)
>>> >
>>> > Is that okay with you? I think I'd also like to call the function
>>> > something
>>> > different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add
>>> > an
>>> > example to the documentation about how a caller would get the
>>> > redirection
>>> > chain by re-implementing redirection (by using the example in your
>>> > previous
>>> > email).
>>>
>>> Sounds great.
>>>
>>> > As for cookie handling - I think Network.Browser has a pretty elegant
>>> > solution to this. They allow a "CookieFilter" which has type
>>> > of URI -> Cookie -> IO Bool. Cookies are only put in the cookie jar if
>>> > the
>>> > function returns True. There is a default CookieFilter, which behaves
>>> > as we
>>> > would expect, but the user can override this function. That way, if you
>>> > don't want to support cookies, you can just pass in (\ _ _ -> return
>>> > False).
>>>
>>> Also sounds good.
>>>
>>> > If we're already expecting people that want specific functionality to
>>> > re-implement the redirect-following code, this solution might be
>>> > unnecessary. Do you think that such a concept would be beneficial for
>>> > Network.HTTP.Conduit to implement?
>>>
>>> Yes, I can imagine that some people would want more fine-grained
>>> control of which cookies are accepted.
>>>
>>> > Either way, I'll probably end up making a solution similar to your
>>> > checkRedirect function that will just allow people to take SetCookies
>>> > out of
>>> > a Response and put Cookies into a Request. I'll probably also provide a
>>> > default function which converts a SetCookie into a cookie by looking up
>>> > the
>>> > current time, inspecting the Request, etc. This will allow me to not
>>> > have to
>>> > change the type of Request or Response - the functions I'll be writing
>>> > can
>>> > deal with the raw Headers that are already in Requests and Responses.
>>> > Modifying 'http' to use these functions will be straightforward.
>>> >
>>> > How does this sound to you?
>>>
>>> Sounds like a good plan to me. I'm not entirely certain how you're
>>> planning on implementing the cookie jar itself. In other words, if I
>>> make a request, have a cookie set, and then make another request
>>> later, where will the cookie be stored in the interim, and how will
>>> the second request know to use it?
>>>
>>> Michael
>>
>>
>