Knowledge base
Two conventions in one node. HTTP submission behaves as expected: an error in the request, the key, the path, the method or inside the node — each gets its own response code, 400, 403, 404, 405 or 500, with details in the errors body.
The configuration API is different: everything except an access refusal returns 200, and the outcome goes into the status field — success or fail — with text in message. A rejected change is not applied.
The refusal text can mislead: deleting a list that is in use may return “no such address list” — the deletion was rejected, and the list stayed in place. And during a large operation, store locking may fail a neighboring operation or an ordinary reload — those are retried.
How to tell there was an error:
| API | Error signal |
|---|---|
| HTTP submission | the response code and the errors body |
| configuration API | status fail and message with code 200 |
| access refusal to the configuration API | a response code other than 200 |
# a configuration API refusal: code 200, the outcome is in the body HTTP/1.1 200 Ok {"message": "Error reading configuration: Config API error: Address 'a@z.com' does not exist in address list 'list1'.", "status": "fail"}
Related entries
2 relations
curl -s -w '\n%{http_code}\n' 'http://127.0.0.1:8080/config/address-lists/nosuchlist'
What else to read
3 articles
◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.
- Cost of a mistake
- safe: a wrong value breaks nothing
- Scenarios
- Configuration lifecycle