Re: HTTP redirects make url-retrieve-synchronously asynchronous

[Stefan Monnier]

>>> It might not be elegant but the attached patch works for me.  If
>>> url-retrieve sees :redirect in cbargs, it calls url-retrieve-synchronously
>>> and then calls the callback with cbargs.
>> 
>> That wasn't what the attached patch did, but in any case that'd be
>> a workaround, not a fix.

> The more I think about it the more my patch seems like an OK fix instead of
> a workaround.  What makes it a workaround to you?

There's still some fundamental problems with the code: url-retrieve returns
a buffer which is expected to be the buffer into which the result will be
put (and where ther callback will be executed), but after a redirect, the
data is actually put into yet another buffer.  I suspect a good fix will
require some change to the "API" (BTW other fixes to the API may be needed to
really fix the problem related to callbacks that don't get called, as
mentioned in comments in url-retrieve-synchronously).

> My fix is short and simple and preserves the synchronicity of the original
> call.  That is, if url-retrieve encountered the redirect, it will remain
> asynchronous; if url-retrieve-synchronously encountered the redirect it
> remains synchronous.

Hmmm it seemed to me that your patch causes a redirect in url-retrieve to
make the end of the operation synchronous rather than asynchronous.
I'll have to take another look.

> Also, it seems like RMS (who added :redirect) might have been thinking that
> url-retrieve should do something special with redirects.  Here's the
> ChangeLog entry corresponding to RMS' change:

IIRC the need for it had to do with how you interpret relative URL in
responses (should be relative to the target of the redirect rather than to
the original URL).


        Stefan