Re: [naviserver-devel] ns_urlencode on Windows Naviserver

[Maurizio M. <Mau...@sp...>]

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:Bri...@qu...] 
Sent: 12 May 2017 16:18
To: nav...@li...
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:ne...@wu...] 
Sent: 12 May 2017 14:52
To: nav...@li...
<mailto:nav...@li...> 
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