views:

90

answers:

1

I have a .NET web service that returns XML, and I'd like to compress this before it is sent.

There's a couple of ways that I can do this, but I'd rather not have to do it in code.

Can I set up IIS to gzip all content returned by my WebService? It's not being called from a browser.

The other question is if this web service is being consumed by a Java client - will that affect anything?

I imagine that the client proxy will still need to decompress, but there shouldn't be any problem if I use gzip - that is a universal protocol, right?

+2  A: 

The standard way to do this kind of thing is to use gzip compression over HTTP since it's directly supported by the protocol. As long as your client supports that then you should be good to go.

If you are writing the client from scratch with more fundamental tools you may need to add handling for this yourself: a good example of this is shown here (python).

I would expect a lot of SOAP client libraries to have built-in support for this but you'll have to try yours to be sure: if they lean on a lower level HTTP library to do their work, in all likelihood it should Just Work.

jkp
This is what I would expect - but what happens at the client-side? Do they have to write code to explicitly unzip the request or would a generated SOAP proxy do this for them? e.g. according to this link they would need to write code - http://janetandkevin.com/blog/articles/189.aspx
Duncan
As I say, depends on the client: some clients will use a lower-level HTTP library that will read the headers and do the right thing. Others might not and in those cases you might need to do some extra legwork. At any rate, you can always make your server-side code look at the accept headers from the client to tell if it supports gzip or not.
jkp
See §14.3 Accept-Encoding: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
trashgod