Before the Splunk Enterprise version 6.2.x (e.g. in 6.1.x) I could still write in WebFramework (Django -based one), to return HTTP response with Status Code of 400, 404, or 500, with a custom message body.
I could do this by, either using Django Framework's ready "HttpResponseBadRequest", "HttpRequestNotFound", and "HttpResponseServerError" -objects, or using the plain "HttpResponse" -object specifying the Status Code as a parameter.
So I could create for example a 500-Code message with a message "Subsystem X failed - request not delivered", should the program logic fail accordingly. I could even use the Django's HTTP-Exception shortcuts (e.g. 'raise Http404("These drones aren't what you are looking for.")'.
So I have two options to go with:
- Either I refactor all serverside error messages to return Http Status "200 - OK", and refactor also all client-side code to expect ONLY 200 code, parsing it's content... but this is a lot less error resilient (than checking the Status Code), and makes the server-side code rather ambiguous.
- Or I overwrite the respective CherryPy module, that makes this change. I'd rather not go on with this, as it could produce Unforseen Consequences™, and has to be re-implemented on each version update...
Any information on whether this was an intended change, or not, and what is the likely version for it to be "fixed" (if will), would be really much appreciated.
Django is receiving less active dev attention now than in the past. Migrating to Simple XML + HTML panels + JS/CSS extensions is a more stable path moving forward if you have resources to make such a transition. -- Much of our existing docs are not up-to-date on this point.
We're currently using both Django and SimpleXML (in an unintended/ad-hoc way, in order to add some non-indexed data to the non-dashboard views, i.e. RDBMS data that's constantly fluctuating by relations - so less suitable for indexing..). Good to know, though. Thanks again. 🙂