Should One Call .Close() on Httpservletresponse.Getoutputstream()/.Getwriter()

Should one call .close() on HttpServletResponse.getOutputStream()/.getWriter()?

Normally you should not close the stream. The servlet container will automatically close the stream after the servlet is finished running as part of the servlet request life-cycle.

For instance, if you closed the stream it would not be available if you implemented a Filter.

Having said all that, if you do close it nothing bad will happen as long as you don't try to use it again.

EDIT: another filter link

EDIT2: adrian.tarau is correct in that if you want to alter the response after the servlet has done its thing you should create a wrapper extending HttpServletResponseWrapper and buffer the output. This is to keep the output from going directly to the client but also allows you to protect if the servlet closes the stream, as per this excerpt (emphasis mine):

A filter that modifies a response must
usually capture the response before it
is returned to the client. The way to
do this is to pass the servlet that
generates the response a stand-in
stream. The stand-in stream prevents
the servlet from closing the original
response stream when it completes and
allows the filter to modify the
servlet's response.

Article

One can infer from that official Sun article that closing the OutputStream from a servlet is something that is a normal occurrence, but is not mandatory.

Should I close the servlet outputstream?

You indeed don't need to do so.

Thumb rule: if you didn't create/open it yourself using new SomeOutputStream(), then you don't need to close it yourself. If it was for example a new FileOutputStream("c:/foo.txt"), then you obviously need to close it yourself.

Reasons that some people still do it are just to ensure that nothing more will be written to the response body. If it would ever happen, then this will cause an IllegalStateException in the appserver logs, but this wouldn't affect the client, so the client still gets the proper response. This is also an easier debug to spot the potential problems in the request-response chain which you wouldn't see at first glance. For example, something else is appending more data to the response body somewhere further down in the chain.

Another reason which you see among starters is that they just wanted to prevent that more data is written to the response body. You see this often when JSP incorrectly plays a role in the response. They just ignore the IllegalStateExceptions in the logs. Needless to say that this particular purpose is bad.

Close Encapsulating Writers/Streams for ServletOutputStream

The OutputStream is something you're not creating, you just query a reference to it with ServletResponse.getOutputStream(). Therefore if you put something around it (e.g. OutputStreamWriter or ZipOutputStream) the wrapper stream or writer will just write to it.

It is implementation dependant whether closing a wrapper stream or writer closes the underlying stream, so you should not close that. But since in most of the cases the wrappers only use the underlying stream to write bytes, it is more than enough to flush the wrapper.

In cases where the wrapper needs some finalizing, it should be (and generally is) the wrapper's responsibility to provide this finalizing functionality in a separate method. For example ZipOutputStream provides a finish() method which finishes writing the contents of the ZIP output stream without closing the underlying stream.

Summarizing:

You should not close the wrapper, but check if it provides some finalizing method without closing the underlying stream, which you should obviously call.

Does a servlets PrintWriter out stream really need to be closed?

If it's not you that's opening the stream, you should not close it.

The stream is opened by the container so the responsibility for closing lies with it.

Should I explicitly close ZipOutputStream over response.getOutputStream()?

Generally speaking the closing the outermost stream will propagate the close() to inner streams, closing all required resources.

It's of course perfectly possible to create a badly behaving stream, but ZipOutputStream probably isn't one.

In some cases it may not be enough to call close() on the outermost stream, but the documentation for the class should indicate any special behaviour.

Handling the Writer/OutputStream returned by ServletResponse's .get{Writer,OutputStream}(): what to do and not to do?

First question: should you catch IOExceptions thrown when you attempt to write to them? Provided that you don't, what is the default behaviour of servlet containers in this case (ie, what is the HTTP return code)?

The default error code for random exceptions thrown from a servlet is generally 503 (internal server error), but i don't think there's a requirement for that (i.e. different servlet containers may do different things). whether or not you should catch the exception and handle it yourself is entirely up to what behavior your servlet needs to have (maybe you have different error codes for different situations, maybe you want to proceed even if you can't read all the data, etc.).

Second question: should you let the servlet engine close the OUtputStream/Writer for you? Is there any danger in closing it yourself inside the servlet?

I believe most(all?) servlet engines will close the stream for you, however i would still say it's a best practice to close it yourself.

Does java automatic close response stream?

You get writer from response so normally you should not call close() while doing this. The servlet container will close for you.

If you pre-close your writer here, some feature will not work.

For example, your Filter may throw exceptions that IllegalStateException: the output stream has already been closed

---

Related Topics