an xml-rpc method can't affect the http status of the response
Bug #796386 reported by
Michael Hudson-Doyle
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro XML-RPC application for Django |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I'm not quite sure what the best approach is, but I think we definitely want to be able to return HTTP 401/403s from xml-rpc method implementations at least, and maybe other codes too. Maybe custom exceptions should be provide translated into appropriate codes, or maybe we should allow methods to just return HttpResponse objects?
Changed in linaro-django-xmlrpc: | |
status: | New → Invalid |
To post a comment you must log in.
Yeah, I considered this too. You will notice that dashboard returns 403 via Fault.faultCode.
I'm not sure if turning this into a proper HTTP status is the right way though - I see the following possible combinations:
1) The server raises an appropriate HttpStatus exception without producing either Fault or response objects. The client library (probably) reports ProtocolError and provides a way for the caller to inspect the status. The biggest downside is that it's really not xml-rpc-ish. There would have to be two code paths for each method that might return those.
2) The server returns a normal response / raises Fault but uses some out-of-band data to convey the status code of the request. The client (we should check this) follows the normal code path where the response/fault is returned as usual but also provides an out-of-band channel for inspecting the response status code. The biggest downside here is that I don't see anyone using the response code as you already have either the Fault (with similar/identical code) or the response which you were after.
3) The server raises an appropriate HttpStatus exception and the library on both sides cooperate to convert this into a standardized Fault. The client has only one code path - one that follows Fault processing. There is no custom guessing. The biggest advantage is that the caller can now assume some semantics of Fault.faultCode between 400 and 500.
What do you think?