• Typically there should not be any difference between URL ending with "/" or not, but in this case, the service you used seems to matter if the "/" is used at the end. From Teiid side there is nothing we can predict and fix on our side. I will consider this as user error.
• I also do see they do not support "http" only "https". The service is simply redirecting to "http" to "https". Also user error, the user should know where the endpoint is. In the case supporting redirects from Designer, there is no good way to configure redirects. In the Server side, one needs to manually configure CXF to suppot redirects.
• The reason it may have worked in the past is, service may have accepted without https and redirects before, now it does not. That would explain why this worked.

If above are only reasons they I suggest closing this issue with no resolution.

There is also change between http and https. If I enter it to browser without 's' I can see 301 redirect in network console.

Missing a slash at end is a not same as redirect

So I tried to change url from :

http://services.odata.org/Northwind/Northwind.svc

to:

https://services.odata.org/Northwind/Northwind.svc/

and it works now.
So workaround exists, I am changing priority to Critical.

But there is still a question. The first option without redirects worked before. Why? And why is not working now? Should be working now? If not could be a mention about this in documentation or TD should show some warning window that user put there address with redirects.

> Teiid does not support redirects if there any

You have to explicitly configure CXF to follow redirects.

Do a curl on Metadata call and see what it is sending. Teiid does not support redirects if there any

But, I think the correct one should be "odata". It worked before, I cannot find right now what has changed.

@matus yes, it is successful with ws translator and fails with odata translator

For the same resource adapter, can you use the ws translator to just execute an invokeHttp for $metadata - perhaps you are not getting the response needed for odata. If you get a json response, the odata translator also includes the headers Accept=application/xml,application/atom+xml to indicate that it needs xml.

Just a note: From what I know from Mario Majernik, the test was passing up to this point. And it is setting the "odata" translator in the process, it's not leaving the default one "ws" in there.