Steve,
In 8916 - if you use:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
If you use w=response.getWriter() than it should work without flush,
since the container does have access to the buffer ( in the first
case the container has no way to access your writer )
I agree that a 2xx response with empty content is perfectly valid
and shouldn't be modified, that's a bug.
Costin
On Thu, 9 May 2002, Steve McCarthy wrote:
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
