> "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...
A long time ago, it did I think. Now it doesn't. You can test it easily by using the HelloWorld servlet, and add a setStatus(250). > >> 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... Headers are not modified, except if the reponse was empty, content-type would be modified (but since it was empty, it seems irrelevant to me). > I had this problem with Tomcat and AvantGo trying to do my employer's > PDA-enabled news site.... Really ? What did it do ? > >> 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 don't think it would work ok with all 4.0.x versions. Obviously, I'm only testing with the most recent stuff (happened to be the 4.1.1+). But, yes, it works. > >> 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... It's a bit more subtle than that, actually. You don't need to commit, just write something, as the valve uses getReporter, instead of getWriter to get the writer to write the data. If people feel uncomfortable with the current behavior (although I assure you, it shouldn't break anything), we can change to <300 (many 3xx "need" status reports; at least, Apache give status reports for a lot of them, so I thought it was wise to do the same). Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
