[Bug 262283] encoding of + in libfetch
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262283] encoding of + in libfetch"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262283] encoding of + in libfetch"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262283] encoding of + in libfetch"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.