You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Eric Butler <Er...@mdintouch.com> on 2005/03/22 19:39:55 UTC
Trying to disable Coyote gzip compression only when there is a server
response status code of 500...
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.
-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.
Anyone have any ideas?
Thanks in advance.
--
------------------------------------------------------
Eric Butler
VP Product Development & Founder
MDinTouch
786.268.1161 X20
http://www.mdintouch.com
ericb@mdintouch.com
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Trying to disable Coyote gzip compression only when there is
a server response status code of 500...
Posted by Eric Butler <Er...@mdintouch.com>.
see inline comments regarding HttpServletResponseWrapper
Remy Maucherat wrote:
>On Tue, 22 Mar 2005 13:39:55 -0500, Eric Butler <Er...@mdintouch.com> 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
ericb@mdintouch.com
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Trying to disable Coyote gzip compression only when there is a server response status code of 500...
Posted by Remy Maucherat <re...@gmail.com>.
On Tue, 22 Mar 2005 13:39:55 -0500, Eric Butler <Er...@mdintouch.com> 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.
> -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.
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org