Comment 1 for bug 796386

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?