[Haskell-cafe] Contributing to http-conduit

[Michael Snoyman]

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