FilterChain should pass the request and response from filters to Target function

[SVilgelm]

The PR #478 brought some weird changes that breaks the filters behaviour.
We have a filter that creates another instance of Response to intercept all headers and data, then does an audit and modifies the data and only then it forwards to the original response.
But the lambda added in that PR breaks this logic, since the target function writes directly to the original response.

[SVilgelm]

@emicklei Could you please check this PR? It is a blocker for us

[emicklei]

weird I agree , the code in v3 already has this change, see:

go-restful/container.go

Line 292 in 8c11725

Target: func(req *Request, resp *Response) {

[SVilgelm]

Yes and I remove that code from v3.

[emicklei]

hmm , ic, but I was introduced for another reason. I will have to find that other issue.

[emicklei]

Apparently, in #478, @erraggy made that change.

[SVilgelm]

yes, I saw both PRs but didn't find any reason for this change.
It really breaks the filters logic.
It is pretty common when we modify/create response or even request in a middleware and the pass new instances to next middleware or to a handler.

[SVilgelm]

it is very useful if we have a lot of old legacy handlers, but we need to migrate for new api, then we can intercept the response from handler and convert it into new format

[SVilgelm]

@erraggy Could you please check this PR and discussion? Is there a reason of adding lambda and passing original request and response to target instead of the instances that came from filters?

[erraggy]

Yikes! It appears that my change to container.go was originally based on a 3 year old version of this repo from before this commit: 722f7c5

My change unintentionally brought back this lambda from 3 years ago. Sorry about that.

[SVilgelm]

so, then lets merge this PR 😃

[SVilgelm]

cool, thank you very much. Now lets release it as 3.7.2 😺

[SVilgelm]

@emicklei do we need to back port it to v2 branch?

[erraggy]

@emicklei do we need to back port it to v2 branch?

My changes that introduced the bug were only applied to the v3 so I don't think any back-porting would be needed.