: > : + static boolean modifiedUTF8 = System.getProperty("jetty.home") != null;
: >
: > ...that seems really hackish to me, particularly since for all we know
: > there are other servlet containers that might have the same problem.
:
: Yeah, it is.
: But it's not really a valid option, it's a bug/limitation in the
: servlet container IMO. It would also suck to bloat configuration (and
: users brains) with options that don't really control anything, except
: that they must correctly match it up with how their servlet container
: behaves. And this doesn't actually fix everything - it simply makes
: it such that encapsulation at the transport layer isn't broken - the
: end user will still be getting back incorrect UTF8.
my suggestion for adding an explicit option for the modifiedUTF8 behavior
to the phps response writer was on the (miss)understanding that the value
was always correct, it was just the length calculation that was being done
wrong by jetty (and correct by other implementations) so if we noticed we
were running in jetty we'd replace the length calculation with our own
(which might be less efficient).
but i guess i don't really understand the patch ... actually, the more i
look at it the less i understand it....
The modifiedUTF8 boolean only influence the numeric length returned as the
"s" option ... the actaully "val" string is still written "as is" by the
servlet container. you've also changed the behavior so that even when
false==modifiedUTF8, the length is now computed differently then before
the patch (using UnicodeUtil.UTF16toUTF8) ... it's this second change i
don't understand based on the context of the bug: why does the length
value need to be computed differnetly for non-jetty implemntations?
: containers hands and do it all ourselves. Or just don't support any
: servlet containers that can't handle code points outside the BMP? Or
I'm in favor of this approach .. if the container can't correctly output
some characters, i see no reason to hide the bug -- if somebody else wants
to code arround the bug by doing it all in solr that's fine, but untill
then i don't see an advantage in outputing the correct number of bytes for
a garbage string -- anybody who really cares is going to need to switch to
a differnet servlet container anyway.
: is there simply a Jetty config option we've been missing. It's hard
: to believe that such a popular servlet container can't handle this.
hey, i don't even understand the bug enough to know what to search for to
try and find an option.
-Hoss
