Unable to load https wsdl

[SteveGregory]

When I try to create a new SOAP project and feed it a WSDL with an https URL (e.g. https://server/path/webservice?wsdl), the WSDL loads fine, but SoapUI tries to load related XSD files with the http protocol. The server hosting the web service does not allow http, thus I always get the following error and cannot create a SOAP Project:

Error loading WSDL
There was something wrong with the WSDL you are trying to import
Error loading [http://server/path/webservice?xsd=xsd0]: org.apache.xmlbeans.XmlException: org.apache.xmlbeans.XmlException: error: Unexpected end of file after null

I am using SoapUI 5.5.0. Please advise.

[richie]

Hey @SteveGregory,

Just asking some stupid questions to make sure i understand ok:

1. Youre attempting to create a new SOAP project via the .wsdl and its
2. The .wsdl does include schema references (its not mandatory)
3. The schema references are of the "import" type....i.e. the schemas arent embedded within the .wsdl itself
4. This is for a test environment, right? So editing the .wsdl is possible (if what you were doing was in "live" rather than a test environment, my suggestions wouldnt work)

If i understand correctly i think off the top of my head you have a couple of options relating to editing the .wsdl

1. Change the supported protocol from http to https so that the import uses https (im assuming you can do this although i dont know how to do this myself as ive never done it before)

OR

2. Download the .xsds you need and edit the .wsdl so that the schemas are embedded in .wsdl rather than leave them as using the import option (ive done this before....its not too diffcult, but its easy to make a mistake)

OR

3. Download the .xsds you need and edit the .wsdl so that the .xsd locations are in locations you define that are available via http (when i did this before i just stuck the .wsdls in a shared directory in dropbox).

Out of the 3 options ive mentioned above option 1 would be quickest/easiest, but ive no idea how to do it.
Option 2 is the most difficult, so i think id go for option 3 (which is pretty simple too), unless you know how to do option1

The above is the way id handle it....the other forum people might have some better options to try

Nice one!

Rich

[richie]

Hey @SteveGregory,

I did see this stackoverflow and someone has thr same issue...they want to change http to https for xsd imports (https://stackoverflow.com/questions/37940436/modify-php-soapclient-to-use-https-rather-than-http-for... ). HOWEVER, it describes what you need to do loosely but not actual step by step details im afraid

As i said before, i think getting copies of the schemas and repointing the import locations to some you control is the easiest option.

Nice one,

Rich

[SteveGregory]

1 I'm unsure what you meant by "and its", but I'm in SoapUI 5.5.0 and I click on the SOAP icon or do File / New Soap Project, and then enter the URL of the WSDL in the "Initial WSDL" field, and hit "OK".
2 Yes, the WSDL contains:
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://my.name.space/" version="1.0">
<xsd:include schemaLocation="mySchema.xsd"/>
</xsd:schema>
</types>
As you can see, it is a relative location (in the same folder as the wsdl) so I'm confused why it uses the server and path from the WSDL's URL but changes the protocol.
3 Not embedded, but "include" rather than "import".
4.1 I'm not sure what you mean about changing the "supported protocol". There is an entry that reads:
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
..but when I changed that to ../soap/https"/> it broke something in the flow and wouldn't build.
(My web service is running in IBM AppConnect.)
4.2 IBM AppConnect requires the schema be separate from the WSDL, so no can do.
4.3 I don't believe I have an unsecured server available, and having a schema file separate from the web service server, that would need to be kept synchronized with the schema file in the app if there are changes, would be added maintenance and risk.

Of those, the most promising path of exploration seems to be changing the binding transport to ..https and trying to get rid of the errors it causes elsewhere in the app, but do any of these further details give you any ideas?

Thanks.

[SteveGregory]

It appears their solution in stackoverflow involves pulling the files down locally. I could ask our clients to manually download the WSDL file and the XSD (or I could just provide these files to them in an e-mail) and then create their SoapUI test projects from the local copies, but of course it's preferable if
I could get the New SOAP Project From WSDL feature in SoapUI to behave as expected so clients can set up SoapUI projects, or get WSDL and schema updates in existing projects, on their own.

[richie]

Hey @SteveGregory 

Answers to. your prompts:

1.  it was a typo (difficult to type on my phone)

3. yeah sorry i wasn't clear - I just meant whether the schema content was actually embedded within your .wsdl or whether the schema content was saved in a separate .xsd

4.1 - what I meant by "supported protocol" was http or https.  From what you've said you need to hit the webservice using https - so this is what I meant by the supported protocol.  regarding changing <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> to <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/https"/>, yeah - that http is actually a folder in the path, so changing that isnt gonna work - but I understand why you give it a shot.  Unfortunately switching http to https sounds straightforward, but I dont think it's a case of just adding an 's' in a couple of places in the .wsdl.  When I originally read about this a while back I think you actually have to rebuild some part of your code to support accepting the https rather than http - hence the reason why I mentioned in my initial post that it sounds the easiest option, but I've got no idea how to do it.

4.2 - ok - so embedding the content rather than separate instances of the schemas is a non-starter

4.3 - so you've nowhere you could store the xsd yourself.  also I appreciate your comment about not wanting multiple tech/req sources to maintain, but sometimes that this consideration can be overridden by necessity, however if you've got nowhere you can save the thing that kinda settles that option then

I dont actually understand what you meant in your follow up post here -->

---

@SteveGregory wrote: I could ask our clients to manually download the WSDL file and the XSD (or I could just provide these files to them in an e-mail) and then create their SoapUI test projects from the local copies, but of course it's preferable if

I could get the New SOAP Project From WSDL feature in SoapUI to behave as expected so clients can set up SoapUI projects, or get WSDL and schema updates in existing projects, on their own.

---

It's a 3rd party webservice right.....I assumed that you would be testing a 3rd parties webservice - is that not right?  Why would your 'clients' be testing it?

Worst case - you dont actually need the .wsdl nor the .xsds - they just save you a little time, effort and headache - it's still straightforward to create a SOAP project without the .wsdl/xsd's - you just need to be provided the details of the webservice and payload and create the project, the APIs and the tests manually.

Cheers,

Rich

[SteveGregory · Accepted solution]

Sorry, Rich. I was trying to avoid unnecessary details so the problem was clear, but it seems I withheld too much.

My organization hosts many web services. Rather than having to e-mail the WSDLs and XSDs to those who want to build clients for these services, we enabled the "?wsdl" feature within those services so all folks need is the web service endpoint and then they can pull down the necessary information themselves; however, since the server enforces https, people reported they were unable to create SoapUI projects as I've described, so I tried it myself and confirmed the issue.

Once they have the XSD(s) (via e-mail or whatever), they are able to build their web service clients and they work fine. But while building these clients, it's common for people to use SoapUI for comprehension and troubleshooting. And SoapUI's New SOAP Project functionality can't create a new project based on a WSDL URL using the https protocol, as it tries to load the associated XSDs using the http protocol and fails. Perhaps this is just a SoapUI bug, but if there's a SoapUI setting that will get around it, or if there's some change I can make to the WSDLs that will make SoapUI behave, I'd like to know.

The particular web service I tested just has the 1 related XSD file, and as shown previously, the include location in the WSDL is just the XSD's filename, as the XSD and the WSDL are in the same folder, so there are no absolute URLs (with protocol, etc.) in the WSDL (other than all the namespaces, which don't count). That leads me to believe it might be a SoapUI bug, but if it is, my Google searches haven't found anyone else mentioning it.

[richie]

@AV 

I messaging you cos you're SmartBear and I didn't know what else to do.  I mistakenly hit the 'Solved' button and I need to undo the selection.  Could you assist please?

@SteveGregory 

no need to apologise - my brain is tiny so I need all the help I can get!

Total guess here, but I don't think it's a SoapUI issue - I think it's probably a SOAP/wsdl and I dont think there's a SoapUI setting to sort either, cos

1.  lots of people have had this issue with various tools/software types - not just SoapUI.

2.  from my reading if you need to change the protocol, it's not just a .wsdl edit, it appears you need to rebuild the webservice code to support that change

3.  I dont think it's a question of SoapUI not able to create a new project based on a wsdl available via https, I think it's a case of its trying to call the .xsd detail when loading the .wsdl, but the code and the .wsdl wasn't explicitly built considering https

Yep gotcha - I saw straight away it's using relative paths and the .xsd is in same location as .wsdl

in your current situation I dont think there's an easy way around it then - at least I've run out of ideas....sorry I couldn't be of more help!

Cheers,

Rich

[KarelHusa]

Hi @SteveGregory ,

can you please attach the WSDL and XSDs (of course simplified/anonymized if they contain any sensitive information)?

I doubt that SoapUI would replace https with http for the include statement.

Can you please check that the XSD which is included in the WSDL does not import/include another XSDs via http?

Best regards,

Karel

[SteveGregory]

In my (perhaps meager) understanding, the protocol is just a matter of endpoint and what the server allows.
Our dev boxes use http and don't support https while our Production environment requires https and doesn't support http.
The WSDL and XSD files are not modified between environments.
This likely works because all our paths in our WSDL and XSD files are relative.
Thanks for trying, @richie.  I really appreciate the effort.
The discussion at least made me think through some possibilities.