[PHP] 6.0.x make php implementation depend on meta packages for http client
Instead of relying on Guzzle directly, depend on a psr/http-client-implementation (AKA PSR 18). This is a metapackage which implementations can declare they provide, all the major ones already do (including Guzzle, Symfony, etc).
Inspired by discussion: https://github.com/OpenAPITools/openapi-generator/issues/7518
PR checklist
- [ x ] Read the contribution guidelines.
- [ x ] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
- [ x ] Run the following to build the project and update samples:
Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH. - [ x ] File the PR against the correct branch:
master,5.1.x,6.0.x - [ x ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.
@jebentier (2017/07), @dkarlovi (2017/07), @mandrean (2017/08), @jfastnacht (2017/09), @ackintosh (2017/09) ❤️, @ybelenko (2018/07), @renepardon (2018/12)
Update from 2021-07-05 redirect problem was solved by upgrading php-http/client-common, PHP Unit tests are passing now
Some tests are failing and I figured out the reason, I don't have a solution for it yet.
http://petstore.swagger.io/v2 is a base url we are running tests against
any request to that host redirects to https://petstore.swagger.io/v2
The redirect plugin from here https://github.com/php-http/plugins/blob/master/src/RedirectPlugin.php#L197 when doing a redirect is updating method from POST to GET. In the end, the response to the second request is 405 Method not allowed.
I read a bit about that and to me it looks that probably RedirectPlugin should not change POST to GET, but that is a common implementation bug
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
As well seen at https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302
Even if the specification requires the method (and the body) not to be altered when the redirection is performed, not all user-agents conform here - you can still find this type of bugged software out there. It is therefore recommended to set the 302 code only as a response for GET or HEAD methods and to use 307 Temporary Redirect instead, as the method change is explicitly prohibited in that case.
I am not sure on how to solve that issue yet, I will get back to the PR after one week
Could you take a look again? The issue with redirect was fixed by using an updated php-http/client-common package. guzzlehttp/psr7 is now either ^1.8 or ^2.0 because the used classes are the same in both
I have seen that build was failing but could not really understand what exactly was wrong
@wing328 is the issue with Petstore tests fixed? I remember it's quite flaky.
Hi! Does this issue have some forecasts for release?
@dkarlovi @wing328 Are there any reasons for the merge delay?
it would be great to have this merged, let us know if help is needed
@olexiyk can you please resolve the merge conflicts when you've time?
UPDATE: I've filed https://github.com/OpenAPITools/openapi-generator/pull/16368 to add the implementation via the library option (e.g. --library psr-18 via CLI)
Included https://github.com/OpenAPITools/openapi-generator/pull/16368 in v7.0.0 release.