Created attachment 232193 [details] git diff in /lib/libfetch against 14-CURRENT Because of this mail thread https://lists.freebsd.org/archives/freebsd-ports/2022-February/001461.html I took a look at fetch. There is also information in the github link in the mails. What I found is that it is pretty easy to encode the + in the path of the URL. Although libfetch is spec compliant with and without this patch. This patch would provide more compatibility with non-spec compliant servers like S3/Cloudflare. My experience as a programmer is that encoding a space as a + is only done when building the query string so if we leave the query string as is we don't change valid URLs. If somebody encodes a space as a + in the host or path of an URI before passing it to libfetch the request will not work with the major (spec compliant) web servers. So I do not see possibilities for regression. So I think encoding the + as %2B in the path is very safe for requests to spec compliant servers and will prevent ambiguous requests to servers who do not follow the specs. An example of the encoding I implemented: fetch -vv "http://example.com/plus+space test?&q=a+b c" scheme: "http" user: "" password: "" host: "example.com" port: "0" document: "/plus%2bspace%20test?&q=a+b%20c" ... So the + and space before the question mark are percent-escaped. In the query string only the space is escaped for a correct http request line.
Can I do something to help this patch getting committed?
(In reply to Ronald Klop from comment #0) Looking back at this issue I see I added a wrong link to the mail thread which triggered me creating this patch. This is the correct one: https://lists.freebsd.org/archives/freebsd-ports/2022-February/001477.html