"Unable to resolve the reference" error on http $ref URL with non-standard port

[vnalla]

I have a OpenAPI 3.0.0 compliant YAML spec files which work fine in Swagger Editor. KaiZen Eclipse (Oxygen) plugin is not able to resolve references. The files are served from tomcat server on the same machine where eclipse is running. Tried with draft 4 compliant JSON Schema file as well as YAML file.

Invalid Reference - Unable to resolve the reference
The value must be valid JSON Reference (for external references) or JSON Pointer (for local references), and must resolve to an object of expected type

thanks

[tedepstein]

@vnalla, I've been reviewing some existing issues, and doing some extensive testing.

With your first reference, I think there are likely two problems:

1. CreatAddress.yaml looks like a typo. Should be CreateAddress.yaml, I assume. The specific error message you're getting from KZOE -- "The value must be valid JSON Reference..." -- indicates that it is not able to resolve the reference as specified. Please double-check to make sure the specified URL is correct, and let us know if you're still getting the same error message...

2. Even if your path is correct, I expect that you'll see a different error message, saying "Invalid object reference, the referenced object is not of expected type."

This is due to a problem detailed in issue #439, which I have just logged. Apparently, KZOE's validation is too restrictive. It wants to find the referenced parameters, schemas, etc. in an OAS-standard path, i.e. a path that could contain an object of the expected type, in a valid OpenAPI document.

The schema you're referencing is in a file by itself. Presumably the schema is the root object in that file. A reference to an object at root level, or in any location that isn't a standard path for an OAS object of the expected type, will fail to resolve.

I am not 100% sure about the timeline, but I hope we'll be able to get this fixed quickly. In the meantime, one possible workaround is to create an OpenAPI 3.0 file with an empty paths object, put the reusable components in their designated place, and reference them there.

See the attached zip file for an example of a multi-file project with component files.

Multi-file Beamup (v3).zip

[vnalla]

The file path is correct, yes I had a typo in the file name and actual file has a typo in it as well. I corrected the spelling and path is correct, as I can access the file in the browser with the same URL. The error message same as before. I will try to modify the file as shown in the example let you know how it goes.

thanks!

[tedepstein]

@vnalla, if you're still seeing "Unable to resolve the reference," then I would not expect any reorganization of the target file to help. The KaiZen Editor is unable to retrieve the content from the specified URL, or possibly unable to parse that content as JSON or YAML.

Since you're running this on localhost, it could be an issue with the configuration of the webserver or the web page/resource. What are the content-type and content-disposition headers returned by a GET on that localhost URL? Could you try using curl or another HTTP utility to get these details, and post them here?

I understand that this worked in the Swagger-Editor, presumably running on a local webserver. It's possible that Swagger-Editor is more tolerant of certain variations in the HTTP response, but it's difficult to say without knowing more details.

You might also want to take a look at the Eclipse error log to see if there's more detail around the failure to resolve that URL.

[vnalla]

if it is non HTTP URL it works, but http does not work and there is no content-type header is included in the returned response The line 34 works but 35 fails

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"398-1525356401007"
< Last-Modified: Thu, 03 May 2018 14:06:41 GMT
< Content-Length: 398
< Date: Thu, 03 May 2018 14:35:27 GMT
< 
---
openapi: "3.0.0"
info:
  version: "2.0"
  title: Create Address Schema

paths: {}

components:
  schemas:
    CreateAddress:

Updated Tomcat conf/web.xml to return MIME type "application/json" for JSON file with "json" extension and "application/x-yaml"/"application/yaml" for "yaml" and "yml" extensions. It still shows the same error.

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"584-1525357101919"
< Last-Modified: Thu, 03 May 2018 14:18:21 GMT
< Content-Type: application/json
< Content-Length: 584
< Date: Thu, 03 May 2018 14:49:54 GMT
< 
{
  "openapi": "3.0.0",
  "info": {
    "version": "2.0",
    "title": "Create Address Schema"
  },
  "paths": {},
  "components": {
    "schemas": {
      "CreateAddress": {
        "type": "object",
        "properties": {
          "address": {
            "type": "string"
          },

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"398-1525356401007"
< Last-Modified: Thu, 03 May 2018 14:06:41 GMT
< Content-Type: application/x-yaml
< Content-Length: 398
< Date: Thu, 03 May 2018 14:46:41 GMT
< 
---
openapi: "3.0.0"
info:
  version: "2.0"
  title: Create Address Schema

paths: {}

components:
  schemas:
    CreateAddress:
      type: object
      properties:
        address:

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"398-1525356401007"
< Last-Modified: Thu, 03 May 2018 14:06:41 GMT
< Content-Type: application/yaml
< Content-Length: 398
< Date: Thu, 03 May 2018 14:53:11 GMT
< 
---
openapi: "3.0.0"
info:
  version: "2.0"
  title: Create Address Schema

paths: {}

components:
  schemas:
    CreateAddress:
      type: object
      properties:

thanks! KiaZenError.log RapZenError.log

[tedepstein]

@vnalla , thanks for the details. We are looking into this, and checking to see if we can reproduce the problem on our side. So far, we have a failing example that looks at least superficially like what you've reported. We'll dig deeper and try to see what's going on.

FYI, we have some HTTP/HTTPS reference examples that work fine, so whatever the problem is, it doesn't affect all HTTP references, only some. We will post back as soon as we have some findings to share...

[andylowry]

To reproduce:

1. Create v2 petstore example in API Studio

2. Start a local web server that serves files from that project's models directory

   • One way to do this is using a standard python2 installation. cd to the models folder, then run python -m SimpleHTTPServer and note the port used (usually 8000)

3. In KZOE, replace references to #/definitions/Error with http://localhost:8000/petstore.yaml#/definitions/Error

At this point you should see error markers on all the updated references, claiming that the references can't be resolved.

[tedepstein]

@vnalla , apparently the problem is the non-standard HTTP port used by your local webserver. Our reference resolver failed to pick this up. It's a simple fix on our end. (See PR #441)

We'll review, test, and get a build out as soon as we can, though it might have to wait until next week, worst case. Thank you for reporting the issue, and thanks for your patience in helping us troubleshoot.

[tedepstein]

@vnalla, FYI I just updated the title of this issue so it's more closely scoped to the actual problem we're fixing.

[andylowry]

@vnalla, The latest published version contains a fix for this issue. Please update from http://products.reprezen.com/swagedit/latest/ and let us know if it addresses your problem.

[vnalla]

@andylowry, Thanks for fixing it, it works now. Actually I am porting my Swagger 2.0 API in which I had JSON Schemas for Requests/Responses which are non-OAS references and did not work either, that is why I posted this issue for two reasons and thanks to @tedepstein for creating #439. Any idea when it will be fixed?

thanks!

[andylowry]

@vnalla We hope to have #439 fixed very shortly as well. Stay tuned...

In the meantime, I'll close this issue. Thanks.