Date: Tue, 01 Mar 2022 20:13:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262283] encoding of + in libfetch Message-ID: <bug-262283-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262283 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: ronald-lists@klop.ws Created attachment 232193 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D232193&action= =3Dedit 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 U= RL. 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 s= pec 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=3Da+b c" scheme: "http" user: "" password: "" host: "example.com" port: "0" document: "/plus%2bspace%20test?&q=3Da+b%20c" ... So the + and space before the question mark are percent-escaped. In the que= ry string only the space is escaped for a correct http request line. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262283-227>