Date: Tue, 01 Mar 2022 20:13:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262283 Bug ID: 262283 Summary: encoding of + in libfetch Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: email@example.com Created attachment 232193 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232193&action=edit 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. -- You are receiving this mail because: You are the assignee for the bug.