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 <neum...@wu.ac.at> wrote: > 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 necessary. > > Since there is currently a large refactoring concerning Unicode handling > going on for > the Tcl community (with potentially different handling in Tcl 8.6, 8.7 and > 9.0, ... hopefully > there will be full support for Unicode already in Tcl 8.7, the voting is > happening right now) > it is not a good idea to come up with a special handling by NaviServer. > These byte sequences > have to be processed sooner or later by Tcl in various versions... > > I do not think it is a good idea to swallow incorrect incoming data by > transforming this > on the fly, this will cause sooner or later user concerns (e.g. "why is > this funny character > in the user name", ...) When the legacy application sends e.g. iso8859 > encoded data, then it > should set the appropriate charset, and it will be properly converted by > NaviServer. > > If for whatever reason this is not feasible to get a proper charset, then > the NaviServer > approach allows to make a second attempt of decoding the data with a > different charset. > > all the best > > -gn >
_______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
