Update request content type

[tsuni_ohsaki]

The client to our Apigee proxy is base on .NET and Web Reference needs to be added from Visual Studio. And it appears Visual Studio makes a request with Content-Type set to "application/soap+xml; charset=utf-8" and Apigee is refusing it. When our backend accessed directly, we see no issues. 

Assuming the assumption above is correct, how can I change the request content type without altering anything else (such as payload, url...) from "application/soap+xml; charset=utf-8" to "text/xml; charset=utf-8" by using Apigee policy.

It would be great if you can provide me an example. Thanks!

[dchiesa1]

VS makes a request with Content-Type set to "application/soap+xml; charset=utf-8" and Apigee is refusing it.

OK. I don't think Apigee by default "refuses" requests with that content-type, but I may be wrong. What I think is probably happening is, your API Proxy is refusing the request with that content-type. Is that possible?

And what specifically do you mean by "refusing it"? What observations have you made that lead you to this conclusion? What is the specific error message you see from Apigee? Do you have a Conditional policy in the proxy that raises a fault if the content-type is not a specific value?

how can I change the request content type without altering anything else (such as payload, url...) from "application/soap+xml; charset=utf-8" to "text/xml; charset=utf-8" by using Apigee policy.

You can make a change in your API Proxy to forcibly set the request content-type, using the AssignMessage header. This is one of its key use-cases. Setting headers. Check the documentation for details. A sample might be

<AssignMessage name='AM-Force-Content-Type'>
  <Set> 
    <Headers>
      <Header name='content-type'>text/xml; charset=utf-8</Header>
    </Headers>
  </Set> 
</AssignMessage>

But if your original description is accurate - "Apigee is refusing it" - then it will do no good to change the header on the message within the Apigee proxy. An AssignMessage policy would execute only after your API proxy has accepted the inbound message.

[tsuni_ohsaki]

The error message I presented initially was from Web Reference creation in VS. We somehow got around it and tried making a SOAP call from client app in VisualStudio, which target our Apigee proxy. Now we don't get Content-Type error, but still get this error:  

System.InvalidOperationException
  HResult=0x80131509
  Message=Response is not well-formed XML.
  Source=System.Web.Services
  StackTrace:
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at ServiceTesting.net.apigee.kareo.partner.KareoServices.GetPractices(GetPracticesReq request) in Y:\repo\platform-event-logger\Source\ServiceTesting\Web References\net.apigee.kareo.partner\Reference.cs:line 818
   at ServiceTesting.Program.Main(String[] args) in Y:\repo\platform-event-logger\Source\ServiceTesting\Program.cs:line 51
  This exception was originally thrown at this call stack:
    System.Xml.XmlTextReaderImpl.Throw(System.Exception)
    System.Xml.XmlTextReaderImpl.Throw(string, string[])
    System.Xml.XmlTextReaderImpl.ThrowInvalidChar(char[], int, int)
    System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
    System.Xml.XmlTextReaderImpl.ParseDocumentContent()
    System.Xml.XmlTextReaderImpl.Read()
    System.Xml.XmlTextReader.Read()
    System.Xml.XmlReader.MoveToContent()
    System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(System.Web.Services.Protocols.SoapClientMessage, System.Net.WebResponse, System.IO.Stream, bool)
    System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(string, object[])
Inner Exception 1:
XmlException: '', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.

The last line indicate VisualStudio complains about Unit Separator which is not a valid character in XML 1.0 (https://stackoverflow.com/questions/6693153/what-is-character-0x1f). So we suspect VisualStudio is based on XML 1.0 parser. We want to try replacing 0x1f with 0x09 (tab) as mentioned in stackoverflow answer in the topic shown above.  

How can this be achieved in Apigee proxy?

[dchiesa1 · Accepted solution]

Since I already provided an irrelevant response to you, based on my guesses in the absence of complete information in the original question, before I proceed to engage on your second question, I'd like to verify that my answer will actually be helpful.  I want more information. Can you tell me the ACTUAL payload that VS gets in response?  Not the error message VS shows you.  The actual payload. 

What is it? Can you show it here?  I would like to see the payload as well as the content-type.  Do you have that?  Can you find it?  Within Apigee Trace you should be able to see these things. 

Also, What thing or system is generating the response that includes the 0x1f character?

I would like to help, and I don't have high confidence that replacing 0x1f with a slash (as suggested in the SO answer) will be helpful.  It may be helpful.  But let's get more information first, eh? 

[tsuni_ohsaki]

Thanks for the reply. Since the trace include some proprietary information, I decided to contact Apigee customer support. 

[tsuni_ohsaki]

The cause was this policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="FixEncoding">
    <DisplayName>Fix Encoding</DisplayName>
    <Properties/>
    <Set>
        <Headers>
            <Header name="Accept-Encoding">gzip,deflate</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

We added it as a remedy for the problem: Apigee produce an error when a client set Accept-Encoding to 'gzip, deflate, br" in the request header such as a Postman request with the default settings. VisualStudio's Web Reference client did not like it. We added a condition so that the above policy does not get executed if Accept-Encoding is not set (VisualStudio' does not setAccept-Encoding).

Now the problem is solved.

[dchiesa1]

Nice. I'm glad you sorted it. 

I think the product team is working on including support for brotli.  No timeline for that feature. But it's a known issue.