web.xml Reverse Proxy Filter=true has side effect of double gzipping GetCap, GML and CSV output in 2.1.1
--------------------------------------------------------------------------------------------------------
Key: GEOS-4756
URL: https://jira.codehaus.org/browse/GEOS-4756
Project: GeoServer
Issue Type: Bug
Components: WMS
Affects Versions: 2.1.1
Environment: Unix-Solaris, Apache2, Tomcat6, Java 1.6, Geoserver 2.1.1
Reporter: Andrew Walsh
Assignee: Andrea Aime
We recently installed Geoserver 2.1.1 from .war file on our
Tomcat. We run our Geoserver behind a reverse proxy setting
the PROXY_BASE_URL through the "global settings" web form and
switching on the 'Reverse Proxy Filter' to true in the
WEB-INF/web.xml. Apache 2.2 at the front end does a proxy to
our Tomcat/geoserver at the back end. We found that that this setup
worked fine with our previous Geoserver 2.0.1 but now we get
the following problems with 2.1.1:-
1) Output from the GetCapabilities requests to WMS 1.1.1 and WFS 1.1.0
produces binary garbage.
2) GML and CSV output for all layers produces binary garbage.
Other things like WMS getMap drawing and getFeatureInfo seem to be
working fine still as they were with 2.0.1
I note that when I set the Reverse Proxy Filter to 'false' the problems
with the GetCap. and GML/CSV XML output go away. So it was something
to do with the filter.
Andrea Aime noted that (thanks for the clue, Andrea!):
"PS: The caps binary issue seems to be related to an interaction
between proxy, servlet proxy and gzip compression filter,
as if I use curl without enabling gzip compression I get back
the caps document properly."
So I checked to see whether the binary output was gzipped and it
was. So the effect of the filtering is send back a double gzipped
file e.g getCap.xml.gz.gz. The browser then duly unzips this but you
still see binary garbage as its still gzipped.
I have verified this by saving the browser getCap output as file.gz and then
running gunzip to get back file and its then readable text/xml.
I further verified the above issue by running the following curl commands
As these run outside the browser a double gzipped file should
in theory come back:
curl -o wms.gz.gz -H "Accept-Encoding: gzip,deflate" -H "Accept: */*" "http://www.metoc.gov.au/geoserver/ows?service=wms&version=1.1.1&request=GetCapabilities"
This will save the file wms.gz.gz.
Then run gunzip on this twice giving you wms.gz and wms.
You will see that the output is OK text/xml.
I verified that the same thing is happening with WFS GML and WFS CSV
with these commands
curl -o gml.gz.gz -H "Accept-Encoding: gzip,deflate" "http://www.metoc.gov.au/geoserver/wms?service=WFS&version=1.0.0&request=GetFeature&typeName=ran:secchi&featureId=RAN.SECCHI.5976"
curl -o csv.gz.gz -H "Accept-Encoding: gzip,deflate" -H "Accept: */*" "http://www.metoc.gov.au/geoserver/wms?service=WFS&version=1.1.0&request=GetFeature&typeName=ran:secchi&featureId=RAN.SECCHI.5976&outputFormat=csv"
So fix is to stop this second gzip from running. Not sure which java program
fix should be applied but start looking near ReverseProxyFilter.java
and friends
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira