"Because of the lack of proper support for non-ASCII characters in file
names, it is recommended that administrators not attempt to use any
non-ASCII characters in file names. Any other configuration is
unsupported.
Apache 2.0 introduces the UTF-8 convention to access any filenames and
resources in a predictable and safe manner. The implementation of this
feature is too extensive to consider backporting to Apache 1.3."
On Wed, Jan 7, 2009 at 6:18 AM, sathya sai <sathyasai.eshwar@xxxxxxxxx> wrote:
> Hi Apache folks,
>
> When I enter http://x.x.x.x/docs/あいうえお.pdf (x.x.x.x a japanese system) from
> my firefox browser, I could see that my browser translates the URI resource
> portion to UTF-8 encoded formated
> (%E3%81%82%E3%81%84%E3%81%86%E3%81%88%E3%81%8A.pdf) which is as expected.
>
> But although the file is avialable on the specified path, my apache server
> fails with 404 error. In further analysing the problem, I could see that the
> problem could be because apache internally translates/maps URI あいうえお.pdf to
> 49/%82%a0%82%a2%82%a4%82%a6%82%a8.pdf , which is in shift_JIS format instead
> & thus failing when the incoming request is UTF-8 encoded resource path. And
> also, when I enter
> http://x.x.x.x/docs/49/%82%a0%82%a2%82%a4%82%a6%82%a8.pdf from my browser I
> could see that the document is getting displayed as expecte d.
What's the evidence that the request contained the UTF-8 sequence?
That seems like the suspicious part, given what Apache tried to serve.
--
Eric Covener
covener@xxxxxxxxx
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|