Fix scope breaking change of request/response interception. (#241) #242
Conversation
|
Ah, you mean |
) Signed-off-by: Hermann Mayer <[email protected]>
Jack12816
force-pushed
the
fix-interception
branch
from
79cd335 to
5c01177
Compare
|
Yes, this is fine without due to the calling scope. I removed these calls. Thanks. |
| # method if you like to. This is just a shortcut. | ||
| def self.pass_request(params, headers, body, url, method) | ||
| handler = proxy.request_handler.handlers[:proxy] | ||
| response = handler.handle_request(method, url, headers, body) |
There was a problem hiding this comment.
nab: It's interesting to see the difference between internet/external APIs here.
i.e. the method args are: params, headers, body, url, method - but we're calling internally with method, url, headers, body
There was a problem hiding this comment.
Yes because of:
proxy.stub('http://example.com/').and_return(Proc.new { |*args|
response = pass_request(*args)
endThere was a problem hiding this comment.
Makes it easier to use here without introduce a breaking change (on the order of and_return arguments). Its more likely to intercept the response and modify it as to tweak the request. It was fine in first place, no need to debate on it in a fixup.
| # the request beforehand and/or modify the actual response which is passed | ||
| # back by this method. But you can also implement a custom proxy passing | ||
| # method if you like to. This is just a shortcut. | ||
| def self.pass_request(params, headers, body, url, method) |
There was a problem hiding this comment.
Just to confirm, is params a dead variable here?
|
Looks good to me, happy to ship this @ronwsmith? :) |
|
@ronwsmith Ping? |
See: #241 (comment)