Hello J�rgen,I like this solution, but then I am only a user of client side DAV support code from Slide.
"Pill, Juergen" <[EMAIL PROTECTED]> writes:
Hello Martin,
You discovered a serious bug, IMO.
I think converting the body into a string (at readRequestContent()) is not
the best idea. If the body is an XML document, the best thing to do is to
feed the byte stream into the parser and let him decide on the encoding
issue. In this case we do not require the client to send an explicit
encoding.
That is not my reading of the specifications. From 2376
Only in case of the body is really required as a string (I am personally not aware of any WebDAV method requiring so), convert the bytes into a String. Here your default definitely makes sense.
I want to suggest to change the type of requestBody to byte[] or (better) InputStream. Any objections?
That was my first idea too. However the Webdav spec chapter 16
http://asg.web.cmu.edu/rfc/rfc2518.html#sec-16
cites RFC 2376 http://www.zvon.org/tmRFC/RFC2376/Output/
RFC 2376 clearly states, that the header overrides the <?xml encoding?> directive.
"Conformant with [RFC-2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of 'us-ascii'. In cases where the XML entity is transmitted via HTTP, the default charset value is still 'us-ascii'."
However, "application/xml" is a different case, in that as the RFC declares, the "charset" is "authoritative". I interpret this to mean that in the absence of any better information, you should be able to rely on the charset specified in the MIME headers. Section 14 of RFC 2518 indicates that either text/xml or application/xml is acceptable.
Scenarios, then:
type text/xml without charset, no encoding in XML header --> assume "us-ascii"
type text/xml with charset, no encoding in XML header --> use charset from mime header.
type text/xml without charset, encoding in XML header --> assume "us-ascii", ignore encoding in header.
type text/xml with charset, encoding in XML header --> use charset from mime header, again ignore encoding in header.
type application/xml without charset, no encoding in XML header --> best guess of XML processor?
type application/xml with charset, no encoding in XML header --> use charset from mime header
type application/xml without charset, encoding in XML header --> use XML header encoding
type application/xml with charset, encoding in XML header --> if not matched encodings, bad request (two authoritative sources disagree)?
Does the above capture all the cases? Alas, too bad SAX parsers don't tend to report the encodings they determine.
-Eric JohnsonSo leaving the interpretation to the parser would be a bug. Currently slide works correct, if the client obeys the webdav specification. webdav requires the client to send a encoding. Trouble starts, when the client violates the specs and does not send a header.
The correct answer would be either returning a 400 (Bad Request) or apply RFC 2376 example 6.4 and assume ASCII. This would result in a XML parse error, when the body is UTF-8.
If you assume UTF-8, only if no encoding is given, slide behaves well for conforming clients. It follows RFC 2376, which is laxer here then RFC 2518,since UTF-8 is a superset of ASCII and also works with cadaver and DAVExplorer. I am not aware of any client, which would have problems, but I dont't know many of them.
Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
