Closed mattbaileyuk closed 2 months ago
Thanks for reporting the issue @mattbaileyuk
I released v3.0.2 with a fix.
Please let me know if this fixes the issue you're facing.
Not sure what's happening with nock
. I'll investigate the issue further when I have time.
Sorry for the inconvenience.
@chimurai Thanks for responding and publishing a fix so quickly š All looks good at our end with 3.0.2
I added an onProxyRes
function which logged out the inbound proxyRes.req
object in response to the call to the nock
endpoint; I could see that there was an options
object on it which had protocol
and host
(so proxyRes.req.options.protocol
instead of proxyRes.req.protocol
), so the information is there but not where you would expect.
Happy to hear the fix works š
Thank you for doing additional investigation. This is really helpful.
Would it be possible to provide a minimal reproduction with nock
to further investigate the issue and help finding a proper solution?
Hi @chimurai , this fix doesn't work in case if router option is set but target option is not set.
Checks
http-proxy-middleware
.Describe the bug (be clear and concise)
The recently-published
3.0.1
ofhttp-proxy-middleware
includes a change to the logger (https://github.com/chimurai/http-proxy-middleware/pull/1001) which attempts to build a validURL
object using parts coming intoproxyRes
.However, we're seeing this blow up in some of our unit tests:
The change does not cope with parts of
req
being missing inproxyRes
, such asreq.protocol
andreq.host
as observed here. In3.0.0
this would just get included in the log message asundefined//undefined/management/users
and now it breakshttp-proxy-middleware
, so we have a breaking change here, even if it's just for more usual behaviour.I think this is because
nock
isn't returning all the bits ofreq
that this code expects (noprotocol
orhostname
but does sendpathname
) - or not in the right format, as I'm unsure ifproxyRes.req
is being built or just copied in from the incoming message. I think the code could be updated to follow what was done with the port and make it conditional, maybe defaulting tohttp://localhost
to make the URL valid.Step-by-step reproduction instructions
Expected behavior (be clear and concise)
The logger can cope with bits of
req
not being present when trying to build a valid URL and does not just blow up (especially if you don't even have logging enabled, as in our case)How is http-proxy-middleware used in your project?
What http-proxy-middleware configuration are you using?
Additional context (optional)
No response