[Haskell-cafe] Contributing to http-conduit

[Myles C. Maxfield]

the fromJust should never fail, beceause of the guard statement:

    | 300 <= code && code < 400 && isJust l'' && isJust l' = Just $ req

Because of the order of the && operators, it will only evaluate fromJust
after it makes sure that the argument isJust. That function in particular
shouldn't throw any exceptions - it should only return Nothing.

Knowing that, I don't quite think I understand what your concern is. Can
you elaborate?

Thanks,
Myles

On Thu, Jan 26, 2012 at 12:59 AM, Michael Snoyman <michael at snoyman.com>wrote:

> 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
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120127/9fe967f5/attachment.htm>