[BUG] curl code samples omit non-printable characters

[Chris Adams]

Checklist

• I checked the FAQ section of the documentation
• I looked for similar issues in the issue tracker
• I am using the latest version of Schemathesis

Describe the bug

I had a FastAPI endpoint which accidentally leaked the header definition for X-Forwarded-For into the OpenAPI docs and that caused a Schemathesis run to fail, emitting a curl sample like this:

    curl -X GET -H 'x-forwarded-for: 0' http://localhost:8000/search/latest-magazines

That worked without error when I tried to reproduce, but I knew it was failing based on my service's logs. I added --code-sample-style=python and the cause became clear:

requests.get('http://localhost:8000/search/latest-magazines', headers={'x-forwarded-for': '0\x1f'})

To Reproduce

1. Start a run against a service which will trigger an error on the presence of an unprintable character (in my case, the ASGI runner itself triggered the error so it wasn't something my application knows about when generating the OpenAPI docs but that's obviously not a prerequisite).

Please include a minimal API schema causing this issue:

{
    "openapi": "3.1.0",
    "paths": {
        "/search/latest-magazines": {
            "get": {
                "summary": "Get a list of the latest magazine issues",
                "operationId": "getLatestMagazines",
                "parameters": [
                    {
                        "name": "x-forwarded-for",
                        "in": "header",
                        "required": false,
                        "schema": {
                            "anyOf": [
                                {
                                    "type": "string"
                                },
                                {
                                    "type": "null"
                                }
                            ],
                            "title": "X-Forwarded-For"
                        }
                    }
                ],
                "responses": {
                    "200": {
                        "description": "Successful Response",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "$ref": "#/components/schemas/SearchResponse"
                                }
                            }
                        }
                    },
                    "422": {
                        "description": "Validation Error",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "$ref": "#/components/schemas/ValidationError"
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "components": {
        "schemas": {
            "SearchResponse": {},
            "ValidationError": {}
        }
    }
}

Expected behavior

Ideally the curl examples would either include the escaped values — but this introduces shell-specific behaviour since you'd need to use something like curl -H "X-Forwarded-For: $(printf '\01f')" … so it might be effective to simply alert the user with a text message that the curl sample is incomplete. In my case, the fact that it printed without a warning and with what appears to be a complete string was somewhat confusing

Environment

- OS: macOS
- Python version: 3.12
- Schemathesis version: 3.27.1
- Spec version: OpenAPI 3.1.0

[Dmitry Dygalo]

Thank you for reporting!
indeed, I think that for now the best course of actions would be to warn the user. This is somewhat unfortunate that properly solving the issue would introduce shell-dependent code :( not sure if it could be worked around with some built-in curl feature

[Chris Adams]

Thank you for reporting! indeed, I think that for now the best course of actions would be to warn the user. This is somewhat unfortunate that properly solving the issue would introduce shell-dependent code :( not sure if it could be worked around with some built-in curl feature

Thinking about it a bit more, maybe just do something as simple as displaying a warning along the lines of “This test involves characters which are difficult to portably represent in shell commands. Here's the Python version:” and override the code sample language? I'd assume that most people using this tool wouldn't be terribly surprised by that and it's something of an edge case so it makes sense to switch to the alternative you already have.

[Dmitry Dygalo]

I like the idea and wording that you proposed! An alternative I was thinking about is showing the cURL command without headers that contain such characters and then displaying headers separately in the warning message, but probably it would not be as useful.

Got to research if it could be possible to detect the shell and display the headers properly.