Accept header too narray for external YAML references

Q	A
Bug or feature request?	Bug
Which Swagger/OpenAPI version?	3.0.0
Which Swagger-Editor version?	editor.swagger.io
How did you install Swagger-Editor?	using hosted version
Which broswer & version?	Firefox 56.0.2
Which operating system?	Windows 10

Demonstration API definition

paths:
  /superiors/{class}/{uid}:
    $ref: "http://staging.anamera.com/anamera_v2/schema/Path_Superiors.yaml"
# NOTE: the Editor itself must be running with a non-SSL URL to reference a non-SSL external URL.

Expected Behavior

Content of YAML document should be inserted.

Current Behavior

Error: “Could not resolve reference because of: Not Acceptable”

Possible Solution

According to https://swagger.io/specification/#format-11 “…a JSON object, which may be represented either in JSON or YAML format.” Consequently, the editor should create ACCEPT headers that will permit either JSON or YAML content types to be served - instead, the editor generates a highly restrictive Accept header: Origin: http://editor.swagger.io Accept-Language: en-US,en;q=0.5 Accept: application/json

The media type registration for “application/json” (https://datatracker.ietf.org/doc/draft-ietf-jsonbis-rfc7159bis/?include_text=1) is EXCLUSIVELY for JSON formatted content. It does NOT permit YAML content. Therefore, it’s self-evident, that the “Accept” header generated by the swagger.io editor would not permit serving YAML formatted content.

For proper function in compliance with the OpenAPI specifications, the editor should use an Accept header similar to this: Accept: application/json, application/x-yaml, text/vnd.yaml (a minimum both the commonly used custom type since is registered yet, as well as the VND type that was proposed in 2015), or more liberally: Accept: application/json, application/x-yaml, text/vnd.yaml, text/yaml, *.*;0.8

Context

At present the only way for a server to respond with YAML formatted data, is to either IGNORE the non-matching ACCEPT request header entirely (if that’s an option), or if a server is strict, one has to mislable YAML formatted data by storing it in a .json file type, so that it’s served with the factually incorrect (and non-compliant) “application/json” Content-Type response header.

[Amachua]

Hello, I reoppen this thread since we’re facing the same kind of issue that @ASchmidt1 had and I’m not sure to understand the reason that lead to this decision. Anyway, if I open a Pull Request with the change on the line you’ve suggested, would you validate it directly? 😃

[Amachua]

To quote you @webron (hope I do get this sentence correctly):

I’d argue that we should just send */* and let the server decide to return whatever it wants.

Since the location of this configuration has changed since the last update, I would simply update the file with the value */*instead of its current value application/json, application/yaml.

Like this every consumer of your product wouldn’t have to update their configuration to match this restrictive Accept header. Also you’ll be able to close this discussion and please the community (or, at least, @ASchmidt1 and myself 😉).

Finally, if you do accept this change for Swagger Editor, I’ve some people on my organization that also complains about this on Swagger Hub. If we do the update here, can you take the opportunity to also change the content negotiation behavior on your other tools? 😃