So it would seem that there is a client that completely disobeys the specification for the "text/xml" mime type.
My personal take would be to respect whatever the XML said its encoding was, regardless of what the specifications say, if only because of the locality of reference. When using a client that sends data to the server, who knows how it decides what to put in any of the HTTP headers? I don't get why the RFC 2376 folks saw fit to override that behavior with a US-ASCII default.
Perhaps an email to the RFC authors is in order?
As I've said before, I just use the client side stuff, so I leave to you and others to battle out....
-Eric.
Martin Holz wrote:
Eric Johnson <[EMAIL PROTECTED]> writes:
Scenarios, then:
type text/xml without charset, encoding in XML header --> assume
"us-ascii", ignore encoding in header.
^^^ You mean XML header here, not HTTP header, right?
That's the scenario, I encountered with a small derivation.
There was no encoding in the XML header either. This implies
UTF-8 (or UTF-16, if a byte order mark is present).
That's, what DAVExplorer sends.
========= Outbound Message ========= PROPPATCH /webdav/vsc/t1.vlu HTTP/1.1 Host: bog:8080 Connection: TE TE: trailers, deflate, gzip, compress User-Agent: UCI DAV Explorer/0.81 RPT-HTTPClient/0.3-3E Cookie: JSESSIONID=AD539506333E7C8727E3DCE3763C7240 Cookie2: $Version="1" Authorization: Basic aG9sejpwcTE3K1IyRDI= Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress Content-type: text/xml Content-length: 150
<?xml version="1.0"?> <A:propertyupdate xmlns:A="DAV:" xmlns:B="davex"> <A:set> <A:prop> <B:foo>Säure</B:foo> </A:prop> </A:set> </A:propertyupdate>
=======================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
