Re: HTTP redirects make url-retrieve-synchronously asynchronous

[Mark Plaksin]

Stefan Monnier <address@hidden> writes:

>> 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).

Gotcha.  This level of analysis of the URL library is beyond me (for now
anyhow :)

>> 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.

Maybe I wasn't clear enough.  The redirect is always handled synchronously
but that doesn't change the synchronicity of the original url-retrieve*
call.  If you call url-retrieve and there's a redirect, the original
url-retrieve call will remain asynchronous.  If you call
url-retrieve-synchronously and there's a redirect, the original call will
remain synchronous.