[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniele Nicolodi
Subject: Bug in url-retrieve-synchronously from url.el on redirect
Date: Fri, 10 Jul 2020 12:18:05 -0600
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


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

If I understand the code correctly, the redirect response in interpreted
in url-http-parse-headers where the header is explicitly truncated:

         (when redirect-uri
           ;; Clean off any whitespace and/or <...> cruft.
           (if (string-match "\\([^ \t]+\\)[ \t]" redirect-uri)
               (setq redirect-uri (match-string 1 redirect-uri)))
           (if (string-match "^<\\(.*\\)>$" redirect-uri)
               (setq redirect-uri (match-string 1 redirect-uri)))

I think the first regular expression is wrong. I believe that its intent
is to remove leading and trailing white space, but it actually truncates
the value to the first white space character. Also, redirect-uri is
obtained with

       (let ((redirect-uri (or (mail-fetch-field "Location")
                               (mail-fetch-field "URI"))))

and mail-fetch-field already removes leading and trailing whitespace.

I think the attached patch should fix the problem.

Finally, the removal of the < > delimiters seems unnecessary too as they
are not allowed delimiters in HTTP headers (in my reading of
https://tools.ietf.org/html/rfc7230) however there are no adverse
consequences in leaving it there.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]