Yeah, this needs more research IMO. One things I am sure of is that a global setting is a no-go for me as it is bound to cause problems in larger apps that may want conflicting values.
Gary On Wed, Apr 16, 2025, 12:48 Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > I think the encoding caused a lot of confusion with people (and also I > dont see how it is user friendly - besides if the calling Convention > required it), but I dont think we can change that now. So I agree with > Review and documenting. > > Maybe we need to provide at least a UriParser.decode() public method as > well? (If I want to fix the relative name I would need access to it) > > I was also thinking about not encoding blank, since those %20 are the only > issue i had in practice, but that would somehow manifest the limbo that > many use it wrong and not recognize it - but it is relative uncritical, > more Compact and better to read in most cases. Maybe global Option? > Specials since it was older behavior > > Gruß, > Bernd > > Gary Gregory wrote on 16. Apr 2025 17:02 (GMT +02:00): > > > Hi all, > > > > We probably need a general review of the API to see if we have an overall > > consistency issue RE encoded vs decoded. > > > > I prefer us to be considerate before adding APIs here and there. > > > > We could at least document what is expected for methods that return a > > String or consume a String. > > > > I wonder what the default expected behavior should be? Encoded URI > Strings > > are more usable. Decoded String seem to make sense for pretty printing > and > > display in UIs. > > > > WDYT? > > > > Gary > > > — > https://bernd.eckenfels.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
