- From: Dan Brotsky <dbrotsky@Adobe.COM>
- Date: Thu, 1 Mar 2001 10:35:51 -0500
- To: Greg Stein <gstein@lyra.org>
- Cc: w3c-dist-auth@w3.org
At 12:33 AM -0800 3/1/01, Greg Stein wrote:
>That would be a good heuristic for handling this.
>
>We could augment the DAV:href element with an optional attribute, like this:
>
> <D:href
>D:original-charset="iso-8859-1">http://some.host/Magn%FCs.txt</D:href>
>and
> <D:href D:original-charset="utf-8">http://some.host/C%C3%A9sar.txt</D:href>
>
>That will help within the responses (if a server supplies it, then you don't
>have to guess; otherwise, fall back to your heuristic).
This certainly would be a helpful thing for servers to say to clients
(although maybe in some other way), and I second your request to JimW
about adding it as an issue.
> We'd still need a
>way to determine the original charset of the Request-URI, though, to fully
>solve the problem.
I think there's a slightly different way to approach this, especially
since (in general) there's no way to determine the original charset
of the client request.
1. In situations where a returned URI in the response was present in
the client request, I think the server really has to return it
exactly as it was submitted. Otherwise a lot of clients are going to
get really confused, because for sure they're just looking for what
they sent and not expecting to get into all sorts of "oh it's really
the same in canonical form" discussions.
2. In situations where a returned URI in the response is not in the
original request, the server is free to use whatever encoding it's
going to use for path segments, and it can tell the client what is
(either specifically as in Greg's proposal above or more generally
via an OPTIONS setting or some such).
As both clients and servers get smarter about this issue, then
presumably the distinction between these cases starts going away (and
it becomes less important for servers to say what encoding they're
using for path segments). But on the way there this approach allows
for backward compatibility with existing clients that are unaware of
these issues without servers having to guess.
And it has the added advantage of not breaking any client/server
combinations that currently work.
dan
Received on Thursday, 1 March 2001 14:46:05 UTC