
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?
Thanks for helping me out with this,
Myles C. Maxfield
On Tue, Jan 24, 2012 at 8:05 PM, Michael Snoyman
It would be the new request indicated by the server response, if the server gave a redirect response.
On Tue, Jan 24, 2012 at 9:05 PM, Myles C. Maxfield
wrote: Sorry, I don't think I'm following. What would the meaning of the value returned from checkRedirect be?
--Myles
On Tue, Jan 24, 2012 at 10:47 AM, Michael Snoyman
wrote: On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
wrote: On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman <
michael@snoyman.com>
wrote:
On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield
wrote: I have attached a patch to add a redirect chain to the Response datatype. Comments on this patch are very welcome.
I thought that this isn't necessary since a client wanting to track all the redirects could just handle them manually by setting the redirect count to 0.
It seems like a lot of work to re-implement the redirection-following code, just to know which URL the bytes are coming from. I feel that adding this field makes the library easier to use, but it's your call.
If that's the concern, I'd much rather just expose a function to help with dealing with redirects, rather than sticking a rather arbitrary [Ascii] in everyone's Response. I think a function along the lines of:
checkRedirect :: Response -> Maybe Request
would fit the bill, and could be extracted from the current `http` function.
Michael