cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <>
Subject [servlet API wrapper] may solve non-latin reqest.getParameter() problem (was: [C2] Requirement for Servlet in extra-classpath solution)
Date Sat, 10 Mar 2001 20:24:20 GMT
From: "Tagunov Anthony" <>
To: "" <>
Cc: "" <>
Date: Sat, 10 Mar 2001 23:15:41 +0300
Reply-To: "Tagunov Anthony" <>
Priority: Normal
X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;6)
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
Subject: Re: [C2] Requirement for Servlet in extra-classpath solution

On Thu, 08 Mar 2001 11:25:44 -0500, Berin Loritsch wrote:

>I just realized, there is an elegant method of removing the
>requirement for the servlet.jar file from the classpath.
>If we make all of our compiled elements use our own wrapper
>classes, then the Compiler doesn't need to see the
>javax.servlet.* classes.  This means we can implement the
>sitemap and XSP pages to compile regardless of the environment.
>Basically we would be using the AbstractFactory pattern, so
>we need to specify the interfaces (extending the Servlet
>interfaces).  We then provide the implementations in the
>environment.http and environment.commandline packages.
>By using our own interfaces, we can standardize on one
>interface--efectively allowing Servlet 2.2 environments to
>simulate Servlet2.3 request and response objects.
>Talk about future proofing the code.  No missing features
>to worry about, and the average developer can take advantage
>of *some* servlet 2.3 features now, and know they will work
>the same when it is commonly available.

Evrybody wants to catch his own rat!
If such a thing would find its way into existence, then
we could have one of the encodings problems solved!

The problem is that at least with some servlet engines
(including Tomcat 3.1.x) there is the following trouble:
(i've already described it on the list, but now it look a
good time to re-describe ;)
  if we have HTML page in an ecoding other then 8859_1
 (say, UTF-8, for example, but the following appllies to
  Cyrillic encodings too)
 and have an input form in this page. Let there be a text
  input element on it, say with the name "foo".
 Imagine you type something non-latin there.
 Then the browser (both IE and NS of versions that
  support UTF-8) takes the imputed non-latin test,
  conversts to the bynary representation of the text
  in UTF-8 (non-latin chars take two bytes), %-s every
  byte and sends it to the server like ..?foo=%DA%13
  (the codes to not correspond to anything, just from my 

  To get back the nice UTF-8 chars one has too
   new String(request.getParameter("foo").getBytes("8859_1"),"UTF-8")

In particular this happens on WAP phones (at least in our tests
Ericcson R320 phone transmitted cyrillic chars exactly in this way.)

  - o -
Does anybody know, has there been any progress with this in Servlet 2.3 spec?
  - o -
The trouble is that the Servlet Engine can not automatically determine the
encoding of the request parameters: the browsers do not send it in the
request :-(

So the only way to get values right is to _know _what_ _was_ _the_ _encoding_ 
_of_ _the_ _page_  and reconstruct the request parameters  in the fashion 
described above.

Bad but better then nothing this can be handled in the intermediate layer between 
the application (xsp pages, xslt transformations having access to http request
parameters, custom actions, matchers, selectors, custon generators and processors)
and the servlet-engine-provided request class proposed above.

 --somewhere in the sitemap
 --in some action
where the encoding of the page is know, the correct value could be fed into this 
intermidiate layer.. 

To avoid confusion, it could have two methods for retriving request parameters:
one would return directly request.getParameter() and the other would throw
exception if invoked and the encoding was not set yet. After it has been set
it would return the recoded value. Setting the encoding twice will be disallowed...
   - o -

BAD. VERY BAD. This thing should be handled in the servlet api. If it isn't 
it still looks VERY AWKWARD to handle this in the intermidiate layer between
servlet api and our apps.. 

But is there a better solution? What we have now:
either new String.. and the stuff code near all parameter retrival? Without
concentrating the information of what encoding should be used in one place
but letting it float all over the code? Each developer individually develping 
a method recode(String val, String encoding) somewhere in his personall 
utilities? To me it's even worse..

  - o -

I heard there's some good NLS support in Jetspeed. Would be VERY intrigued
to know if they have a way of solving the trounble. That's why posting to both

Best regards, Tagunov Anthony

To unsubscribe, e-mail:
For additional commands, email:

View raw message