Re: PATCH: Add uri percent-encoding for binary data

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Anders Åstrand <anders@449.se>, pgsql-hackers@postgresql.org
Date: 2020-03-19T07:55:30Z
Lists: pgsql-hackers
> On 4 Mar 2020, at 12:25, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
>> On 20 Feb 2020, at 23:27, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> 
>> On 2019-Oct-07, Anders Åstrand wrote:
>> 
>>> Attached is a patch for adding uri as an encoding option for
>>> encode/decode. It uses what's called "percent-encoding" in rfc3986
>>> (https://tools.ietf.org/html/rfc3986#section-2.1).
>> 
>> Thanks.  Seems useful.  I made a few cosmetic tweaks and it looks almost
>> ready to me;
> 
> I agree that uri decoding/encoding would be useful, but I'm not convinced that
> this patch does the functionality justice enough to be useful.  What is the
> usecase we envision to solve when not taking scheme into consideration?
> 
> Reserved characters have different meaning based on context and scheme, and
> should not be encoded when used as a delimiter.  This does make the patch a lot
> more complicated, but if we provide a uri encoding which percent-encode the
> delimiters in https:// I would expect that to be reported to pgsql-bugs@
> repeatedly.  Adding URIs with userinfo makes it even more problematic, as
> encoding the @ delimiter will break it.
> 
> Further, RFC6874 specifies that ipv6 URIs with zone identifiers are written as:
> IPv6address "%25" ZoneID.  With this patch it would be encoded %2525 ZoneID
> which is incorrect.
> 
> That being said, if we do look at the scheme then we'll need to decide which
> URI standard we want to stick to as RFC3986 and WHATWG URL-spec aren't
> compatible.
> 
> Perhaps not calling it 'uri' and instead renaming it to 'percent-encoding' can
> make it clearer, while sticking to the proposed feature?

With no response for 2 weeks during the commitfest, I propose to move this to
the next CF to allow time for discussions.

cheers ./daniel