topic Re: Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x? in Splunk Dev

Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x?

CynthiaMhav — Wed, 25 Feb 2015 09:51:36 GMT

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.

Re: Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x?

dfoster_splunk — Tue, 03 Mar 2015 19:31:05 GMT

I think this is a bug. I have filed it internally as SPL-97569 and instructed that this thread be updated when the ticket is completed. I have no ETA.

Re: Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x?

CynthiaMhav — Tue, 03 Mar 2015 20:27:10 GMT

Thank you, a lot. 🙂 This is a rather crippling bug on any javascript that relied on the response bodies (in addition to status codes)... but then again, this laying around a few months now (unfortunately I had no time to report it earlier.. had hurries everywhere) makes it look like not too many use the Django side in-depth. 😞

Re: Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x?

dfoster_splunk — Tue, 03 Mar 2015 20:55:54 GMT

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.

Re: Why WebFramework's responses with a non-200 HTTP Status Code always return the same, post-6.2.x?

CynthiaMhav — Wed, 04 Mar 2015 12:21:33 GMT

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. 🙂