On 11/21/18 10:53 AM, Ronnie Brunner wrote:
Hi Massimo
Both test suites run flawlessly on my system.
My only concern would be whether we should introduce a potential
incompatibility in a patch version or whether this justifies a minor
version upgrade... I'm torn, it seems a border case and I can live
with both as long as it was a conscious decision on your side and not
just by accident.
Gruess Ronnie
Hi Ronnie,
I've been asking myself exactly the same question. The answer I gave is
grounded on 3 reasons:
1) Rivet provides ::rivet::load_response as a function for loading the
data coming from an HTML form. This Tcl procedure calls [::rivet::var
all] which loads URL encoded and POSTed data as well. Any procedure
using ::rivet::load_response is therefore unaffected and form handling
done by direct calling ::rivet::var is likewise unaffected
2) Code calling 'var_qs' and 'var_post' after they have been imported
into the global namespace must be doing the correct assumptions about
them otherwise that code is already broken anyway. The wrong way to use
them is to read data sent with an HTTP 'POST' by calling var_qs and vice
versa
3) Code that could be affected basically must do wrong assumptions about
what ::rivet::var_qs and ::rivet::var_post do and it must be calling
these commands using their fully qualified form.
the 3 new tests in tests/post.test should guard for possible future
regressions
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
