Repo link on SF Summary page pointing to obsolet Bitbucket repository
Thanks a lot for reporting. The link is now pointing correctly to GitHub
Repo link on SF Summary page pointing to obsolet Bitbucket repository
There is now (since Nov 6) a change following your request in the repository: https://github.com/naviserver-project/naviserver/commit/48c541c3ac647c1f45462d3c9dd90fbfbd7f1b48 Note, that this is not the usual source location (there is currently a problem on bitbucket with their changes in the licensing model). Furthermore, this change is in the main branch, whereas your diff above is from the release/4.99 branch. There are substantial changes in the main branch (to be used in the release 5.0 of NaviServer)...
No. I just need the absolute path of the currently executing script (for CGI program).
contrary to documentation "name" option to [ns_set create] is not optional.
UTF8 input not validated
There was a large reform for handling UTF-8 in NaviServer - and in Tcl as well. Full support for UTF-8 from Tcl will be introduced by the forthcoming Tcl9. NaviServer performs peroper conversions where ever necessary (e.g. in the DB drivers). Furthermore, there is a validation support in NaviServer on the Tcl level "ns_valid_utf8" and on the C API level "Ns_Valid_UTF8()".
contrary to documentation "name" option to [ns_set create] is not optional.
Many thanks for the report. This has been fixed apparently some time ago.
Is there an application that needs this variable? According to https://www.php.net/manual/en/reserved.variables.server.php scripts executed with the CLI (such as file.php or ../file.php), SCRIPT_FILENAME will contain the relative path specified by the user, otherwise the absolute pathname (not the requested file name, but the path on the file system). Is this also your expectation?
Support SCRIPT_FILENAME (NSCGI)
ns_accesslog extendedheaders
Hi Khy, Thanks for the report, this is fixed by https://bitbucket.org/naviserver/naviserver/commits/b50875f5dea00dc1c7c00ceed77e1fbacb7a6c1f Setting the extendedheaders via configuration file was ok, we use e.g. ns_section ns/server/${server}/module/nslog { ... ns_param extendedheaders "Host X-User-Id X-Mobile_p" ... } all the best -g
ns_accesslog extendedheaders
contrary to documentation "name" option to [ns_set create] is not optional.
Provide access to default configuration
The magic of config values was addressed in 3 ways: a) the config operations can be traced via "ns_logctl severity dev on" b) whenever a config option is read the values have been made visible through introspection c) all values can be inspected via the nstats module (nsstats?@page=configparams)
Timeout in DriverRecv?
The code has been rewritten several time since the bug report. All of Driver-IO is non-blocking. The receive operation performs the timeout wait operation only, when a timeout is provided.
Virtual Hosts
'ns_schedule_proc -once 0 foo' now fails but should work
fixed in git
we have fixed this already locally.... will push this to git as soon as possible
'ns_schedule_proc -once 0 foo' now fails but should work
ns_sourceproc does not work as intended (from tcl/file.tcl)
Your are right. I removed one inconsistency about enabletclpages about one year ago [1], so ns_sourceproc could be used in plain NaviServer until then. Yes, in OpenACS the request processor takes over, using its own abstractions and mapping to physical files. [1] https://bitbucket.org/naviserver/naviserver/commits/3d68beae91e629c72b283ce181cbf36d1f973421
Okay, I was playing around with a precompiled version of naviserver on Windows from Spazio, the changes to file.tcl to use ns_register_tcl were made about a year ago. I guess not loading OpenACS exposed this issue. With OpenACS, I guess the request processor takes over. So to answer your question, I was using an old version of file.tcl, which I didn't realize until now.
invalid request 400 (Bad Request)
By default, "enabletclpages" registers tcl procs via ns_register_tcl $method /*.tcl and not via ns_register_proc $method /*.tcl ns_sourceproc, what you seem to use. From my understanding ns_sourceproc is outdated..... may i ask, why you use this? When ns_sourceproc is used, you are right, i can confirm that there is/was an error. I have fixed that along the lines you are mentioning in the bitbucket repository.