Response is Committed would mean that response is sent for client to see it. It would be the same thing as saying buffer is flushed since response stores the output in its buffer. It also means that header and status in response can't be changed now.
Seems OK to me.
1.1: The reset method clears data in the buffer when the response is not committed. Headers and status codes set by the servlet prior to the reset call must be cleared as well.
This means that now response object is as new as it was before old buffer and header was put into it.
Ok again
1.2: The resetBuffer method clears content in the buffer if the response is not committed without clearing the headers and status code.
This means that now response object has no content to show to the client (if it was committed at this stage) but headers and status values are still there
This is clearly written in the API docs of resetBuffer method
API Docs wrote:Clears the content of the underlying buffer in the response without clearing headers or status code. If the response has been committed, this method throws an IllegalStateException.
1.3: If the response is committed and the reset or resetBuffer method is called, an IllegalStateException must be thrown.
Obviously so, since now buffer can't be cleared anymore nor can header and status values be changed. In fact now response object may not be available at all, after committing container frees resources so now response object is garbage collected.
If the response object is garbage collected, then it means that there is no references left on it. Then how can you call reset or resetBuffer on an object for which you don't have any reference. You are taking it more complicatedly. Its just that after committing the response, the client browser may have rendered the content so you can't change it now.
1.4: The response and its associated buffer will be unchanged.
I didn't understand the meaning of this. What is the significance of "unchanged" here. Does it mean any changes will be henceforth ignored ??
Well its simple, if you call reset or resetBuffer and the response has already been committed, then you'll get an IllegalStateException. But neither the response nor the response buffer will be changed. So you can catch that exception and continue with what you were last doing (this is impractical as you would reset buffer or response only to do something else
).
1.5: When using a buffer, the container must immediately flush the contents of a filled buffer to the client. If this is the first data is sent to the client, the response is considered to be committed.
If no response has been sent to client till now, commit the response (send it to client and flush the buffer). Else simply flush the buffer. Now if the buffer is empty can we still write content to the buffer or an attempt to do so will throw IllegalStateException ???
Well I didn't understand it properly but just to make it clear, if you reset the buffer, then you can add content to the buffer after that.
2) Now when we do RequestDespatcher.forward(), I got the impression from one of the threads here, that response is committed so headers are stone cast now and CAN'T be changed. So does it mean that if I attempt to add/set header I will get IllegalStateException or the header changes will simply be ignored??
As far as I know, if any response is sent, then doing a forward will result in a IllegalStateException.
Similarly can the buffer still be manipulated and it wudn't be visible to the client since response has been committed???
I didn't understand this statement
3) Source: Servlet Spec 2.4 SRV.5.3
Similarly in case of sendRedirect() and sendError(). sendRedirect() will clear buffer, forward it to the mentioned resource and then commit the response. Method sendError() will clear the buffer and set error codes and message in the buffer and then commit the response.
So both of these cases any subsequent changes in buffer and header will cause IllegalStateException or will the changes be simply ignored ???
Any further change to the response or buffer will result in an IllegalStateException...