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

Accept-Header and Content-Type-Header in parameters of openapi.yaml are not allowed #625

Closed
3 tasks done
LWlook opened this issue Feb 23, 2023 · 4 comments
Closed
3 tasks done
Labels
bug Something isn't working

Comments

@LWlook
Copy link

LWlook commented Feb 23, 2023

  • Checked the docs
  • Looked for open & closed tickets
  • Googled for the issue

What happened?

  1. I just started an new laravel project and added fortify and scribe
  2. I generated the docs + the openapi specification
  3. Looked into the specification and saw following:
      parameters:
        - in: header
          name: Content-Type
          description: ''
          example: application/json
          schema:
            type: string
        - in: header
          name: Accept
          description: ''
          example: application/json
          schema:
            type: string
  1. Looked at the specification for openapi on swagger https://swagger.io/docs/specification/describing-parameters/#header-parameters and saw the sentence: Note: Header parameters named Accept, Content-Type and Authorization are not allowed.

Now my question (and probably the issue of the library): Is there a way to suppress these parameters in the openapi.yaml?

My environment:

  • PHP version (from php -v): 8.2.0
  • Framework (Laravel/Lumen): Laravel
  • Laravel/Lumen version (from composer show laravel/framework or composer show laravel/lumen-framework): 10.1.4
  • Scribe version (from composer show knuckleswtf/scribe): 4.16.0

My Scribe config (from php artisan scribe:config:diff): ------ SAME AS DEFAULT CONFIG ------

Additional infos:
Just to mention why this is a problem for me: I have to use swagger for displaying my documentation/api and with your library there are always two useless fields in the documentation in every request (as seen in the screenshot). And this two fields don't even do anything and are probably distracting from the real parameters.
image

@LWlook LWlook added the bug Something isn't working label Feb 23, 2023
@LWlook LWlook changed the title Accept-Header and Content-Type-Header in parameters of openapi.yaml Accept-Header and Content-Type-Header in parameters of openapi.yaml are not allowed Feb 23, 2023
@LWlook
Copy link
Author

LWlook commented Feb 24, 2023

Just as additional info: In the ruleset for openapi from IBM is the Accept-Header even the first rule in their ruleset.

https://github.com/IBM/openapi-validator/blob/main/docs/ibm-cloud-rules.md#accept-parameter

@shalvah
Copy link
Contributor

shalvah commented Feb 24, 2023

This seems like not a big deal. We just need to adjust the OpenApiSpecWriter to not include those headers. You can make a PR for that.

@LWlook
Copy link
Author

LWlook commented Feb 24, 2023

Yea, not that big of a deal. I will make probably a PR i the next few days.

Just another little question: I use the spatie/data package a lot, and so i'm not using the original form request class (but instead direct the data object). Is there a way to "register" these Dependency-Injected-Data-Classes with scribe, so the parameters are auto discovered in route methods?

PS: I really really like your package :)

@shalvah
Copy link
Contributor

shalvah commented Feb 24, 2023

I don't know much about that package, but it sounds like you can do that with a custom strategy.

@shalvah shalvah closed this as completed in 56d589a Apr 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants