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" <[email protected]>: > On Wed, Jan 25, 2012 at 9:01 AM, Myles C. Maxfield > <[email protected]> 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 > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
