see inline comments regarding HttpServletResponseWrapper
Remy Maucherat wrote:
On Tue, 22 Mar 2005 13:39:55 -0500, Eric Butler <[EMAIL PROTECTED]> wrote:
First of all, thanks to all the developers and users that have
contributed to Tomcat. It's quite an amazing piece of software.
I'll start by telling you why I am trying to do this, what approaches I
have taken in my attempts to do it, and then I'll ask for some
suggestions on other approaches that may work better.
*Why*
We have an MS .Net (1.1) client talking SOAP over HTTP to Webservices
built on Sun's JWSDP 1.3 (via Tomcat). There is a pretty strict
requirement to compress responses as they are usually 200-1000KB. There
is a 'lack of feature' in the MS .Net Webservice client implementation
in that it is not possible to decompress the HTTP response when there is
a server response code of 500. The SOAP spec requires that SOAP Faults
on the server set the response code to 500, and thus we are unable to
process any SOAP faults on the client. In all other cases we are cool
in decompressing the responses. Since there don't exist any options for
us on the client we are limited to the server for solutions.
*Approaches attempted and failed*
-Servlet filters - a servlet filter only has access to the
HttpServletRequest and the HttpServletResponse and neither of these is
aware of the response status code.
Wrap the response object. A servlet like the compression filter has to
wrap anyway to be able to work.
I tried using the HttpServletResponseWrapper however there is no method
on this class to obtain the response status...only a method to set the
status. The core problem I have is that I have not been able to
determine where I can get the response status in order to know if I
should compress the response. The only place where the response status
is known is in the Http11Processor class. Can you think of a way to get
the response status from a filter?
-Coyote's compression option with a numerical value higher than all Soap
Fault sizes - it seems that the content-length of the response is always
set to -1, either by Sun's JWSDP or because the HTTP response is
chunked. I'm not sure which is the cause, but when the content-length
is -1, the response is always compressed.
-We tried an endless list of things on the .Net client in an attempt to
decompress the SOAP Fault responses to no avail.
*Approaches attempted and suceeded*
-Modifying org.apache.coyote.http11.Http11Processor.class by adding this
immediately inside of isCompressible()
if ( response.getStatus() == 500 ) {
return false;
}
I know this isn't pretty but it works. This will be acceptable if I
can't find a better option, but it will require that each time we
upgrade Tomcat, we'll need to compile a custom Http11Processor. I'll
also need to check that we aren't violating the Apache License.
It obviously does not violate the Apache license.
--
------------------------------------------------------
Eric Butler
VP Product Development & Founder
MDinTouch
786.268.1161 X20
http://www.mdintouch.com
[EMAIL PROTECTED]
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
