You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <ma...@unipr.it> on 2011/09/18 18:51:50 UTC
Rivet 2.0.4
I'm planning to release a 2.0.4 with the few bugfixes
I did, the extended manual with new pages for previously
undocumented commands and the new makeurl command, which
should be 100% compatible, being the support for a
relative URI a simple extension of what the command did
before.
I wonder whether the new load_env and load_headers
commands fit a bugfix release or they ought to
be put off for a 2.1.0 release. I personally favor
to release them right away.
Basically the new commands enable the programmer to
create arrays in a procedure's local scope.
Their argument default value (an array name) has been
fully qualified in order to make it reside in the
::request namespace, which is wiped out before every
request is processed. So, no big deal if they are called
from within a procedure, the net effect will be the same.
As a matter of fact, the new commands are fixing a
possible security weakness: so far calling load_env and
load_headers from a pure Tcl script with default
arguments would force the 'env' and 'headers' arrays
to be created in the global namespace because that's
a .tcl file default scope.
This implies these arrays won't be deleted across
subsequent requests, leaving open in principle the
chance to read environment variables
set in other contexts. Page manuals about these
commands should stress this point in order to
make the programmer aware of the possible pitfalls of
forcing the data to be scoped in the global namespace.
comments?
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.0.4
Posted by Massimo Manghi <ma...@unipr.it>.
Latest changes committed in branches/2.0 for anyone to try them out.
-- Massimo
On Sun, 18 Sep 2011 12:28:41 -0500, Karl Lehenbauer wrote:
> This is really great. Thanks for all your work. I think the
> load_env and load_headers scoping are smart and I favor putting them
> in.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Rivet 2.0.4
Posted by Karl Lehenbauer <ka...@gmail.com>.
This is really great. Thanks for all your work. I think the load_env and load_headers scoping are smart and I favor putting them in.
On Sep 18, 2011, at 11:51 AM, Massimo Manghi wrote:
> I'm planning to release a 2.0.4 with the few bugfixes
> I did, the extended manual with new pages for previously
> undocumented commands and the new makeurl command, which
> should be 100% compatible, being the support for a
> relative URI a simple extension of what the command did
> before.
>
> I wonder whether the new load_env and load_headers
> commands fit a bugfix release or they ought to
> be put off for a 2.1.0 release. I personally favor
> to release them right away.
>
> Basically the new commands enable the programmer to
> create arrays in a procedure's local scope.
>
> Their argument default value (an array name) has been
> fully qualified in order to make it reside in the
> ::request namespace, which is wiped out before every
> request is processed. So, no big deal if they are called
> from within a procedure, the net effect will be the same.
>
> As a matter of fact, the new commands are fixing a
> possible security weakness: so far calling load_env and
> load_headers from a pure Tcl script with default
> arguments would force the 'env' and 'headers' arrays
> to be created in the global namespace because that's
> a .tcl file default scope.
> This implies these arrays won't be deleted across
> subsequent requests, leaving open in principle the
> chance to read environment variables
> set in other contexts. Page manuals about these
> commands should stress this point in order to
> make the programmer aware of the possible pitfalls of
> forcing the data to be scoped in the global namespace.
>
> comments?
>
> -- Massimo
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org