Hello J�rgen, "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. > 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. So 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]
