"Remy Maucherat" <[EMAIL PROTECTED]> 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.
But if I don't, then apparently the container is able to do anything he can with the written data, like /dev/null(ing) it... >> 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. Who gives a damn about web browsers? Cute'n fancy HTML, but a response status of 2xx means -it's-all-right-, and I _want_ my headers to go straight down back to the requestor... I had this problem with Tomcat and AvantGo trying to do my employer's PDA-enabled news site.... >> Question 3 >> The servlet spec allows you to write to the output by either obtaining >> a Writer or an OutputStream from the container, but not both. >> >> Should servlet container behave differently if application writes to >> OutputStream instead of Writer? >> A. No. Behavior should be consistent. >> B. If application returns 2xx other than 200 or 204, and it called >> getWriter(), then the response will be replaced, unless it has >> been committed via flush(), or if the application called >> getOutputStream(). > > A, and behavior IS consistent. > > All your examples from section 3 would work fine. They don't do the same > thing as the invalid test case you attached to the report, in that they > actually do write the bytes. I'll have to triplecheck this with my own eyes... >> I have been frustrated in multiple attempts to report this very glaring bug, >> because the reviewer chooses to close the bugs, dismissing them out-of-hand >> as "invalid" without addressing a single fact, without being able to muster a >> technical argument to where I might be mistaken. > > Your bug really is invalid, but you don't seem to be reading the comments. I believe that his bug is _really_ valid... From what I can see in the code http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/ apache/catalina/valves/ErrorReportValve.java?rev=1.5.2.3&content-type=text/v nd.viewcvs-markup Scroll down 3/4 pages and go to the "report" method... That sucker only returns if statusCode < 200, while to be correct, it should only do it if < 300 (also I'd tend to consider the < 400, so including redirection, not to have a "magically generated" body). Look at invoke, it's clearly glamorously there, if we didn't get the response committed, or an exception in the request, that valve _does_ take the underlying streams _and_ write out data... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
