Menu
▾
▴
Re: [naviserver-devel] ns_urlencode on Windows Naviserver
|
From: Gustaf N. <ne...@wu...> - 2017-06-12 20:04:29
|
Am 09.06.17 um 14:35 schrieb Enrique Catalan: > 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 , Dear Enrique, Since you are using the windows version of NaviServer that Maurizio provides, you are not using NaviServer 4.99.15, to which this man page refers, but some newer version (check with [ns_info patchlevel] and/or [ns_info tag]). The version on bitbucket conforms to RFC 3986 (see [1] for details). > 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. RFC 3986 updates RFC 1738 and obsoletes RFCs 2732, 2396, 1808 The detailed definition of the encoding of a query RFC 3986 is summarized in the source code [2]. The definition says clearly query = *( pchar / "/" / "?" ) which means, that slash and question mark should be unprotected. The query part is after the "?" which separates the path from the query. In a path, these characters have to be encoded. Why are you concerned? -g PS: RFC 2718 is about URL *schemes" and is cited in the Tcl manpage about the usage of UTF-8. [1] https://sourceforge.net/p/naviserver/mailman/message/35747431/ [2] https://bitbucket.org/naviserver/naviserver/src/15ad74bc59a51bb53f6feef0135049576289a388/nsd/urlencode.c?at=default&fileviewer=file-view-default#urlencode.c-232 > > Enrique. > > > > > On Thu, Jun 8, 2017 at 9:29 PM, Gustaf Neumann <ne...@wu... > <mailto: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 >> <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... >> <mailto: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 >> <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 >> <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 list >> nav...@li... >> <mailto:nav...@li...> >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> <https://lists.sourceforge.net/lists/listinfo/naviserver-devel> > > |
