W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: FW: character encoding.

From: Taisuke Yamada <tai@iij.ad.jp>
Date: Mon, 15 Jul 2002 18:37:38 +0900
To: w3c-dist-auth@w3.org
Message-ID: <vwzsn2lfi1p.fsf@pekoe.iij.ad.jp>


I assume you're having a problem with charset encoding in HTTP
request-line and HTTP header. I don't know if this encoding issue
has been discussed in the past, but I believe the general consensus
is to use UTF-8 in any case.

I think there's some notes on this issue in rfc2396 and rfc2277 (can
anyone correct me?). As there is no way to transmit encoding
information for HTTP request-line and HTTP header, this seems to be
the only solution.

Of course, the problem is that not all clients/servers actually
follow this scheme - older implementation tends to transmit (or
expects to receive) whatever the encoding it uses locally. This
obviously causes interoperability problem when non-ASCII named
resource is used. I currently get around the problem by plugging
an encoding detection/conversion filter in the server I'm running.

This problem was not apparent (or critical) before WebDAV, because
it was not a common practice to give non-ASCII URL to web browsers.
Only after the WebDAV, the Web become writable as "filesystem", and
people started to use non-ASCII filenames.

> Second i have a java implementation of a webdav server running on
> resin (webserver). Resin allows one to specify character encoding
> in the conf file. However when used with other webservers or
> OS (using windows just now) it isnt possible to set the character
> encoding. Therefore when my windows explorer client sends the
> encoded request the server doesnt recognise it and spits out a bad
> request 400. DO i now have to go and implement the character
> encoding too?

Taisuke Yamada <tai@iij.ad.jp>
Internet Initiative Japan Inc., Technical Planning Division
Received on Monday, 15 July 2002 06:10:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC