- From: Taisuke Yamada <tai@iij.ad.jp>
- Date: Mon, 15 Jul 2002 18:37:38 +0900
- To: w3c-dist-auth@w3.org
Hi. 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