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

[Daniele Nicolodi <daniele@grinta.net>]

On 13/07/2020 12:15, chad wrote:
> 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

Thanks Chad. This does not quite explain the presence of the </>
stripping in handling HTTP protocol headers. But it may be that with
subsequent refactoring, this coded ended where it is now.

It would be nice if someone with commit rights could find a couple of
spare cycles to comment on these patches and hopefully apply them.

PS: Emails to Bill Perry address are bouncing for me.

Cheers,
Dan


> 
> On Fri, Jul 10, 2020 at 5:55 PM Daniele Nicolodi <daniele@grinta.net
> <mailto: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 <mailto: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
>