Thanks again Gustaf.
We've been happily running rc2 for a few days now without problem.
On Tue, 7 Jun 2022 at 11:13, Gustaf Neumann wrote:
> Dear all,
>
> i've uploaded RC2 to sourceforge.
>
> In short, the changes relative to RC1 are primarily the fallback charsets
> (required to ease the
Dear all,
i've uploaded RC2 to sourceforge.
In short, the changes relative to RC1 are primarily the fallback charsets
(required to ease the situation for sites that have to deal with invalid
UTF-8)
and a change in cookie management to improve future-proofness
(some browsers announced that
Dear David,
the automated shortening for the invalid strings is now committed.
https://bitbucket.org/naviserver/naviserver/commits/51f101928be6d27efe5ab78d7d9a9693026791c1
I'll try to make rc2 soon.
all the best
-gn
On 30.05.22 21:01, Gustaf Neumann wrote:
i agree, this might be a lot of
i agree, this might be a lot of logging, especially when the decoded
strings are long.
Not sure, what the best approach of this is
- an configuration parameter LogInvalidUTF8warnings to deactivate these
messages (default true)
- an configuration parameter NrInvalidUTF8warnings to limit these
Thanks Gustaf - the errorCode will be very handy to trap these encoding
errors.
We're using the per-server "formfallbackcharset" without issue at the
moment. Working well.
One problem we encountered is the Warnings logged when invalid UTF-8 is
encountered.
Some of the POSTs causing encoding
Dear all,
The latest commits
- added the "multipart/form-data" handlingfor fallback charsets,
- provides an error code for invalid UTF-8 and
- adds support for the "_charset_" field for default charsets (see RFC
7578, section 4.6).
Also, the regression test got several more tests.
I have
Thanks as well, change is welcome! ... i've added the documentation for
the configuration variables.
-g
On 20.05.22 16:28, David Osborne wrote:
Thanks Gustaf - I've run some quick tests against the per-server and
global fallback and it seems to work well in the cases we're looking
at -
Thanks Gustaf - I've run some quick tests against the per-server and global
fallback and it seems to work well in the cases we're looking at - thanks
for the fast work!
I've yet to try the ns_getform option but will do so shortly. I've
submitted a pull req for the ns_getform doc which I'm hoping
Hi David,
we have not a global and per-server parameter called "formfallbackcharset",
the flag for "ns_getform" and "ns_parsequery" is now called
"fallbackcharset".
In many cases, using e.g. the per-server parameter should be sufficient
to handle
incorrect queries...
still missing:
Dear David,
i've committed the option "-fallbackencodings" for the commands
"ns_getform" and "ns_parsequery". The implementation covers
"ns_getform", where the data is provided as
"application/x-www-form-urlencoded" either when parsing from memory or
from the spool file. The
Hi Gustaf,
I spotted that *ns_getform *takes a charset argument from looking at the
source code.
The options for overriding charsets at the moment seem to be:
*ns_getform iso8859-1*
*ns_urlcharset iso8859-1*
*ns_getform *
*ns_conn urlencoding iso8859-1*
*ns_getform *
We experimented with
Hi Dave, Maybe i find time slots before the release for easing this
process, e.g.m providing a flag for providing a charset for "ns_getform"
in case it fails, "ns_urldecode" has already a "-charset" flag) but i
have not checked the details how complex this is.
all the best -g
On 13.05.22
Thanks Gustaf,
I didn't pick up that your latest commit makes it possible to catch and
handle an encoding error now.
Thanks - we'll try to address the issue that way.
Regards,
Dave
On Thu, 12 May 2022 at 12:27, Gustaf Neumann wrote:
> Dear David,
>
> NaviServer is less strict than the
Dear David,
NaviServer is less strict than the W3C-document, since it does not send
automatically an error back.
Such invalid characters can show up during decode operations of
ns_urldecode and ns_getform.
So, a custom application can catch exceptions and try alternative
encodings if
Thanks again Gustaf,
I can see the W3C spec you reference seems quite unequivocal in saying an
error message should be sent back when decoding invalid UTF-8 form data.
But I was curious why other implementations appear to use the UTF-8
replacement character (U+FFFD) instead, and found a bit of
Dear all,
i have committed a change to achieve a more consistent and compliant
behavior.
Since all form and query processing of NaviServer happens via API
(ns_urldecode, ns_getform), the current architecture does not allow
direct error messages. The NaviServer philosophy is that the (Tcl)
Dear David and all,
I looked into this issue, and I do not like the current situation either.
In the current snapshot, a GET request with invalid coded
query variables is rejected, while the POST request leads just
to the warning, and the invalid entry is omitted.
W3C [1] says in the reference
Hi Gustaf,
We've been testing *4.99.24 rc1* and it seems pretty solid so far. Thanks
for all the work that went into it.
One change of behaviour that is causing us issues is the handling of
invalid UTF8 characters.
We have a system which regularly POSTs data to NaviServer - sometimes (for
Dear all,
on sourceforge is a release candidate for NaviServer 4.99.24 [1].
Please test if possible. The release should be in the near future.
Below is a preliminary summary of changes.
All the best, and have a nice easter weekend!
-g
[1]
19 matches
Mail list logo
