return 504, 502 and 500 as appropriate Fixes #131

[graingert]

No description provided.

[coveralls]

Coverage increased (+0.06%) to 96.97% when pulling 43a2f66 on graingert:patch-1 into 100681c on chimurai:master.

[SpaceK33z]

Nice, looks good. I'm wondering if this would be a breaking change. It could be breaking if someone relies on the 500 status being returned.

[graingert]

@SpaceK33z not a breaking change over HTTP. The HTTP spec is very clear that servers can return these error codes, and clients should support them. Any client that does a hardcoded detection of '500' is not HTTP compliant, and should expect to be broken.

[coveralls]

Coverage increased (+0.06%) to 96.97% when pulling 0627ad9 on graingert:patch-1 into 100681c on chimurai:master.

[graingert]

@chimurai woop it's green now

[chimurai]

Thanks for the PR @graingert.

Definitely a better usage of the http status codes. Don't mind if this PR breaks existing hardcoded detection because of this improvement.

This defaultErrorHandler is overridable with the onError option if you want a customized error handling.

So if someone still wants to rely on the hardcoded 500 http error, they can use the onError option to achieve that.

---

Some background info why this default error handler exists.

From the http-proxy documentation:

proxy events
error: The error event is emitted if the request to the target fail. We do not do any error handling of messages passed between client and proxy, and messages passed between proxy and target, so it is recommended that you listen on errors and handle them.

[chimurai]

published in v0.17.3

hope this doesn't cause much regression :)

[SpaceK33z]

Awesome @chimurai :).