Dear Brian,
a short look into the code, at the two different
implementations (and how much they differ) would have avoided this wrong
assumption.
On top of that, as Gustaf suggested, using the "-part path" option you can
obtain the full URL properly converted.
The main point, the main difference with the old implementation, is about
how "reserved characters", like "/", ":", have to be treated.
The old implementation percent-encode reserved characters in any situation.
The new, and I guess correct, implementation percent-encode these character
only when they are not used as delimiters.
This is the relevant RFC 3986 text:
"
Reserved Characters
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
"
Hope it helps,
Maurizio
From: Brian Fenton [mailto:brian.fen...@quest.ie]
Sent: 12 May 2017 16:18
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver
Thanks Gustaf
An issue arose during migration testing which was breaking some of our
existing AOLserver code, then when I saw the documentation issue, I thought
best to check with the list that maybe there was an issue with the Windows
version.
I'll dig into our code and see what the problem is exactly.
thanks
Brian
From: Gustaf Neumann [mailto:neum...@wu.ac.at]
Sent: 12 May 2017 14:52
To: naviserver-devel@lists.sourceforge.net
<mailto:naviserver-devel@lists.sourceforge.net>
Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver
Am 12.05.17 um 13:41 schrieb Brian Fenton:
Thank you David
So, assuming the documentation is incorrect
https://naviserver.sourceforge.io/n/naviserver/files/ns_urlencode.html it
seems that the API has been changed from AOLserver.
Brian
Brian, are you worried about the literal comparison in a test case, or is
there a deeper background?
Some more background: ns_urlencode in AOLserver was always incorrect in
respect to the RFCs, which define different encodings for the "path" and the
"query" part of an URL. Therefore many years ago, NaviServer added flags
"-part" to specify the encoding (implementing an extension of RFC1738
(1994)).
In the (unreleased) tip version of NaviServer on bitbucket, i've updated the
implementation to be in sync with valid RFCs (RFC 3986 for URIs and RFC
6265, cookie encodings). So if one compares the result of a tip version of
NaviServer with the documentation of the released version, the results
differ (btw., the example on the NaviServer man page is bad). See about the
changes in the tip see e.g. [1] and the following postings.
-g
[1] https://sourceforge.net/p/naviserver/mailman/naviserver-devel/?limit=50
<https://sourceforge.net/p/naviserver/mailman/naviserver-devel/?limit=50&vie
wmonth=201703&viewday=22> &viewmonth=201703&viewday=22
--
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
