Hi,
When we use the soap passthrough wizard, edge automatically configures an Invalid Soap "RaiseFault" policy to check the content-type in the header
Condition is set to
<Condition>!(request.header.Content-Type ~~ "(text|application)\/(xml|([a-z]*\+xml))(;(\w)*=(\S*))?") and (request.verb != "GET")</Condition>
Is there a reason the condition does not allow space after the ;
(text|application)\/(xml|([a-z]*\+xml))(;(\w)*=(\S*))?
we see some applications sending the value with space
text/xml; charset=something
This is picked up by the proxy as InvalidSoap because the condition is not met.
Should it be with (\s)* after the ;
(text|application)\/(xml|([a-z]*\+xml))(;(\s)*(\w)*=(\S*))?
or are these application not following proper Content-Type standards?
Hi @Yasser Taeima, It is normal to have space in the Content type content after the semi column if you look at this https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type. I have tested the content-type both with and without the space and it works perfectly by default for me. The expression has indicated anything after "xml" is optional, so if you have space it will just ignore the last bit else it will evaluate with (;(\w)*=(\S*))
I don't think you ran the same test; that is not the behavior we are seeing
This RegExp
(text|application)\/(xml|([a-z]*\+xml))(;(\w)*=(\S*))?
will not match
text/xml; charset=something
causing InvalidSOAP to be triggered.
The above expression is only allowing
text/xml;charset=something
or
text/xml
but
text/xml; charset=something
gets rejected
Anyone else seeing the same behaviour?
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |