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

[chad]

Very likely the </> stripping code dates from a time period when code would recognize strings inside angle-brackets as potential URLs/URIs, and passed the entire string to the url library out of simplicity. If memory serves, Bill Perry's original url code dates from the wild and wooly early days of loose url encoding. I would expect that it can be changed safely.

Hope that helps,

~Chad

On Fri, Jul 10, 2020 at 5:55 PM Daniele Nicolodi <daniele@grinta.net> wrote:

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