Remy Maucherat wrote: >>Question 1 >> Does servlet specification require you to call flush() to ensure that >> the client actually see the bytes? >> A. No, spec does not mandate this behavior for webapps. >> B. "you have to flush your writer. Otherwise, because of timing >> problems, the bytes will not get written" (bug 8916) >> > >If you instantiate a buffered writer yourself (instead of using >resp.getWriter) >to wrap around resp.getOutputStream, you have to flush it. >So it's B. > Wrong again, Remy. And please stop introducing diversions like "instantiating a buffered writer yourself." The bug exists with the Writer returned from the container.
Please go the the Java Servlet Specification, v2.2 Final Release. Where does it put the burden of flushing buffer on the web application? Please cite the chapter and section. Of course you can't because it is not there. Why is Tomcat 4.0.x is the only servlet container that requires this strange behavior? Old JServ didn't. WebLogic doesn't. I don't see how a reasonable developer can not answer "A". Also, what is this business you said about "because of timing problems, the bytes will not get written?" Do other developers agree with this statement? > > >>Question 2 >> Where in servlet spec (or RFC 2616, your choice) does it allow >> the container to replace the message body or content-type header for >> >an > >> application that has set the status code to 2xx? >> A. It doesn't. It shouldn't. That would be clearly wrong. >> B. 200's and 204's are left alone, all other 2xx status codes are >> fair game to have their headers and body replaced. >> > >If the servlet didn't do anything other that set headers, and did not write >any >content, it doesn't contrdict any spec, and is desirable if the client is a >web browser. >B also. > Please don't introduce another diversion that it somehow matters whether the servlet set any body content or not. If it is 2xx, leave it alone. It is reasonable even to leave 3xx responses alone. And for the record, the bug exists if body content has been written. Your answer again does not make sense. Here is a real-world example. Say I write a WebDAV servlet. It writes text/xml. It returns 207, which is not an error. Nor is this an "invalid test case." Now if the XML body is relatively short (smaller than whatever the container sets the buffer size in the Writer), when my servlet relinquishes control to Tomcat, Tomcat will stomp the body and change the content type! Please explain again to everyone why this is the right behavior. Right now the only way to work around this behavior is to write a longer message, which causes the container-provided Writer to internally flush its buffer, or to force all servlet authors to manually call flush(). And remember, this is just a workaround. ErrorReportValve.java is still trying to overwrite the response- it just can't do it once the response is committed. >Your bug really is invalid, but you don't seem to be reading the comments. > Then when will you cite an RFC or specification to contradict my argument? I give you overwhelming and specific evidence of a bug, yet you don't contradict even one of my statements. I am confident that you can't. Still I wait for an rebuttal with technical merit. I can justify every single assertion that I have made and back them up with RFC, specification, or common sense. -Steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
