[Haskell-cafe] Contributing to http-conduit

[Aristid Breitkreuz]

The nice thing is that this way, nobody can force me to handle cookies.  ;-)

Might be that usage patterns emerge, which we can then codify into
functions later.
Am 25.01.2012 08:09 schrieb "Michael Snoyman" <michael at snoyman.com>:

> On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield
> <myles.maxfield at gmail.com> wrote:
> > Sorry, I think I'm still a little confused about this.
> >
> > From the point of view of a library user, if I use the 'http' function,
> but
> > want to know what final URL I ended up at, I would have to set redirects
> to
> > 0, call http, call checkRedirect, and recurse until checkRedirect returns
> > Nothing (or a count runs out). I would be handling the recursion of
> > redirects myself.
> >
> > On one hand, this solution is lightweight and easy to implement in the
> > library. On the other hand, the caller has to run each individual request
> > themselves, keeping track of the number of requests (so there isn't an
> > infinite loop). The loop is already implemented in the http function - I
> > think it's reasonable to modify the existing loop rather than expect the
> > caller to re-implement that logic.
> >
> > However, it's probably just as reasonable to say "if you want to know
> what
> > URL you end up at, you have to re-implement your own
> redirection-following
> > logic."
> >
> > I do agree, however, that including an (possibly long, though explicitly
> > bounded) [Ascii] along with every request is arbitrary, and probably not
> the
> > best solution. Can you think of a solution which allows the caller to
> know
> > the url chain (or possibly just the last URL - that's the important one)
> > without having to re-implement the redirection-following logic
> themselves?
> >
> > It sounds like if you had to choose, you would rather force a caller to
> > re-implement redirection-following rather than include a URL chain in
> every
> > Response. Is this correct?
>
> That's correct. I think knowing the final URL is a fairly arbitrary
> requirement, in the same boat as wanting redirect handling without
> supporting cookies. These to me fall well within the 20%: most people
> won't need them, so the API should not be optimized for them.
>
> There's also the fact that [Ascii] isn't nearly enough information to
> properly follow the chain. Next someone's going to want to know if a
> request was GET or POST, or whether it was a permanent or temporary
> redirect, or the exact text of the location header, or a million other
> things involved. If someone wants this stuff, they should reimplement
> the redirect logic.
>
> But I don't really see this as being such a burden. If we had the
> checkRedirect function, it would look something like:
>
> myHttp req = do
>    let req' = req { redirectCount = 0 }
>    res <- http req'
>    case checkRedirect res of
>        Just req2 -> myHttp req2
>        Nothing -> return res
>
> I don't think that's a terrible burden.
>
> 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/20120125/63f2502c/attachment.htm>