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.")'.
Since 6.2.x the HttpRequest with a Status Code of 200 (thankfully) works fine - else it'd be impossible to code by Web Framework anymore... But any other Status Code seems to get overwritten into a default XML message (apparently defined in *$SPLUNK_ROOT/lib/python2.7/site-packages/splunk/appserver/mrsparkle/controllers.proxy.py** ... I didn't have time yet, to reverse engineer that issue further in-code)*. This makes it impossible to return custom 404 pages, or error messages/reasons, effectively breaking any old javascript that relied on these...
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.
... View more