Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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> > > |
|
From: Brian F. <Bri...@qu...> - 2017-06-12 14:28:42
|
Hi Gustaf Many thanks for your kind offer. For now, Enrique has found a good workaround using the TCL ::http::formatQuery command, so we'll use that. All the best Brian From: Gustaf Neumann [mailto:ne...@wu...] Sent: 08 June 2017 20:30 To: nav...@li... Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver 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...<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 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 list nav...@li...<mailto:nav...@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 |
|
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 > > |
|
From: Gustaf N. <ne...@wu...> - 2017-06-08 19:29:54
|
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...] > *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&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... > 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 |
|
From: Brian F. <Bri...@qu...> - 2017-06-08 16:51:49
|
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...] 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&viewmonth=201703&viewday=22 -- Univ.Prof. Dr. Gustaf Neumann WU Vienna Institute of Information Systems and New Media Welthandelsplatz 1, A-1020 Vienna, Austria |
|
From: Gustaf N. <ne...@wu...> - 2017-06-07 07:55:56
|
Dear Ian, In your built process versions for NaviServer and the modules (nsdbpg) are probably not matching. The best is to use the released versions from sourceforge https://sourceforge.net/projects/naviserver/files/naviserver/4.99.15/ Note, that you should install NaviServer first, before building modules, such that the default module-Makefile picks up the right includes. -gn Am 07.06.17 um 00:56 schrieb Ian Harding: > I downloaded the tip from bitbucket.org <http://bitbucket.org> and > tried to build it against naviserver 4.99.15. > > I get an error like this: > > [root@web1 nsdbpg-0.2]# make NAVISERVER=/httpd/Naviserver49 > PGLIB=/usr/local/pgsql/lib PGINCLUDE=/usr/local/pgsql/include > gcc -I/usr/local/pgsql/include -g -Wall -fPIC -pipe > -I/httpd/Naviserver49/include -I"/usr/local/include" > -DHAVE_CONFIG_H -c -o nsdbpg.o nsdbpg.c > nsdbpg.c:58:1: error: unknown type name ‘NsDb_DriverInitProc’ > NS_EXPORT NsDb_DriverInitProc Ns_DbDriverInit; > ^ |
|
From: Ian H. <har...@gm...> - 2017-06-06 22:56:50
|
I downloaded the tip from bitbucket.org and tried to build it against naviserver 4.99.15. I get an error like this: [root@web1 nsdbpg-0.2]# make NAVISERVER=/httpd/Naviserver49 PGLIB=/usr/local/pgsql/lib PGINCLUDE=/usr/local/pgsql/include gcc -I/usr/local/pgsql/include -g -Wall -fPIC -pipe -I/httpd/Naviserver49/include -I"/usr/local/include" -DHAVE_CONFIG_H -c -o nsdbpg.o nsdbpg.c nsdbpg.c:58:1: error: unknown type name ‘NsDb_DriverInitProc’ NS_EXPORT NsDb_DriverInitProc Ns_DbDriverInit; ^ nsdbpg.c:101:1: error: ‘Ns_DbDriverInit’ redeclared as different kind of symbol Ns_DbDriverInit(const char *driver, const char *configPath) ^ nsdbpg.c:58:31: note: previous declaration of ‘Ns_DbDriverInit’ was here NS_EXPORT NsDb_DriverInitProc Ns_DbDriverInit; ^ make: *** [nsdbpg.o] Error 1 Anyone know how to fix? Thanks! |
|
From: David O. <da...@qc...> - 2017-05-29 08:37:53
|
Thanks very much Gustaf! We'll schedule a build and let you know how it goes. On 25 May 2017 at 11:32, Gustaf Neumann <ne...@wu...> wrote: > > but i will be looking into this when times allows. > David, There are now some updates in the repository, removing falso > positives about zombies etc. for eval-timouted nsproxy cases > -g > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Gustaf N. <ne...@wu...> - 2017-05-25 10:32:55
|
> but i will be looking into this when times allows. David, There are now some updates in the repository, removing falso positives about zombies etc. for eval-timouted nsproxy cases -g |
|
From: Gustaf N. <ne...@wu...> - 2017-05-17 10:04:49
|
Am 17.05.17 um 11:58 schrieb David Osborne: > Thanks Gustaf. > We've tested and rolled this change out now and it's looking good. Great, good to know! i am not happy about the warnings/error messages, as it looks to me, getting rid of these would require some API changes to report a more detailed status to the caller and allow it to complain when necessary, .... but i will be looking into this when times allows. all the best -g |
|
From: David O. <da...@qc...> - 2017-05-17 09:58:20
|
Thanks Gustaf. We've tested and rolled this change out now and it's looking good. Regards On 15 May 2017 at 21:01, Gustaf Neumann <ne...@wu...> wrote: > Am 15.05.17 um 17:54 schrieb David Osborne: > > In some cases (but not all), Ns_WaitProcess is logging an error > > immediately after the reaper sends a signal 15. > > > > It's under these circumstances ReleaseProxy seems to find the proxy > > Busy without a slave. > > > > [15/May/2017:16:38:39][23802.7f2f0d7fa700][-nsproxy:reap-] Warning: > > [testpool]: pid 5174 won't die, send signal 15 > > [15/May/2017:16:38:40][23802.7f2f0d7fa700][-nsproxy:reap-] Error: > > process 5174 killed with signal 15 (Terminated) > at least this case are of no concern: the reaper stops the child process > and sends it a signal; then it recognizes, that the child was killed by > a signal and reports this via the error log entry. "Error" is probably > too strong here (for the server it is not clear, who sent the > signal).... grading this down to a "warning" is probably not problematic > and less worrying. > > -gn > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Gustaf N. <ne...@wu...> - 2017-05-15 20:01:29
|
Am 15.05.17 um 17:54 schrieb David Osborne: > In some cases (but not all), Ns_WaitProcess is logging an error > immediately after the reaper sends a signal 15. > > It's under these circumstances ReleaseProxy seems to find the proxy > Busy without a slave. > > [15/May/2017:16:38:39][23802.7f2f0d7fa700][-nsproxy:reap-] Warning: > [testpool]: pid 5174 won't die, send signal 15 > [15/May/2017:16:38:40][23802.7f2f0d7fa700][-nsproxy:reap-] Error: > process 5174 killed with signal 15 (Terminated) at least this case are of no concern: the reaper stops the child process and sends it a signal; then it recognizes, that the child was killed by a signal and reports this via the error log entry. "Error" is probably too strong here (for the server it is not clear, who sent the signal).... grading this down to a "warning" is probably not problematic and less worrying. -gn |
|
From: David O. <da...@qc...> - 2017-05-15 15:54:49
|
In some cases (but not all), Ns_WaitProcess is logging an error immediately after the reaper sends a signal 15. It's under these circumstances ReleaseProxy seems to find the proxy Busy without a slave. [15/May/2017:16:38:39][23802.7f2f0d7fa700][-nsproxy:reap-] Warning: [testpool]: pid 5174 won't die, send signal 15 [15/May/2017:16:38:40][23802.7f2f0d7fa700][-nsproxy:reap-] Error: process 5174 killed with signal 15 (Terminated) On 15 May 2017 at 14:45, Gustaf Neumann <ne...@wu...> wrote: > > i've made the code more robust .... although it is not clear to me yet, > how the > proxy can be "Busy" without having a slave... maybe a race condition. I > will check. > -g > > |
|
From: David O. <da...@qc...> - 2017-05-15 14:07:39
|
Thanks - that stops the seg fault... it does seem to leave a lot of zombies though. This is the output during the ns_proxy test: [15/May/2017:15:03:47][7028.7ffff5c3b700][-command-] Notice: releasing busy proxy testpool-8 [15/May/2017:15:03:48][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7590 won't die, send signal 15 [15/May/2017:15:03:48][7028.7ffff5c3b700][-command-] Notice: releasing busy proxy testpool-8 [15/May/2017:15:03:49][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7590 won't die, send signal 9 [15/May/2017:15:03:49][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7591 won't die, send signal 15 [15/May/2017:15:03:49][7028.7ffff5c3b700][-command-] Notice: releasing busy proxy testpool-8 [15/May/2017:15:03:50][7028.7fffc67fc700][-nsproxy:reap-] Warning: nsproxy: zombie: 7590 [15/May/2017:15:03:50][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7591 won't die, send signal 9 [15/May/2017:15:03:50][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7621 won't die, send signal 15 [15/May/2017:15:03:50][7028.7ffff5c3b700][-command-] Notice: releasing busy proxy testpool-8 [15/May/2017:15:03:51][7028.7fffc67fc700][-nsproxy:reap-] Warning: nsproxy: zombie: 7591 [15/May/2017:15:03:51][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7621 won't die, send signal 9 [15/May/2017:15:03:51][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7622 won't die, send signal 15 [15/May/2017:15:03:52][7028.7fffc67fc700][-nsproxy:reap-] Warning: nsproxy: zombie: 7621 [15/May/2017:15:03:52][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7622 won't die, send signal 9 [15/May/2017:15:03:52][7028.7fffc67fc700][-nsproxy:reap-] Warning: [testpool]: pid 7640 won't die, send signal 15 [15/May/2017:15:03:52][7028.7fffc67fc700][-nsproxy:reap-] Error: process 7640 killed with signal 15 (Terminated) [15/May/2017:15:03:53][7028.7fffc67fc700][-nsproxy:reap-] Warning: nsproxy: zombie: 7622 On 15 May 2017 at 14:45, Gustaf Neumann <ne...@wu...> wrote: > Am 15.05.17 um 15:15 schrieb David Osborne: > > Thanks. > > > > This does indeed seem to fix the test case I sent - > good > > however I'm now getting a segmentation fault during the "make test". > bad > > i've made the code more robust .... although it is not clear to me yet, > how the > proxy can be "Busy" without having a slave... maybe a race condition. I > will check. > -g > > > ------------------------------------------------------------ > ------------------ > 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 > |
|
From: Gustaf N. <ne...@wu...> - 2017-05-15 13:45:34
|
Am 15.05.17 um 15:15 schrieb David Osborne: > Thanks. > > This does indeed seem to fix the test case I sent - good > however I'm now getting a segmentation fault during the "make test". bad i've made the code more robust .... although it is not clear to me yet, how the proxy can be "Busy" without having a slave... maybe a race condition. I will check. -g |
|
From: David O. <da...@qc...> - 2017-05-15 13:15:14
|
Thanks.
This does indeed seem to fix the test case I sent - however I'm now getting
a segmentation fault during the "make test".
It's during the second ns_proxy 5.10 test (there are two 5.10s) - "test
ns_proxy-5.10 {check killing active proxy}".
ns_close is being called on an invalid SlavePtr during ns_proxy cleanup.
Is this something platform specific?
[15/May/2017:13:56:37][1717.7ffff543a700][-command-] Notice: 5.10
[15/May/2017:13:56:38][1717.7fffc99dc700][-nsproxy:reap-] Warning: nsproxy:
zombie: 1782
[15/May/2017:13:56:38][1717.7fffc99dc700][-nsproxy:reap-] Warning:
[testpool]: pid 1785 won't die, send signal 9
[15/May/2017:13:56:38][1717.7ffff543a700][-command-] Notice: releasing busy
proxy testpool-8
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff543a700 (LWP 1722)]
0x00007fffeebe8ba8 in ReleaseProxy (interp=interp@entry=0x7ffff000cf80,
proxyPtr=0x7ffff0456c60) at nsproxylib.c:3261
3261 ns_close(proxyPtr->slavePtr->rfd);
(gdb) print proxyPtr
$1 = (Proxy *) 0x7ffff0456c60
(gdb) print proxyPtr->slavePtr
$2 = (Slave *) 0x0
(gdb) print *proxyPtr->slavePtr
Cannot access memory at address 0x0
(gdb) list
3256 result = Eval(interp, proxyPtr, Tcl_DStringValue(&ds),
-1);
3257 }
3258 Tcl_DStringFree(&ds);
3259 } else if (proxyPtr->state == Busy) {
3260 Ns_Log(Notice, "releasing busy proxy %s", proxyPtr->id);
3261 ns_close(proxyPtr->slavePtr->rfd);
3262 proxyPtr->slavePtr->rfd = NS_INVALID_FD;
3263 }
3264 if (proxyPtr->cmdToken != NULL) {
3265 /*
(gdb) bt
#0 0x00007fffeebe8ba8 in ReleaseProxy (interp=interp@entry=0x7ffff000cf80,
proxyPtr=0x7ffff0456c60) at nsproxylib.c:3261
#1 0x00007fffeebe8d5c in ReleaseHandles (interp=0x7ffff000cf80,
idataPtr=<optimized out>) at nsproxylib.c:3381
#2 0x00007fffeebe6876 in ProxyObjCmd (data=0x7ffff0024ab0,
interp=0x7ffff000cf80, objc=2, objv=0x7ffff001bcd8)
at nsproxylib.c:1668
#3 0x00007ffff71bae59 in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#4 0x00007ffff720195e in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#5 0x00007ffff7200897 in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
#6 0x00007ffff71bc6e6 in TclEvalObjEx () from /usr/lib/x86_64-linux-gnu/
libtcl8.5.so
#7 0x00007ffff724442f in ?? () from /usr/lib/x86_64-linux-gnu/libtcl8.5.so
On 13 May 2017 at 19:53, Gustaf Neumann <ne...@wu...> wrote:
> Hi David,
>
> i've committed a version to bitbucket, that should address the problem.
> Here is what's seems to happen:
> a) in your example, you are sending exec commands with huge output and a
> eval-timeout of 1ms
> b) NaviServer stops it side the eval more or less immediately (after one
> ms)
> c) the slave still tries to send the data, but runs into a blocking
> write operation
> d) the slave does react in this state by "normal" interactions, causing
> the hang.
>
> After my change, NaviServer closes in ReleaseProxy() its end manually,
> in case the slave is busy.
> -g
> PS: it is clear, that we do not see in our production environment this
> problem, since we are not using an eval timeout.
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
|
|
From: Gustaf N. <ne...@wu...> - 2017-05-13 18:53:22
|
Hi David, i've committed a version to bitbucket, that should address the problem. Here is what's seems to happen: a) in your example, you are sending exec commands with huge output and a eval-timeout of 1ms b) NaviServer stops it side the eval more or less immediately (after one ms) c) the slave still tries to send the data, but runs into a blocking write operation d) the slave does react in this state by "normal" interactions, causing the hang. After my change, NaviServer closes in ReleaseProxy() its end manually, in case the slave is busy. -g PS: it is clear, that we do not see in our production environment this problem, since we are not using an eval timeout. |
|
From: Maurizio M. <Mau...@sp...> - 2017-05-13 14:10:29
|
Dear all, CBMC (http://www.cprover.org/cbmc/) symbolic execution of “nsproxy” reports an error in RecvBuff. It could be a false positive. Hope it helps, Maurizio [SendBuf.assertion.1] assertion (slavePtr != ((void *)0)): SUCCESS [SendBuf.assertion.2] assertion (dsPtr != ((void *)0)): SUCCESS [SendBuf.overflow.1] arithmetic overflow on signed * in (ms % 1000) * 1000: SUCCESS [SendBuf.pointer_dereference.1] dereference failure: pointer NULL in *dsPtr: SUCCESS [SendBuf.pointer_dereference.2] dereference failure: pointer invalid in *dsPtr: SUCCESS [SendBuf.pointer_dereference.3] dereference failure: deallocated dynamic object in *dsPtr: SUCCESS [SendBuf.pointer_dereference.4] dereference failure: dead object in *dsPtr: SUCCESS [SendBuf.pointer_dereference.5] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [SendBuf.pointer_dereference.6] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [SendBuf.pointer_dereference.7] dereference failure: pointer NULL in *dsPtr: SUCCESS [SendBuf.pointer_dereference.8] dereference failure: pointer invalid in *dsPtr: SUCCESS [SendBuf.pointer_dereference.9] dereference failure: deallocated dynamic object in *dsPtr: SUCCESS [SendBuf.pointer_dereference.10] dereference failure: dead object in *dsPtr: SUCCESS [SendBuf.pointer_dereference.11] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [SendBuf.pointer_dereference.12] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [SendBuf.pointer_dereference.13] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [SendBuf.pointer_dereference.14] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [SendBuf.overflow.2] arithmetic overflow on unsigned + in iov[(signed long long int)0].iov_len + iov[(signed long long int)1].iov_len: SUCCESS [SendBuf.pointer_dereference.15] dereference failure: pointer NULL in *slavePtr: SUCCESS [SendBuf.pointer_dereference.16] dereference failure: pointer invalid in *slavePtr: SUCCESS [SendBuf.pointer_dereference.17] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [SendBuf.pointer_dereference.18] dereference failure: dead object in *slavePtr: SUCCESS [SendBuf.pointer_dereference.19] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [SendBuf.pointer_dereference.20] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [SendBuf.pointer_dereference.21] dereference failure: pointer NULL in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.22] dereference failure: pointer invalid in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.23] dereference failure: deallocated dynamic object in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.24] dereference failure: dead object in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.25] dereference failure: pointer outside dynamic object bounds in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.26] dereference failure: pointer outside object bounds in *return_value__errno$1: SUCCESS [SendBuf.pointer_dereference.27] dereference failure: pointer NULL in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.28] dereference failure: pointer invalid in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.29] dereference failure: deallocated dynamic object in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.30] dereference failure: dead object in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.31] dereference failure: pointer outside dynamic object bounds in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.32] dereference failure: pointer outside object bounds in *return_value__errno$2: SUCCESS [SendBuf.pointer_dereference.33] dereference failure: pointer NULL in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.34] dereference failure: pointer invalid in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.35] dereference failure: deallocated dynamic object in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.36] dereference failure: dead object in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.37] dereference failure: pointer outside dynamic object bounds in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.38] dereference failure: pointer outside object bounds in *return_value__errno$3: SUCCESS [SendBuf.pointer_dereference.39] dereference failure: pointer NULL in *slavePtr: SUCCESS [SendBuf.pointer_dereference.40] dereference failure: pointer invalid in *slavePtr: SUCCESS [SendBuf.pointer_dereference.41] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [SendBuf.pointer_dereference.42] dereference failure: dead object in *slavePtr: SUCCESS [SendBuf.pointer_dereference.43] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [SendBuf.pointer_dereference.44] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [RecvBuf.assertion.1] assertion (slavePtr != ((void *)0)): SUCCESS [RecvBuf.assertion.2] assertion (dsPtr != ((void *)0)): SUCCESS [RecvBuf.overflow.1] arithmetic overflow on signed * in (ms % 1000) * 1000: SUCCESS [RecvBuf.pointer_dereference.1] dereference failure: pointer NULL in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.2] dereference failure: pointer invalid in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.3] dereference failure: deallocated dynamic object in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.4] dereference failure: dead object in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.5] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.6] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [RecvBuf.overflow.2] arithmetic overflow on unsigned - in (unsigned long long int)dsPtr->spaceAvl - (unsigned long long int)1u: FAILURE [RecvBuf.pointer_dereference.7] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.8] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.9] dereference failure: pointer NULL in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.10] dereference failure: pointer invalid in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.11] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.12] dereference failure: dead object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.13] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.14] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.15] dereference failure: pointer NULL in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.16] dereference failure: pointer invalid in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.17] dereference failure: deallocated dynamic object in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.18] dereference failure: dead object in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.19] dereference failure: pointer outside dynamic object bounds in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.20] dereference failure: pointer outside object bounds in *return_value__errno$1: FAILURE [RecvBuf.pointer_dereference.21] dereference failure: pointer NULL in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.22] dereference failure: pointer invalid in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.23] dereference failure: deallocated dynamic object in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.24] dereference failure: dead object in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.25] dereference failure: pointer outside dynamic object bounds in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.26] dereference failure: pointer outside object bounds in *return_value__errno$2: FAILURE [RecvBuf.pointer_dereference.27] dereference failure: pointer NULL in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.28] dereference failure: pointer invalid in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.29] dereference failure: deallocated dynamic object in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.30] dereference failure: dead object in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.31] dereference failure: pointer outside dynamic object bounds in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.32] dereference failure: pointer outside object bounds in *return_value__errno$3: FAILURE [RecvBuf.pointer_dereference.33] dereference failure: pointer NULL in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.34] dereference failure: pointer invalid in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.35] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.36] dereference failure: dead object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.37] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.38] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [RecvBuf.overflow.3] arithmetic overflow on unsigned - in avail - iov[(signed long long int)1].iov_len: SUCCESS [RecvBuf.overflow.4] arithmetic overflow on signed - in len - n: SUCCESS [RecvBuf.pointer_dereference.39] dereference failure: pointer NULL in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.40] dereference failure: pointer invalid in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.41] dereference failure: deallocated dynamic object in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.42] dereference failure: dead object in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.43] dereference failure: pointer outside dynamic object bounds in *dsPtr: SUCCESS [RecvBuf.pointer_dereference.44] dereference failure: pointer outside object bounds in *dsPtr: SUCCESS [RecvBuf.overflow.5] pointer arithmetic overflow on + in dsPtr->string + n: SUCCESS [RecvBuf.pointer_dereference.45] dereference failure: pointer NULL in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.46] dereference failure: pointer invalid in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.47] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.48] dereference failure: dead object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.49] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.50] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.51] dereference failure: pointer NULL in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.52] dereference failure: pointer invalid in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.53] dereference failure: deallocated dynamic object in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.54] dereference failure: dead object in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.55] dereference failure: pointer outside dynamic object bounds in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.56] dereference failure: pointer outside object bounds in *return_value__errno$6: SUCCESS [RecvBuf.pointer_dereference.57] dereference failure: pointer NULL in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.58] dereference failure: pointer invalid in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.59] dereference failure: deallocated dynamic object in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.60] dereference failure: dead object in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.61] dereference failure: pointer outside dynamic object bounds in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.62] dereference failure: pointer outside object bounds in *return_value__errno$7: SUCCESS [RecvBuf.pointer_dereference.63] dereference failure: pointer NULL in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.64] dereference failure: pointer invalid in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.65] dereference failure: deallocated dynamic object in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.66] dereference failure: dead object in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.67] dereference failure: pointer outside dynamic object bounds in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.68] dereference failure: pointer outside object bounds in *return_value__errno$8: SUCCESS [RecvBuf.pointer_dereference.69] dereference failure: pointer NULL in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.70] dereference failure: pointer invalid in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.71] dereference failure: deallocated dynamic object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.72] dereference failure: dead object in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.73] dereference failure: pointer outside dynamic object bounds in *slavePtr: SUCCESS [RecvBuf.pointer_dereference.74] dereference failure: pointer outside object bounds in *slavePtr: SUCCESS [RecvBuf.overflow.6] arithmetic overflow on signed - in len - n: SUCCESS [RecvBuf.overflow.7] pointer arithmetic overflow on + in ptr + n: SUCCESS From: David Osborne [mailto:da...@qc...] Sent: 12 May 2017 18:19 To: nav...@li... Subject: Re: [naviserver-devel] ns_proxy hang Not sure if this helps you - it may be entirely expected behaviour, but I attached gbp to the nsproxy process and got a backtrace from the 2 test cases I mentioned, immediately after the "ns_proxy eval...". In the case with no hang the nsproxy process is waiting in RecvBuf: #0 0x00007ffff6593250 in __libc_readv (fd=6, vector=vector@entry=0x7fffffffe8a0, count=count@entry=2) at ../sysdeps/unix/sysv/linux/readv.c:54 #1 0x00007ffff7bd717f in RecvBuf (slavePtr=0x7fffffffe930, ms=-1, dsPtr=0x7fffffffe970) at nsproxylib.c:1319 #2 0x00007ffff7bd6391 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50, init=0x7fffffffe970) at nsproxylib.c:578 #3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4, argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287 #4 0x0000000000400765 in _start () The case which hangs, the nsproxy process is still waiting in SendBuf after the "ns_proxy eval..." ends: #0 0x00007ffff65932f0 in __libc_writev (fd=7, vector=vector@entry=0x7fffffffe8b0, count=count@entry=2) at ../sysdeps/unix/sysv/linux/writev.c:54 #1 0x00007ffff7bd6fcc in SendBuf (slavePtr=0x7fffffffe930, ms=-1, dsPtr=<optimized out>) at nsproxylib.c:1245 #2 0x00007ffff7bd6365 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50, init=0x7fffffffe970) at nsproxylib.c:613 #3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4, argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287 #4 0x0000000000400765 in _start () On 10 May 2017 at 15:27, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...> > wrote: I'll look at it at the weekend - unless someone else can fix this before this. -g Am 10.05.17 um 16:00 schrieb David Osborne: Increasing waittimeout doesn't seem to have any effect on this problem. I have backtraces of all threads at the point of the hang here: https://gist.github.com/davidqc/ebee38528b0a40a0b8d028981ad933e6 Thread 19 I think is the culprit: Thread 19 (Thread 0x7fffaaffd700 (LWP 17652)): #0 0x00007ffff6322b89 in __libc_waitpid (pid=pid@entry=17651, stat_loc=stat_loc@entry=0x7fffaaffcde4, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40 #1 0x00007ffff7b5aa4c in Ns_WaitForProcess (pid=17651, exitcodePtr=0x0) at exec.c:178 #2 0x00007ffff1b68615 in ReaperThread (UNUSED_arg=0x44f3) at nsproxylib.c:2935 #3 0x00007ffff74b886d in NsThreadMain (arg=<optimized out>) at thread.c:232 #4 0x00007ffff74b98a9 in ThreadMain (arg=<optimized out>) at pthread.c:830 #5 0x00007ffff5e500a4 in start_thread (arg=0x7fffaaffd700) at pthread_create.c:309 #6 0x00007ffff635162d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 |
|
From: David O. <da...@qc...> - 2017-05-12 16:19:26
|
Not sure if this helps you - it may be entirely expected behaviour, but I
attached gbp to the nsproxy process and got a backtrace from the 2 test
cases I mentioned, immediately after the "ns_proxy eval...".
In the case with no hang the nsproxy process is waiting in RecvBuf:
#0 0x00007ffff6593250 in __libc_readv (fd=6,
vector=vector@entry=0x7fffffffe8a0,
count=count@entry=2)
at ../sysdeps/unix/sysv/linux/readv.c:54
#1 0x00007ffff7bd717f in RecvBuf (slavePtr=0x7fffffffe930, ms=-1,
dsPtr=0x7fffffffe970) at nsproxylib.c:1319
#2 0x00007ffff7bd6391 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50,
init=0x7fffffffe970) at nsproxylib.c:578
#3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4,
argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287
#4 0x0000000000400765 in _start ()
The case which hangs, the nsproxy process is still waiting in SendBuf after
the "ns_proxy eval..." ends:
#0 0x00007ffff65932f0 in __libc_writev (fd=7,
vector=vector@entry=0x7fffffffe8b0,
count=count@entry=2)
at ../sysdeps/unix/sysv/linux/writev.c:54
#1 0x00007ffff7bd6fcc in SendBuf (slavePtr=0x7fffffffe930, ms=-1,
dsPtr=<optimized out>) at nsproxylib.c:1245
#2 0x00007ffff7bd6365 in Ns_ProxyMain (argc=47, argv=0x7fffffffea50,
init=0x7fffffffe970) at nsproxylib.c:613
#3 0x00007ffff64d3b45 in __libc_start_main (main=0x400730 <main>, argc=4,
argv=0x7fffffffec48, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffec38) at libc-start.c:287
#4 0x0000000000400765 in _start ()
On 10 May 2017 at 15:27, Gustaf Neumann <ne...@wu...> wrote:
> I'll look at it at the weekend - unless someone else can fix this before
> this.
>
> -g
> Am 10.05.17 um 16:00 schrieb David Osborne:
>
> Increasing waittimeout doesn't seem to have any effect on this problem.
>
> I have backtraces of all threads at the point of the hang here:
> https://gist.github.com/davidqc/ebee38528b0a40a0b8d028981ad933e6
>
> Thread 19 I think is the culprit:
>
> Thread 19 (Thread 0x7fffaaffd700 (LWP 17652)):
> #0 0x00007ffff6322b89 in __libc_waitpid (pid=pid@entry=17651, stat_loc=stat_loc@entry=0x7fffaaffcde4, options=options@entry=0)
> at ../sysdeps/unix/sysv/linux/waitpid.c:40
> #1 0x00007ffff7b5aa4c in Ns_WaitForProcess (pid=17651, exitcodePtr=0x0) at exec.c:178
> #2 0x00007ffff1b68615 in ReaperThread (UNUSED_arg=0x44f3) at nsproxylib.c:2935
> #3 0x00007ffff74b886d in NsThreadMain (arg=<optimized out>) at thread.c:232
> #4 0x00007ffff74b98a9 in ThreadMain (arg=<optimized out>) at pthread.c:830
> #5 0x00007ffff5e500a4 in start_thread (arg=0x7fffaaffd700) at pthread_create.c:309
> #6 0x00007ffff635162d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
>
|
|
From: Maurizio M. <Mau...@sp...> - 2017-05-12 15:12:37
|
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
|
|
From: Brian F. <Bri...@qu...> - 2017-05-12 14:19:14
|
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... 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 |
|
From: Gustaf N. <ne...@wu...> - 2017-05-12 13:51:44
|
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 |
|
From: Maurizio M. <Mau...@sp...> - 2017-05-12 11:48:21
|
Thank you very much David! Maurizio From: David Osborne [mailto:da...@qc...] Sent: 12 May 2017 13:36 To: nav...@li... Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver --- Welcome to tlc_erp running at /usr/lib/naviserver/bin/nsd (pid 10339) NaviServer/4.99.16d5 for linux built on May 4 2017 at 16:39:38 Tag: tar-4.99.16d5 tlc_erp:nscp 1> ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www.aol.com <http://www.aolserver.com/redirect.adp?url=http://www.aol.com&t=1,2,3> &t=1,2,3 http://www.aolserver.com/redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c3 ---- On 12 May 2017 at 12:32, Brian Fenton <Bri...@qu... <mailto:Bri...@qu...> > wrote: Hi Maurizio I really don’t know. I don’t have access to a Linux installation to check. Are you suggesting that the API may have changed since AOLserver? Brian From: Maurizio Martignano [mailto:Mau...@sp... <mailto:Mau...@sp...> ] Sent: 12 May 2017 12:31 To: nav...@li... <mailto:nav...@li...> Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver Dear Brian, Is this really a “Windows Naviserver” issue or is it a matter of a new implementation of the function, different from what was previously done in Aolserver? The two implementations seem to me quite different. Thanks a lot, Maurizio From: Brian Fenton [mailto:Bri...@qu...] Sent: 12 May 2017 11:15 To: 'nav...@li... <mailto:nav...@li...> ' <nav...@li... <mailto:nav...@li...> > Subject: [naviserver-devel] ns_urlencode on Windows Naviserver I think there might be a problem with ns_urlencode on Windows Naviserver. I just ran this example (taken directly from the documentation): ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www.aol.com <http://www.aolserver.com/redirect.adp?url=http://www.aol.com&t=1,2,3> &t=1,2,3 And the result was unexpected: http://www.aolserver.com/redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c The correct result is http%3a%2f%2fwww%2eaolserver%2ecom%2fredirect%2eadp%3furl%3dhttp%3a%2f%2fwww%2eaol%2ecom%26t%3d1%2c2%2c3 This is breaking some of our existing AOLserver code during migration testing. Any suggestions? Brian Fenton Senior Developer Phone: +353 1 679 9933 <tel:+353%201%20679%209933> <http://www.grantmanagementsoftware.com> grantmanagementsoftware.com <http://www.grantmanagementsoftware.com/> <https://twitter.com/AIMS_qcl> <https://www.linkedin.com/grp/home?gid=2978658> Quest Computing Ltd. Ushers Court | 31-33 Ushers Quay | Dublin 8, Ireland This e-mail transmission may contain confidential information that is intended for the individual or entity named on the e-mail address. If you are not the intended recipient, please reply to the sender so that Quest Computing Ltd can arrange for the proper delivery and then please delete the message from your inbox. If you have received this e-mail in error, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. Quest Computing Ltd., Ushers Court, 31-33 Ushers Quay, Dublin 8, Ireland. Quest Computing Ltd. is registered in Ireland No. 146435. ------------------------------------------------------------------------------ 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 -- David Osborne Qcode Software Limited http://www.qcode.co.uk T: +44 (0)1463 896484 |
|
From: Brian F. <Bri...@qu...> - 2017-05-12 11:43:25
|
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 From: David Osborne [mailto:da...@qc...] Sent: 12 May 2017 12:36 To: nav...@li... Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver --- Welcome to tlc_erp running at /usr/lib/naviserver/bin/nsd (pid 10339) NaviServer/4.99.16d5 for linux built on May 4 2017 at 16:39:38 Tag: tar-4.99.16d5 tlc_erp:nscp 1> ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www.aol.com&t=1,2,3 http://www.aolserver.com/redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c3 ---- On 12 May 2017 at 12:32, Brian Fenton <Bri...@qu...<mailto:Bri...@qu...>> wrote: Hi Maurizio I really don’t know. I don’t have access to a Linux installation to check. Are you suggesting that the API may have changed since AOLserver? Brian From: Maurizio Martignano [mailto:Mau...@sp...<mailto:Mau...@sp...>] Sent: 12 May 2017 12:31 To: nav...@li...<mailto:nav...@li...> Subject: Re: [naviserver-devel] ns_urlencode on Windows Naviserver Dear Brian, Is this really a “Windows Naviserver” issue or is it a matter of a new implementation of the function, different from what was previously done in Aolserver? The two implementations seem to me quite different. Thanks a lot, Maurizio From: Brian Fenton [mailto:Bri...@qu...] Sent: 12 May 2017 11:15 To: 'nav...@li...<mailto:nav...@li...>' <nav...@li...<mailto:nav...@li...>> Subject: [naviserver-devel] ns_urlencode on Windows Naviserver I think there might be a problem with ns_urlencode on Windows Naviserver. I just ran this example (taken directly from the documentation): ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www.aol.com&t=1,2,3 And the result was unexpected: http://www.aolserver.com/redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c The correct result is http%3a%2f%2fwww%2eaolserver%2ecom%2fredirect%2eadp%3furl%3dhttp%3a%2f%2fwww%2eaol%2ecom%26t%3d1%2c2%2c3 This is breaking some of our existing AOLserver code during migration testing. Any suggestions? Brian Fenton Senior Developer Phone: +353 1 679 9933<tel:+353%201%20679%209933> grantmanagementsoftware.com<http://www.grantmanagementsoftware.com> [AIMS Grant and Programme Management]<http://www.grantmanagementsoftware.com/> [Twitter]<https://twitter.com/AIMS_qcl> [LinkedIn]<https://www.linkedin.com/grp/home?gid=2978658> Quest Computing Ltd. Ushers Court | 31-33 Ushers Quay | Dublin 8, Ireland This e-mail transmission may contain confidential information that is intended for the individual or entity named on the e-mail address. If you are not the intended recipient, please reply to the sender so that Quest Computing Ltd can arrange for the proper delivery and then please delete the message from your inbox. If you have received this e-mail in error, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. Quest Computing Ltd., Ushers Court, 31-33 Ushers Quay, Dublin 8, Ireland. Quest Computing Ltd. is registered in Ireland No. 146435. ------------------------------------------------------------------------------ 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 -- David Osborne Qcode Software Limited http://www.qcode.co.uk T: +44 (0)1463 896484 |
|
From: David O. <da...@qc...> - 2017-05-12 11:35:55
|
--- Welcome to tlc_erp running at /usr/lib/naviserver/bin/nsd (pid 10339) NaviServer/4.99.16d5 for linux built on May 4 2017 at 16:39:38 Tag: tar-4.99.16d5 tlc_erp:nscp 1> ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www.aol.com&t=1,2,3 http://www.aolserver.com/redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c3 ---- On 12 May 2017 at 12:32, Brian Fenton <Bri...@qu...> wrote: > Hi Maurizio > > > > I really don’t know. I don’t have access to a Linux installation to check. > Are you suggesting that the API may have changed since AOLserver? > > > > Brian > > > > > > *From:* Maurizio Martignano [mailto:Mau...@sp...] > *Sent:* 12 May 2017 12:31 > *To:* nav...@li... > *Subject:* Re: [naviserver-devel] ns_urlencode on Windows Naviserver > > > > Dear Brian, > > Is this really a “Windows Naviserver” issue or is it a > matter of a new implementation of the function, different from what was > previously done in Aolserver? > > > > The two implementations seem to me quite different. > > > > Thanks a lot, > > Maurizio > > > > > > *From:* Brian Fenton [mailto:Bri...@qu... <Bri...@qu...>] > > *Sent:* 12 May 2017 11:15 > *To:* 'nav...@li...' <naviserver-devel@lists. > sourceforge.net> > *Subject:* [naviserver-devel] ns_urlencode on Windows Naviserver > > > > I think there might be a problem with ns_urlencode on Windows Naviserver. > > > > I just ran this example (taken directly from the documentation): > > ns_urlencode http://www.aolserver.com/redirect.adp?url=http://www. > aol.com&t=1,2,3 > > > > And the result was unexpected: http://www.aolserver.com/ > redirect.adp?url%3dhttp://www.aol.com%26t%3d1%2c2%2c > > > > The correct result is http%3a%2f%2fwww%2eaolserver% > 2ecom%2fredirect%2eadp%3furl%3dhttp%3a%2f%2fwww%2eaol% > 2ecom%26t%3d1%2c2%2c3 > > > > This is breaking some of our existing AOLserver code during migration > testing. > > > > Any suggestions? > > > > *Brian Fenton* > *Senior Developer* > > Phone: *+353 1 679 9933 <+353%201%20679%209933>* > *grantmanagementsoftware.com* <http://www.grantmanagementsoftware.com> > > [image: AIMS Grant and Programme Management] > <http://www.grantmanagementsoftware.com/> > > > > [image: Twitter] <https://twitter.com/AIMS_qcl> > > [image: LinkedIn] <https://www.linkedin.com/grp/home?gid=2978658> > > Quest Computing Ltd. Ushers Court | 31-33 Ushers Quay | Dublin 8, Ireland > > > > > > This e-mail transmission may contain confidential information that is > intended for the individual or entity named on the e-mail address. If you > are not the intended recipient, please reply to the sender so that Quest > Computing Ltd can arrange for the proper delivery and then please delete > the message from your inbox. > > If you have received this e-mail in error, you are hereby notified that > any disclosure, copying, distribution, or reliance upon the contents of > this e-mail is strictly prohibited. Quest Computing Ltd., Ushers Court, > 31-33 Ushers Quay, Dublin 8, Ireland. Quest Computing Ltd. is registered in > Ireland No. 146435. > > > > > > ------------------------------------------------------------ > ------------------ > 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 > > -- David Osborne Qcode Software Limited http://www.qcode.co.uk T: +44 (0)1463 896484 |
14 messages has been excluded from this view by a project administrator.
