Java: Is there a way of changing the received HTTP Response headers?

I'm using a JAX-WS generated client (using wsimport, the one bundled with Glassfish 2.1.1) to connect to a ASP.NET generated WebService running in a IIS 6.

When I request compression in the response (by including HTTP Header Accept-Encoding: gzip through JAX-WS SOAP Handlers) the IIS 6 answers with a compressed response, but doesn't includes the Content-Encoding: gzip HTTP response header, so i get the following Exception:

com.sun.xml.ws.protocol.soap.MessageCreationException: Couldn't create SOAP message due to exception: XML reader error: com.sun.xml.stream.XMLStreamException2: ParseError at [row,col]:[1,1]
Message: Content is not allowed in prolog.
at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:361) at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:173)
at com.sun.xml.xwss.XWSSClientPipe.process(XWSSClientPipe.java:160)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.client.Stub.process(Stub.java:248)
at com.sun.xml.ws.client.sei.SEIStu开发者_开发知识库b.doProcess(SEIStub.java:135)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)

Edited Apr 17, 2011

I've also tried, using the same SOAPHandler I use for requesting compressed response, to modify the Response Headers, but the Exception occurs before the Handler is called.

End Edit Apr 17, 2011

Also, when I make the same request to the WebService through soapUI 3.6.1 with the Preference "Accept compressed responses from hosts", I can see what I've said: the IIS 6 server is not including the HTTP Response Header for compression, and soapUI shows the response as "binary data" and shows these response headers:

HTTP/1.1 200 OK
Date: Wed, 13 Apr 2011 08:50:55 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 1104

If -with soapUI- I don't request compressed response I get the next response size:

Content-Length: 2665

So, the question here is, as I've said, that IIS6 is not adding the Contend-Encoding header in the response. My question is: Is it possible to -programmatically- add the Content-Encoding header? Or, it also could be: Is it possible to ask IIS6 to include the Content-Encoding header?

UPDATE

Using Charles Web Debugging Proxy 3.5.2 I've confirmed the response from IIS6 doesn't include the Content-Encoding header:

HTTP/1.1 200 OK
Date    Wed, 13 Apr 2011 10:51:53 GMT
Server  Microsoft-IIS/6.0
X-Powered-By    ASP.NET
X-AspNet-Version    2.0.50727
Cache-Control   private, max-age=0
Content-Type    text/xml; charset=utf-8
Content-Length  1110

I'm guessing this may be an issue more related to the WebService than to IIS 6

Basically you need two components. First you must create a filter and add it in web.xml as this:

<filter>
  <filter-name>yourFilter</filter-name>
  <filter-class>yourFilterClassWhichAddsTheCorrectHeader</filter-class>
</filter>
<filter-mapping>
  <filter-name>yourFilter</filter-name>
  <url-pattern>theServletUrlMappedToJaxWS</url-pattern>
</filter-mapping>

Next you might need to create a wrapper of the response where you add the missing header.

Actually you might get not need the wrapper at all, just set the missing header directly in the filter you configured in web.xml

Hope this helps...

JAX-WS-specific workaround is to try and place a handler into input chain of the client. The handler would access the servlet context, get the request object, look at the payload and if it starts with GZ-specific sequence, add the HTTP header to the list of existing ones.

Downsides: may not work. I expect the list of HTTP headers to be an immutable collection. Besides, the parsing of content (and the failure) may happen earlier than first handler will get the control.

(I had another suggestion here -- to use an HTTP Filter -- but then I realized JAX-WS is a client, and doesn't use web.xml).

have you tried adding

Accept-Encoding: gzip,deflate

to request header?

is it associated to this bug? (eventhough ur not using IE, may be helpful)

Internet Explorer Loses the First 2048 Bytes of Data That Are Sent Back by Web Servers That Use HTTP Compression

I am not too sure how you're client handles the response. However if you can intercept the HttpResponse programmaticaly, you could try something similar to using a servlet filter to wrap the HttpResponse and augment the headers.

public class HttpReponseWrapper extends HttpReponse 
{
   HttpResponse reponse;
   public HttpResponseWrapper(HttpResponse response)
   {
     this.response = response;
   }

   public String getContentEncoding()
  {
      return "Content-Encoding=gzip";
  }
}