function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
VPVP 

Testing soap compression

I am trying to test my SF webservice api 7.0 calls that use soap compression using axis java 1.3. Can I use axis SOAPMonitor to sniff and pick up those http requests? My understanding is that SOAPMonitor has to be deployed on the web service side to monitor the soap traffic to/from that service - since in this case I do not have access to the salesforce webservice host, I presume I will not be able to use the SOAPmonitor here.

I tried tcpmon as well - it is able to intercept my request messages - I am not able to get the response back from the service. Not sure what is going wrong.

When I tried SOAP scope sniffer I get the following soap response:


ns1:UNKNOWN_EXCEPTION
UNKNOWN_EXCEPTION: content does not match Content-Encoding: gzip


UNKNOWN_EXCEPTION
content does not match Content-Encoding: gzip




Almost seems like soapscope sniffer is unzipping the messages before sending them on to salesforce - which should not be the case since I understand soapscope sniffer does not intercept and resend the message.

Any other way to verify soap compression?
SuperfellSuperfell
try YATT or TcpTrace (both on www.pocketsoap.com) which'll show you the raw tcp stream.

do you still get UNKNOWN_EXCEPTION: content does not match Content-Encoding: gzip when you send your request without any monitoring tool? if so, that indicates that you're claiming the request is gzipped, but its actually not.

Have you seen http://www.pocketsoap.com/weblog/2005/10/1565.html which describes how to enable the compression support that's now built into axis 1.3
VPVP


SimonF wrote:
try YATT or TcpTrace (both on www.pocketsoap.com) which'll show you the raw tcp stream.


Thanks - will try that.


do you still get UNKNOWN_EXCEPTION: content does not match Content-Encoding: gzip when you send your request without any monitoring tool? if so, that indicates that you're claiming the request is gzipped, but its actually not.

Have you seen http://www.pocketsoap.com/weblog/2005/10/1565.html which describes how to enable the compression support that's now built into axis 1.3




Yes I did refer to your blog - and in fact I believe that the soap compression is working, because I tried without monitor logging (tcpmon/soapscope), and api calls worked okay.

But I just wanted to do an explicit test and verify using some concrete indicator (maybe a reduced message size, or scrambled i.e. zipped msg) that the msgs were indeed getting compressed. In soapscope/tcpmon, I do see that the http header shows "Accept-Encoding=gzip,Content-Encoding=gzip" - is that a sufficient indicator of compression working?
SuperfellSuperfell
To confirm for sure, you'll need to switch to HTTP and sniff the packets (try YATT or Ethereal)
VPVP


SimonF wrote:
To confirm for sure, you'll need to switch to HTTP and sniff the packets (try YATT or Ethereal)




Even with YATT, I got same behavior as with tcpmon and soapscope sniffer
- without compression I can see all rqst-response msgs in the tool window
- when zipping using CommonsHTTPSender, I see only the first request, the response to that request never shows up

The http header in the zipped case shows HTTP 1.1 is used, transfer encoding=chunked and content encoding=gzip. The content encoding is probably enough to infer that compression is working. But are the problems with the tcp trace tools with zipped requests due to the chunking/zipping?
SuperfellSuperfell
in YATT turn on the "Shows NULLs" option (in the View menu)
VPVP
With "Show Nulls" on, I see some non-ascii chars in the message body (which I used to see with tcpmon/soapscope as well) - probably indicating the zipped content. But no response is still received to that message.
SuperfellSuperfell
No response is shown or no response is recieved ? (i.e. does the client think it got a response?)
VPVP


SimonF wrote:
No response is shown or no response is recieved ? (i.e. does the client think it got a response?)




No response is seen on the YATT/tcpmon/soapscope consoles. That in turn is because no response was received by the client - the client console has the following messages:

17:32:08,196 INFO [HttpMethodDirector] I/O exception caught when processing request: The server na1.salesforce.com failed to respond
17:32:08,196 INFO [HttpMethodDirector] Retrying request
17:33:13,696 INFO [HttpMethodDirector] I/O exception caught when processing request: The server na1.salesforce.com failed to respond
17:33:13,696 INFO [HttpMethodDirector] Retrying request
17:34:18,868 INFO [HttpMethodDirector] I/O exception caught when processing request: The server na1.salesforce.com failed to respond
17:34:18,868 INFO [HttpMethodDirector] Retrying request
17:35:24,400 ERROR org.apache.commons.httpclient.NoHttpResponseException: The server na1.salesforce.com failed to respond