Search code examples
jakarta-eejax-wscontent-type

SOAP unsupported media exception text/plain Supported ones are: [text/xml]

In our app we have the following line of code which makes a SOAP request to a service

@WebResult(
      name = "GetRequestResponse",
      targetNamespace = "urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1",
      partName = "parameters"
   )
   GetRequestResponse getRequest(@WebParam(name = "GetRequestRequest",targetNamespace = "urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1",partName = "parameters") GetRequestRequest var1) throws InvalidContentException, SMEVFailureException, SenderIsNotRegisteredException, SignatureVerificationFaultException, UnknownMessageTypeException;

It used to work until the service changed its response content type from text/xml to text/plain

It still returns valid XML but just in text/plain

I don't want to drastically modify the code since it's a very old and outdated legacy library used speciafically to make requests to the service (also, I am not sure whether there's something which could replace it)

To summarize we get the following exception:

ru.voskhod.smev.message_exchange_service_client.WebServiceClientException: com.sun.xml.internal.ws.server.UnsupportedMediaException: Unsupported Content-Type: text/plain;charset=utf-8 Supported ones are: [text/xml]
  at ru.voskhod.smev.message_exchange_service_client.MessageExchangeEndpoint.getRequest(MessageExchangeEndpoint.java:457)

Is there a way to make it accept text/plain and treat it just like text/xml?

Solution

  • You can use an intermediate reverse proxy (e.g. locally where the client runs) that overwrites text/xml with text/plain on the Content-Type response header, and then talk to that proxy instead of talking to the server.

    e.g. you can use httpd with with ProxyPass/ProxyPassReverse directives (from mod_proxy module) combined with Header set Content-Type "text/plain" (from mod_headers module).

    If the client cannot be configured to call a new domain(e.g. localhost), you may need to add a hosts file entry to resolve the remote server's domain to the reverse proxy's bind address. But the reverse proxy will still need to be able to dns-resolve the original address of the remote server, so for this to work at least one of the two(the client or the reverse proxy) may need to be containerized.