Remy Maucherat wrote: > Mark Thomas wrote: >> Looking into bug 37072 has identified a conflict in the spec. >> http://issues.apache.org/bugzilla/show_bug.cgi?id=37072 >> >> Consider the following sequence of calls: >> >> response.setCharacterEncoding("UTF-8"); >> response.getWriter(); >> response.reset(); >> >> After this the writer encoding and response encoding do not agree and >> can not be reconciled: >> - the Writer is using UTF-8 because the reset only clears the buffer, >> it doesn't reset the writer's encoding >> - response.getCharacterEncoding returns ISO-8859-1 due to the reset >> - response.setCharacterEncoding has no effect since the getWriter() >> call sets the usingWriter flag that prevents changes to the character >> encoding. >> >> The spec is clear that: >> - reset() clear all the headers > > This means there's no way to send the char encoding, so this means it is > reset as well. > >> - calls setCharacterEncoding() have no effect after getWriter() >> >> What isn't clear is should the call to reset() also clear the writer >> (assuming of course that the response isn't committed)? Along the same >> lines is getWriter(), reset(), getStream() be legal? >> >> I am minded to clear the writer, buffer, stream and associated flags >> on reset(). > > It's not up to us (IMO) to start dealing with possible contradictions in > the specification, esp when there's no use case for the situation, and > the reports should be invalid. At least, unless you enjoy it, in which > case it would be ok :)
I think it is up to us to raise such contradictions with the expert group for clarification. Aren't you on the expert group or am I mis-remembering? The obvious use case is error pages. Given I do enjoy fixing bugs - why else would I do it ;) - am I correct in taking your comment to mean you are not against such a change to the reset() method? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
