Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy is not validating against the correct response schema when using accept header for versioning #2509

Open
jarlah opened this issue Apr 8, 2024 · 3 comments

Comments

@jarlah
Copy link

jarlah commented Apr 8, 2024

Prism proxy is not validating against the correct response schema when using accept header for versioning

Context

I cant make versioned requests using accept header and expect the prism proxy to verify the correct response schema in the openapi file.

Current Behavior

It currently takes the first schema, for the first response listed under responses and validates the server response based on that.

Expected Behavior

It should read the content type from the response and select the proper response schema in the openapi path.

Possible Workaround/Solution

I dont have any good suggestions.

Steps to Reproduce

Use the following openapi spec

{
    ..... the rest of the spec .....
    
    "paths": {
        "/api/stuff/{stuffid}": {
            "get": {
                "tags": [
                    "stuff"
                ],
                "operationId": "getStuff",
                "summary": "Get stuff",
                "description": "Get some stuff",
                "parameters": [
                    {
                        "name": "stuffid",
                        "in": "path",
                        "description": "Stuff id",
                        "required": true,
                        "schema": {
                            "type": "string",
                            "example": "stuff id"
                        }
                    }
                ],
                "responses": {
                    "200": {
                        "description": "200",
                        "content": {
                            "application/vnd.stuff.v2+json": {
                                "schema": {
                                    "$ref": "#/components/schemas/StuffV2"
                                }
                            },
                            "application/vnd.stuff.v1+json": {
                                "schema": {
                                    "$ref": "#/components/schemas/StuffV1"
                                }
                            },
                            "application/json": {
                                "schema": {
                                    "$ref": "#/components/schemas/StuffV2"
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

run the proxy with errors enabled

prism proxy stuffapi.json http://stuffserver.com --errors

call the url

curl -v http://localhost:4010/api/stuff/fluffybear -H "Accept: application/vnd.stuff.v1+json"

if response returns v1 as it should, the proxy will test for v2 since its first on the list of responses.

I have verified this by actually reordering responses in the spec.

Environment

  • Version used: latest
  • Environment name and version (e.g. Chrome 39, node.js 5.4):
  • Operating System and version (desktop or mobile): prism cli on redhat
  • Link to your environment/workspace/project:
@jarlah
Copy link
Author

jarlah commented Apr 8, 2024

primary suspect is somewhere around here

export function findContentByMediaTypeOrFirst(specs: IMediaTypeContent[], mediaType: string) {

@daniel-white
Copy link

daniel-white commented Apr 12, 2024

we should also validate this on requests with the content-type header as well as in mock mode.

Copy link

This ticket has been labeled jira. A tracking ticket in Stoplight's Jira (STOP-458) has been created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants