recent commit 40894382fc9fe959f3beacd20cfd6421eaf840b0 already improved
that method: before that other commit it was juste impossible to query
a endpoint with a response type that was something else than
application/json or application/xml. With that commit it became possible
to query such endpoint provided that the client declare in its Accept
header that it can cope with */* (or provided that the client omitted
that header altogether).
But there were still cases badly handled. For instance if an endpoint
returns a response of type image/png and that it receives a query with
header "Accept: image/png", then it would reply with 406.
To avoid any other issue with type resolution, this commit revamps the
getOutputFormat function more thoroughly and does it by implementing
the specification available at
https://httpwg.org/specs/rfc9110.html#field.accept ), which means that
the format accepted by the client are ordered by the relative weights
specified it specified.
PR #21261 added support for endpoint with response of type text/plain
or even image/png.
This commit adds such endpoint so that:
- the way those are supported is clearer (as it is now directly visible
in the generated sample files)
- if a future commit impacts this part of the generation it will be easier
to assess that impact
* [php-symfony] Never return 406 when user accepts */*
When a query has header "Accept" set to "*/*" it means it accepts
everything. It is hence weird to return a 406.
This patch ensures it does not occur: when the query accepts everything
then we take any produced type.
This fixes#13334. This also partly makes the open PR #15560 obsolete
(or at least, it provides a workaround)
* [php-symfony] Don't crash at runtime on null convertFormat
$this->convertFormat may return "null". When it's the case we end up
calling
...->serialize($data, null);
but this crashes at runtime because that serialize method declares that
the 2nd parameter is of type "string" (so null is not accepted).
With this patch we avoid having an error 500. Instead we return something
that makes perfect sense when the OpenApi specification declares a content
of type "text/plain" and that the returned value is for instance a string,
an int, or a boolean.
* [php Symfony] fix return type for non json/xml api
This fixes the generated returned type of controller methods for
endpoint with a response declared like
content:
text/plain:
schema:
type: <boolean|string|integer|number>
or for
content:
image/png:
schema:
type: string
format: binary
Without this commit the generated method *had to* return a value that
matched "array|object|null", which does not work in this case.
This commit makes it possible to return the proper type.
Bump requirements
- add Symfony 7 support
- remove support php < 8.2 (EOL)
- remove symfony < 6.4 support
Bug Fix
- add missing $security{{name}} variable when using Bearer Auth
Misc
- getContentType method is deprecated; use getContentTypeFormat
- use match instead of switch for simple assignments
- remove default depth param from json_encode call
- make data provider static (phpunit)
This fixes#15043
The issue is that browsers like "text/html,...,*/*;q=0.8" (see for
instance https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values
)
Without this commit we end up with an array of accepted type like
`("text/html", "*/*;q=0.8)` so when we then check if the array contains
`*/*` the check fails, and we return a 406 even though the client is
able to get the response.
This commit fixes it by removing the `;q=0.8` part.
(Ideally we should not just discard that part, we should extract that
value, and order by it. See
https://developer.mozilla.org/en-US/docs/Glossary/Quality_values for
more info about that. However this could be done in a subsequent PR:
this already fixes the 406 error, which is pretty blocking)
* Set PHP 7.1.3 required version
I've tried to specify ^7.0 version at first, but main package which is
symfony/framework-bundle@v4.4.8 requires PHP ^7.1.3.
* Bump Symfony FrameworkBundle to ^4.4.8
Current Symfony Framework stable version is v5.0.8, but I guess it
requires significant codebase upgrade, so I've sticked with 4.4.8 which
shouldn't cause any breaking changes. Old requirement was ^3.3|^4.1
which compatible with 4.4.8.
* Bump PHPUnit version to ^7.0
PHPUnit 8.x version required PHP ^7.2, so I'm setting 7.x version to
support PHP 7.1.
There is new way to specify Kernel class, related PR:
https://github.com/symfony/symfony/pull/22668
* Bump PHP CS Fixer version to ^2.16.3
Configuration and all renamed rules fixed.
Config file renamed to .php_cs.dist as recommended in migration guide.
Migration guide from 1.x to 2.x:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/UPGRADE.md#config-file
* Remove PHP_CodeSniffer package
Second linter doesn't make sense. I think Symfony user would prefer
PHP CS Fixer over PHP_CodeSniffer because first one maintained by Symfony
members.
* Remove satooshi/php-coveralls package from Composer
This package is abandoned and Coveralls recommends to install it directly
in Travis-CI task script.
* Update Travic-CI config
I've changed test versions to PHP 7.1.3 and 7.2. PHPUnit generates
coverage report in report/logs/clover.xml file. Then PHP CS Fixer runs
with --dry-run option to not override anything just to show coding style
errors.
* Add basic Coveralls config
This is basic recommended config for a PHP based project.
* Add symfony/yaml package
This package was part of satooshi/php-coveralls, now it should be
defined as dev dependency.
* Do not commit composer.lock
I think committed composer.lock can cause CI errors while tests on fresh
installs are better.
* Remove confusing Ruby comment
* Fix problem with clients, that put charset in content type header.
With this fix header "Content-Type: application/json; charset=utf-8" working same as "Content-Type: application/json" for parse input data
* Fix code style, add $consumes length check.
* Add isContentTypeAllowed static method and tests
* Fix old tests
Right now serializer doesn't support anything beside json and xml.
Call tests with application/json instead of form data.
Co-authored-by: Yuriy Belenko <yura-bely@mail.ru>
* Removed commented code
* Input validation is now supported as strict JSON validation
* [PHP][Symfony] Improve the implementation
Closes#6614
* Generated code is tested to assure it compiles and updated README to dynamically load dependencies via composer
* Updated shell script because shippable tests were failing
