Can the SOAP request SOAPAction be changed as a result of interoperability problems between .NET and JAVA or the network / subsystem proxy

I have a scenario where the .NET 3.5 WebClient executes a SOAP request and a SoapAction that is sent in the header, this

 <Host>:<Port>/NotOps/RFMP/portTypeEndPoint?SessionID=<token> 

But on the host side of SOAP REQUEST, which is JAVA, there are "/" that were received before "?" symbol

 <Host>:<Port>/NotOps/RFMP/portTypeEndPoint/?SessionID=<token> 

Is it possible for a network proxy to modify any part of the soap request? (by network proxy, I mean a proxy server that is used inside the business to access the Network on other networks)

Is there a compatibility issue between a .Net 3.5 client that uses a Java service such as those mentioned here.

.NET requires the SOAPAction HTTP header to be used to pinpoint the operation by which the service is called .. NETWORK requires the SOAPAction header format to be a namespace service, followed by a forward slash, followed by the name of the operation or urn: Example / sayHello. Note that SOAP :: Lite uses the pound sign (#) by default to separate the service namespace from the operation name. This was not a problem when we were invoking Java services using SOAP :: Lite, because Apache SOAP simply completely ignored the SOAPAction header.

This is referred to http://oreilly.com/catalog/progwebsoap/chapter/ch03.html Example 3-19

Any ideas on other things that might trigger this behavior?

In this case, the error associated with the optional forward slash was misleading, since the error was the result of a lack of permission at the endpoint

0
source share
2 answers

As you said, this behavior can be triggered by a proxy with some rewriting, but it would be very strange.

Try the test:

  • From calling the .NET code some layout (ideally on the same computer as your program) and check out SoapAction.

  • Call your Java code from SoapUI with the same request that you received from step 1. (again, ideally from the same machine)

Should he still add / earlier? this meant that the technology you used was changing that for you (my guess is the Java application server).

If / does not appear, you need to explore your network and find a magic proxy.

0
source

Beyond the answer provided by jakub.petr

The error associated with the optional slash was the result of a lack of resolution at the endpoint of the connection

Keep in mind that even detailed errors can mislead you to try to fix things that aren't broken.

So

0
source

Source: https://habr.com/ru/post/958314/


All Articles