Change in w3.org XML schema files locations to https means cannot compile ONVIF WSDL via Apache CXF

[zebity]

Issue

Many of the included XML Schema files used within ONVIF WSDL definition have moved from http to https locations.

The result is that when trying to compile into Java code using Apache CXF 3.x & 4.x there is redirection from http to https location which result in Apache Xerces XML Parser failing with "premature-end-file" error:

[WARNING] Exception in thread "main" org.apache.cxf.tools.common.ToolException: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsdl definition file:/META-INF/wsdl/www.onvif.org/ver10/device/wsdl/onvif_device.wsdl: WSDLException (at /wsdl:definitions/wsdl:import/wsdl:definitions/wsdl:types/xs:schema/xs:schema): faultCode=PARSER_ERROR: Problem parsing 'http://www.w3.org/2004/08/xop/include'.: org.xml.sax.SAXParseException: Premature end of file.

Workaround is to copy ONVIF and related schema files to disk and patch these to load from file system rather than directly from source.

Can ONVIF specification be updated to use https locations directly to avoid re-direct failures ?

There are two different failure scenarios:

1. Source uses http based redirect
2. Source is sending html file (rather than XML) with redirect directive

So need to review the various XML schema files and update to https for one that are no longer served as http

Diagnosis

To test source of error I created the following trivial Java program to parse the XML file: https://github.com/zebity/onvif-relay/blob/main/onvif-cxf-relay/src/test/java/test_xerces/TestXerces.java

When run with:

• http://www.w3.org/2004/08/xop/include == parse fails
• https://www.w3.org/2004/08/xop/include == parse ok

Other files with redirection issues include:

• "http://www.w3.org/2005/05/xmlmime" schemaLocation="http://www.w3.org/2005/05/xmlmime"
• "http://www.w3.org/2003/05/soap-envelope" schemaLocation="http://www.w3.org/2003/05/soap-envelope"
• "http://www.w3.org/2004/08/xop/include" schemaLocation="http://www.w3.org/2004/08/xop/include"

[steven93921]

I ran into a similar issue with gSOAP's wsdl2h being unable to follow the permanently removed/redirect response for these files when using OpenSSL 3.0. I was able to add an option to disable SSLv3 for wsdl2h to resolve the problem.

This seems to be an Apache CXF problem that should be addressed there.

[zebity]

Hi @steven93921 ,

I believe that the "root" cause is actually with www.w3.org in doing the re-direct from well known http to https, but is it a question of what the the "easiest" way to resolve out of:

1. www.w3.org - stop redirectly widely published http URIs to https
2. Apache CXF - add accommodation for redirects
3. Apache Xerces - add accommodation for redirects
4. ONVIF - change schema to use redirected URIs

I raised (4) here as I thought this is path of least resistence and should have no impact on any consumers, as schemaLocation directive already allow for clear separation of name space from URI (location).

Suspect that I will just need to raise issue across all 4 possible solutions and see how things pan out.

Right now I am having to workaround this by doing download/patch which make generation of Java code convoluted and fragile (as patching is prone to failure on change and doing a "sed" as alternate is potentially dangerous.

EDIT: Issue has already been raised on CXF (in 2022...) : https://issues.apache.org/jira/browse/CXF-8760?jql=text%20~%20%22www.w3.org%20redirect%22 , nothing happening quickly over there ;-)

[HansBusch]

Close as related PR has been approved