No subject
Sun Oct 23 10:51:38 CEST 2011
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 at 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 at 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 at snoyman.com>
> > wrote:
> >>
> >> On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield
> >> <myles.maxfield at gmail.com> wrote:
> >> >
> >> > On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman <
> michael at snoyman.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield
> >> >> <myles.maxfield at 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
> >
> >
>
--f46d043c7f0c039a7a04b754d7b4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sorry, I think I'm still a little confused about this.<div><br></div><d=
iv>From the point of view of a library user, if I use the 'http' fu=
nction, 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 checkRedir=
ect returns Nothing (or a count runs out). I would be handling the recursio=
n of redirects myself.</div>
<div><br></div><div>On one hand, this solution is lightweight and easy to i=
mplement in the library. On the other hand, the caller has to run each indi=
vidual request themselves, keeping track of the number of requests (so ther=
e 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 t=
han expect the caller to re-implement that logic.</div>
<div><br></div><div>However, it's probably just as reasonable to say &q=
uot;if you want to know what URL you end up at, you have to re-implement yo=
ur own redirection-following logic."</div><div><br></div><div>I do agr=
ee, however, that including an (possibly long, though explicitly bounded) [=
Ascii] along with every request is arbitrary, and probably not the best sol=
ution. 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) withou=
t having to re-implement the redirection-following logic themselves?</div>
<div><br></div><div>It sounds like if you had to choose, you would rather f=
orce a caller to re-implement redirection-following rather than include a U=
RL chain in every Response. Is this correct?</div><div><br></div><div>
Thanks for helping me out with this,</div>
<div>Myles C. Maxfield</div><div><br><div class=3D"gmail_quote">On Tue, Jan=
24, 2012 at 8:05 PM, Michael Snoyman <span dir=3D"ltr"><<a href=3D"mail=
to:michael at snoyman.com" target=3D"_blank">michael at snoyman.com</a>></span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It would be the new request indicated by the=
server response, if the<br>
server gave a redirect response.<br>
<br>
On Tue, Jan 24, 2012 at 9:05 PM, Myles C. Maxfield<br>
<div><div><<a href=3D"mailto:myles.maxfield at gmail.com" target=3D"_blank"=
>myles.maxfield at gmail.com</a>> wrote:<br>
> Sorry, I don't think I'm following. What would the meaning of =
the value<br>
> returned from checkRedirect be?<br>
><br>
> --Myles<br>
><br>
><br>
> On Tue, Jan 24, 2012 at 10:47 AM, Michael Snoyman <<a href=3D"mailt=
o:michael at snoyman.com" target=3D"_blank">michael at snoyman.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Jan 24, 2012 at 6:57 PM, Myles C. Maxfield<br>
>> <<a href=3D"mailto:myles.maxfield at gmail.com" target=3D"_blank">=
myles.maxfield at gmail.com</a>> wrote:<br>
>> ><br>
>> > On Mon, Jan 23, 2012 at 10:43 PM, Michael Snoyman <<a href=
=3D"mailto:michael at snoyman.com" target=3D"_blank">michael at snoyman.com</a>&g=
t;<br>
>> > wrote:<br>
>> >><br>
>> >> On Tue, Jan 24, 2012 at 8:37 AM, Myles C. Maxfield<br>
>> >> <<a href=3D"mailto:myles.maxfield at gmail.com" target=3D=
"_blank">myles.maxfield at gmail.com</a>> wrote:<br>
>> >> > I have attached a patch to add a redirect chain to t=
he Response<br>
>> >> > datatype.<br>
>> >> > Comments on this patch are very welcome.<br>
>> >><br>
>> >> I thought that this isn't necessary since a client wa=
nting to track<br>
>> >> all the redirects could just handle them manually by sett=
ing the<br>
>> >> redirect count to 0.<br>
>> ><br>
>> > It seems like a lot of work to re-implement the redirection-f=
ollowing<br>
>> > code,<br>
>> > just to know which URL the bytes are coming from. =A0I feel t=
hat adding<br>
>> > this<br>
>> > field makes the library easier to use, but it's your call=
.<br>
>><br>
>> If that's the concern, I'd much rather just expose a funct=
ion to help<br>
>> with dealing with redirects, rather than sticking a rather arbitra=
ry<br>
>> [Ascii] in everyone's Response. I think a function along the l=
ines of:<br>
>><br>
>> checkRedirect :: Response -> Maybe Request<br>
>><br>
>> would fit the bill, and could be extracted from the current `http`=
<br>
>> function.<br>
>><br>
>> Michael<br>
><br>
><br>
</div></div></blockquote></div><br>
</div>
--f46d043c7f0c039a7a04b754d7b4--
More information about the Haskell-Cafe
mailing list