Re: Bug in url-retrieve-synchronously from url.el on redirect

[Daniele Nicolodi]

On 10-07-2020 14:32, Daniele Nicolodi wrote:
> On 10/07/2020 14:25, Yuri Khan wrote:
>> On Sat, 11 Jul 2020 at 02:43, Daniele Nicolodi <daniele@grinta.net> wrote:
>>
>>> As far as I understand the RFCs (and being wrong before, I may be wrong
>>> again) do not allow for < > quoting either. Why does url-http.el strip
>>> them? Why does it break the URI at the first space if spaces are not
>>> allowed?
>>
>> I cannot answer that, maybe someone who is knowledgeable about
>> uri-http.el chimes in.
>>
>> RFC 7231 allows clients to attempt to DTRT with invalid Location URIs
>> in any way they deem appropriate; you could argue for a different
>> recovery heuristic. Me, I’d rather have things break loudly on each
>> violation, so that it does not go unnoticed for too long. Postel’s
>> Razor is how we got HTML in its current shape.
> 
> I tend to agree with you, but, in this specific case, being compatible
> with other HTTP implementations is a worthwhile goal.
> 
> Unfortunately, re-defining url-http-parse-headers is the only
> work-around I found to make Emacs do the less bad thing when dealing
> with this malformed URIs.

Bill, you seem to be the author of this code, although Stefan is the one
that introduced it to the Emacs accordingly to git blame. Do any of you
know why the redirect Location is handled like that?

I would like to suggest the two attached patches. The first fixes actual
issues I encountered, the second simply adjusts a comment.

Thank you.

Cheers,
Dan

0001-url-http-Fix-handling-of-redirect-locations.patch
Description: Text document

0002-url-http-Do-not-suggest-a-broken-HTTP-server-impleme.patch
Description: Text document