Jerome Dochez wrote On 06/29/06 10:53,:
> II need to review the bug first to see if it should be included.
>
> Jan, what is your take on this bug ?
> Vince, how important is it for them ?
I've committed a partial fix for this to the GlassFish trunk, which
will allow the encoding of multi-byte URIs to be configured (via
domain.xml) on a per-HTTP-listener basis.
However, in order to fully support multi-byte URIs on a per-request
basis, some form of client cooperation will be required.
In the Netbeans sample webapp, the encoding of the response that is
returned when accessing index.jsp is UTF-8.
When the mouse moves above the "link1" link, you can see the link's
address in the status bar, which shows a Japanese character embedded
inside the URL. When you click the link in the page, you can see in
the address bar that this character is encoded as %E3%81%A8, which is
the result of UTF-8 (the response encoding) and URL encoding: In UTF-8
encoding, the Japanese character is represented by 3 octets, which are
URL encoded (resulting in the %E3%81%A8 sequence) before the
request is submitted.
The server must perform corresponding decoding steps on the received
URI before matching it against the webapp's resources: While any given
URI may be URL decoded, the subsequent character decoding step
requires knowledge of the character encoding that was used by the
client. In this case, the server needs to know that UTF-8 must be
used, but it has no way of getting this information from the client.
Our HTTP listeners expose a "uriEncoding" property which allows the
URI encoding to be configured for all requests received by a
particular listener. I just committed (to the trunk) support for
allowing this property to be configured as an http-listener property
in domain.xml. When I set its value to "UTF-8":
<http-listener port="1024" ...>
<property name="uriEncoding" value="UTF-8"/>
</http-listener>
I was able to make some progress: Instead of receiving the 404
mentioned in the bug report, the target JSP is now being found and
processed to a servlet, but for some reason, javac does not produce
any corresponding .class file, resulting in a 500 error:
java.io.FileNotFoundException: no such file:
/space/luehe/ws/sjsas90/publish/glassfish/domains/domain1/
generated/jsp/j2ee-modules/__Jot_WebApplication1__/
org/apache/jsp/?a_jsp.class
I will need to further investigate the JSP compilation failure, but at
least static resources with multi-byte URIs may now be supported (on
the trunk). However, as I explained earlier, multi-byte URI encodings
may be supported (and configured) on a per-listener basis only, and
not on a per-request basis.
Jan
>
> Jerome
>
> vince kraemer wrote:
>
>> Jerome Dochez wrote:
>>
>>>
>>> Checkin guidelines
>>>
>>> 1. Only approved bug fixes are allowed in this release. The current
>>> list of approved bugs is attached. I will run a bugswat soon
>>> to get feedbacks/bugs from module owners.
>>> 2. Please contact Jerome Dochez if you would like to make changes to
>>> the bugs list (cc dev.glassfish.java.net so others can voice
>>> their support/concerns).
>>>
>>
>> How do I get a bug added to the ur1 fix list?
>>
>> I just filed issue 797, which is an i18n issue in the server that one
>> of the NetBeans QA folks encountered.
>>
>> Do I just need to add the magic needfix-9.0peur1 or is that handled
>> by somebody else?
>>
>> Thanks,
>> vbk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>