I am trying to send a SOAP message to an NK SOAP service from an external SOAP client and am triggering an internal error:

<ex>   <id>Exception during request processing</id>   <message>whilst waiting for result...</message>   <requestid>[SOURCE http://quasar:8080/asp/soap/wsn in urn:org:ten60:netkernel:fulcrum:frontend as com.ten60.netkernel.urii.IURAspect]</requestid>   <stack>     <level>com.ten60.netkernel.scheduler.RequestState.setException() line:126</level>     <level>com.ten60.netkernel.scheduler.Scheduler.receiveAsyncException() line:336</level>     <level>org.ten60.transport.http.bridge.HTTPBridgeAccessor.requestAsync() line:148</level>     <level>com.ten60.netkernel.scheduler.Scheduler.stateRequestRepresentation() line:429</level>   </stack>   <ex>     <id>com.ten60.netkernel.util.NetKernelException</id>     <message>Problem with source in HTTPBridge</message>     <stack>       <level>org.ten60.transport.http.bridge.HTTPBridgeAccessor.requestAsync() line:144</level>       <level>com.ten60.netkernel.scheduler.Scheduler.stateRequestRepresentation() line:429</level>       <level>com.ten60.netkernel.scheduler.Scheduler.processRequest() line:251</level>       <level>com.ten60.netkernel.scheduler.Scheduler.processRequest() line:227</level>     </stack>     <ex>       <id>java.lang.StringIndexOutOfBoundsException</id>       <message>String index out of range: -2</message>       <stack>         <level>java.lang.String.substring() line:1768</level>         <level>org.ten60.transport.http.bridge.HTTPBridgeAccessor.SOAPMode() line:670</level>         <level>org.ten60.transport.http.bridge.HTTPBridgeAccessor.source() line:194</level>         <level>org.ten60.transport.http.bridge.HTTPBridgeAccessor.requestAsync() line:140</level>       </stack>     </ex>   </ex> </ex>

Looking at the source code in HTTPBridgeAccessor.SOAPMode, I can see that I must have a SOAPAction HTTP Request header which is not null, but is a very short string (line 670, where the error occurs, needs to be a bit more defensive in its checks).

My question is: What can I do to be able to see the HTTP Request headers as they come into the HTTPBridge?
   regards,
   -tom

Tom,

Peter and Tony are away from the office right now, so I'll try to answer the question. This is out of my area of expertise, but you might be able to use the debugger to look at this.

Set up the debugger for the fulcrum module and set the URI pattern to trap the request. (Don't forget to increase the timeout value). Once you capture the request, the tool is pretty good at letting you drill into the various elements (passed values, etc.).

If this does not help, please re-post and Peter will be able to provide a better answer.

Randy

Thanks for the idea Randy. According to the HttPBridge documentation, if I have the 'passHeaders' option enabled in the zone, then each header will be mapped to an argument/value on the request URI. I'll try that.

Meanwhile, I discovered more information that makes me think that some NK code needs to be..er.."enhanced":

I found out that my tool requires me to explicitly enter the Action URI string (this was hidden from me by the fact that the tool I didn't write was called from an ANT script I didn't write). Unfortunately, the HTTPBridge code (in SOAPMode around line 670) still assumes that every Action URI will be enclosed in quotes and blindly strips off the first and last characters!

So, if I enclose my Action URI in a pair of dummy characters, like this:

Xurn:some:action:uri:MyActionX

they get stripped instead and the service works!

This has come up before though I just can't find where. It seems that the spec (for soap 1.1):
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528
states that the soap action must contain quotes. Yet some implementations seem to break the rules.

Probably NetKernel should be more tolerant?

It would be good to be more tolerant of the errant implementations,
especially since I was using an ANT task built on top of an Apache library.

It looked like it would be very easy to just do an extra check or two in the NK code at the point where it blew up.

Your right Tom, now this has been identified as a common deviation from the spec we should make this more tolerant. Please can you raise a bugxter report. Cheers.