I don't see why the class itself is burdened with reading a system parameter and parsing an interger stack size out of it. Put that code somewhere else, and pass the int value in as a constructor parameter. This will let you test the class behaviour for different values of the stack size, which is needlessly hard at the moment.
I'm a bit worried by the isClosed stuff. All that seems to happen if the stack is "closed" is that some operations throw a generic IOException. I can't see that this is especially useful behaviour from the perspecive of the client code. If the client code gets one of those exceptions, what should it do then? I assume it is there because client code is "not supposed" to call "put" or "flush" when it's not appropriate. Why not move this open/close/prevent behaviour and its flag outside to a "gatekeeper" or "decorator" class which you can choose to use or not.
<!-- What follows is the handling of the HTTP-errors -->
<!-- Curently defined errors are -->
<!-- 400 : Bad Request -->
<!-- 401 : Unauthorized -->
<!-- 402 : Payment Required -->
<!-- 403 : Forbidden -->
<!-- 404 : Not Found -->
<!-- 405 : Method Not Allowed -->
<!-- 406 : Not Acceptable -->
<!-- 407 : Proxy Authentication Required -->
<!-- 408 : Request Timeout -->
<!-- 409 : Conflict -->
<!-- 410 : Gone -->
<!-- 411 : Length Required -->
<!-- 412 : Precondition Failed -->
<!-- 413 : Request Entity Too Large -->
<!-- 414 : Request-URI Too Long -->
<!-- 415 : Unsupported Media Type -->
<!-- 416 : Requested Range Not Satisfiable -->
<!-- 417 : Expectation Failed -->
<error-page>
<error-code>401</error-code>
<location>error/Unauthorized.jsp</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>error/Forbidden.jsp</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>error/NotFound.jsp</location>
</error-page>
...