From: Enrique C. <ec...@ec...> - 2017-06-09 13:08:24
|
Hi, Here is a good test case of Brian's point that shows more details about the problem which is when the URL has another URL as a value of an url var, check this out: % set url "/comments/view?object_id=45&return_url=/ticket/view?x=456&ticket_id=90" if we run "ns_urlencode -part query $url", in the naviserver implementation that follows the RFC #1738 as per https://naviserver.sourceforge.io/n/naviserver/files/ns_urlencode.html , we get this result: /comments/view?object_id%3d45%26return_url%3d/ticket/view?x%3d456%26ticket_id%3d90 ( it doesn't encode the / and ? in the value of return_url ). However, if we use the TCL implementation, "::http::formatQuery $url", which seems to follow a different RFC, RFC #2718, as per https://www.tcl.tk/man/tcl8.6/TclCmd/http.htm#M11 , we get this result: %2Fcomments%2Fview%3Fobject_id%3D45%26return_url%3D%2Fticket%2Fview%3Fx%3D456%26ticket_id%3D90 We understand the importance of having the flag -part to encode separately the path or the query, this is great but our concern is that when using -query, it doesn't seem to encode the / and ? when used as value of a variable. Enrique. On Thu, Jun 8, 2017 at 9:29 PM, Gustaf Neumann <ne...@wu...> wrote: > Brian, > It is certainly possible to overload every command, but i would not > recommend it, since this can break code in various ways, and i would not > recommend to rely in general on the non-standard-confoming AOLserver > encoding.I would rather recommend to implement a new function (e.g. > ns_urlencode_aol) which can be used in your UUID implementation. Would > this be an acceptable approach for your system? i could dig out the > AOLserver code and send you such an implementation, in case that would be > of use for you. > > -g > PS: there are many - also pretty standard - ways to compute an UUID. An > UUID should not depend on an encoding representation, which is just > intended as a temporary representation for transit, internally everything > should work on the decoded values. > > > Am 08.06.17 um 18:50 schrieb Brian Fenton: > > Hi all > > > > I'm back again with more questions about changes to ns_urlencode in > Naviserver. > > > > 1. Can someone confirm what is the default for -part, query or > path? From my own tests, it seems to be "query" but I couldn't see it in > the docs here https://naviserver.sourceforge.io/n/naviserver/ > files/ns_urlencode.html > > > > 2. in the case where the query portion of a URL, has a value which itself > is a url, Naviserver handles this differently than AOLserver e.g. > > ns_urlencode "url=/wf/task?task_id=2" returns: > > url%3d/wf/task?task_id%3d2 > > > > Under AOLserver, this returns: > > url%3d%2fwf%2ftask%3ftask%5fid%3d2 > > > > This is something widely used in our application, where we have a UUID > implementation, which relies on encoding and decoding URLs, and comparing > them to cached values. Unfortunately this difference in how Naviserver and > AOLserver implement this is giving us some issues (of our own making, > admittedly). > > > > Has anyone any suggestions for how to obtain the AOLserver behaviour under > Naviserver? Would it be difficult to overload ns_urlencode? > > Would be grateful for any advice. > > > > best wishes > > Brian > > > > *From:* Brian Fenton > *Sent:* 12 May 2017 15: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... <ne...@wu...>] > *Sent:* 12 May 2017 14:52 > *To:* 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&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 lis...@li...https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > -- > 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 > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > |