[Bug 262283] encoding of + in libfetch

From: <bugzilla-noreply_at_freebsd.org>
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: ronald-lists@klop.ws

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.