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

WIP: Support Filters Being Bound to Different Stages of Processing #171

Closed

Conversation

GuyPaddock
Copy link

@GuyPaddock GuyPaddock commented Aug 21, 2019

Makes it possible for a filter definition to include a new stage key that can be set to before_validation, after_validation, request_wire, or response_wire; which binds the filter to fire off either before validation (the default), after validation, before being written to the wire in a request, or after being read from the wire from a response, respectively.

Still needs tests.

Depends on #167, closes #169, and closes #134.

Guy Elsmore-Paddock added 2 commits August 12, 2019 22:20
…atibility

PSR-7 requires a method to be set on Request objects at the time they
are created, but the Operation object previously defaulted the method to
an empty string. Now we default it to 'GET', which should be a safe
choice.

In addition, if a request is misconfigured to force the request method
to an empty string, there is now a validation for that.

Closes guzzle#166.
…ssing

Makes it possible for a filter definition to include a new `stage` key
that can be set to `before_validation`, `after_validation`,
`request_wire`, or `response_wire`; which binds the filter to fire off
either before validation (the default), after validation, before being
written to the wire in a request, or after being read from the wire from
a response, respectively.

Still needs tests.
@GuyPaddock GuyPaddock force-pushed the feature/post-validation-filtering branch from 43abdaf to 8576ba1 Compare August 21, 2019 05:50
- Cleans-up logic that was working around `$this->filters` being empty.
- Fixes method visibility for `expandFilterArgs()`.
if (isset($filter['stage'])) {
$filterStage = $filter['stage'];
} else {
$filterStage = self::FILTER_STAGE_AFTER_VALIDATION;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This default is fine for filters on request payloads/parameters, but wrong for filters on response values. For responses, the default filter stage should be FILTER_STAGE_RESPONSE_WIRE if not specified.

When a simple filter is used, the logic is correct because the filter is invoked for all stages of processing except FILTER_STAGE_AFTER_VALIDATION. But if that simple filter is rewritten as a complex filter (by specifying the filter as an array with a method key), the filter will not work properly without stage key.

@GrahamCampbell
Copy link
Member

It looks like this is abandoned. If you are still interested in finishing this, please feel free to open a new PR. I don't have capacity to take over and finish this from its current state.

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

Successfully merging this pull request may close these issues.

Feature Request - Ability to Bind Parameter Filters to Specific Request Stages Filters are applied twice
2 participants