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

[Daniele Nicolodi]

On 10/07/2020 12:49, Yuri Khan wrote:
> On Sat, 11 Jul 2020 at 01:18, Daniele Nicolodi <daniele@grinta.net> wrote:
> 
>> url-retrieve-synchronously fails to obey redirect responses if the
>> returned "Location" header contains spaces: it redirects to the URL
>> truncated to the first space. It seems that spaces in the Location
>> header value are allowed (at least ngnix produces headers like that).
> 
> They are not, and you should report it as a bug against nginx. It
> should be percent-encoding the space. It should also be
> percent-encoding any non-ASCII characters.
> 
> The Location header is defined in RFC 7231, section 7.1.2, with a
> value of URI-reference as defined in RFC 3986. The complete BNF
> grammar is listed in Appendix A, and none of the productions there
> contain the raw space character, nor raw non-ASCII characters.

Thanks for the explanation.

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 would apply the old "be liberal in what you accent and strict in what
you emit" wisdom here. Indeed, all the HTTP implementations I tested,
except Emacs, interpret the Location header with spaces as most likely
intended.

Cheers,
Dan