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 <michael@snoyman.com> wrote:
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
<myles.maxfield@gmail.com> 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 <michael@snoyman.com>
> wrote:
>>
>> On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
>> <myles.maxfield@gmail.com> 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
>> >> <myles.maxfield@gmail.com> 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
>
>