HTTP Health Options Are Validated
Applies to
@connectum/healthcheck1.3.0.
Does this apply to you?
You need to act only if your code passes httpPaths to Healthcheck():
httpPaths: []now throws aRangeErrorwhenHealthcheck()is called. Before, it lefthttpEnabled: truewith an endpoint that matched nothing.- An entry that is not a string, does not start with
/, or contains?or#now throws aTypeError. Before, it was accepted and never matched a request.
If you do not pass httpPaths, or you pass a non-empty list of absolute paths, nothing changes. The check runs whenever httpPaths is passed, also with httpEnabled: false.
Required changes
Choose one for each affected call:
- You used
[]to turn the HTTP endpoint off. RemovehttpPathsand sethttpEnabled: false(the endpoint is off by default). - An entry had no leading slash. Write an absolute path:
'healthz'becomes'/healthz'. - An entry carried a query or a fragment. Remove the
?...or#...part; a request path never contains it, and the query string is ignored when matching.
// Before: HTTP "disabled" by an empty list
Healthcheck({ httpEnabled: true, httpPaths: [] });
// After
Healthcheck({ httpEnabled: false });2
3
4
5
Behavior that did not change
Paths are matched exactly and case-sensitively (/healthz/ does not match /healthz), the query string is ignored when matching, and the request method is not checked.
One defect is fixed with no action on your side: /healthz?service=<name> used to answer with the overall state when the request carried an empty or malformed Host header. It now describes <name> for any Host value.
Verify the upgrade
Start the server and request /healthz?service=<a service you track>; the service field of the body must be that name. If Healthcheck() throws at startup, the message names the httpPaths option and the entry that failed.