Issues

ZF-11991: Zend_Json_Server only allows error codes RESERVED for JSON-RPC implementation

Description

Zend_Json_Server only allows errors in range(-32099, -32000).

This range is within the -32768 to -32000 range the JSON-RPC spec reserves. Zend_Json_Server should NOT allow using these codes, but allow any other.

Comments

Um... Zend_Json_Server is a JSON-RPC implementation; how is this a problem?

True, I did not say Zend_Json_Server should not use these codes, I said it should not ALLOW using these codes. The are reserved for the protocol implementation, ie Zend_Json_Server itself.

Yet client code can only invoke errors within the reserved range. This is not in compliance with the spec:

"The error codes from and including -32768 to -32000 are reserved for pre-defined errors. Any code within this range, but not defined explicitly below is reserved for future use. The error codes are nearly the same as those suggested for XML-RPC at the following url: http://xmlrpc-epi.sourceforge.net/specs/…"

The spec then goes on listing the specific protocol error codes, and listing the range -32099 / -32000 as:

-32000 to -32099 Server error Reserved for implementation-defined server-errors.

The section (5.1) closes with the following statement:

"The remainder of the space is available for application defined errors."

Clearly, the protocol implementation does not mean the whole ZF based application but just Zend_Json_Server. So Zend_Json_Server should limit itself to this range, not the application, as the remainder of the space is "available" for the application. Furthermore, the rest of the application should not even be allowed to set codes in this range, because they are "reserved" for the protocol implementation.

Anyone?

Does allowing the userspace application to set protocol error codes cause any direct negative side-effects? Unless there is a demonstrable problem, we shouldn't change this behaviour for fear of breaking those userspace implementations which are using those error codes.

I get that. At the very least, the right error codes should be allowed in the 1.9 cycle, and since 2.0 isn't final yet, disallowing wrong error codes should be added to that branch.

Tbh, I haven't checked the latest beta, but assuming it's not fixed there (which is a reasonable assumption), it should be ASAP. Otherwise this won't be fixed until 3.0 and god knows when that will be.

Apologies, I misread your initial report. I thought you meant they CAN set protocol error codes, but you meant they CAN ONLY set errors in that reserved range. If that is the case, it is something which should be fixed. Could you point to me where these error codes are defined for JSON-RPC? Their v1 specification doesn't mention anything about it.

Tbh, I do not understand your confusion. The spec says the range -32768 to -32000 is reserved for protocol implementation. In the context of ZF, this refers to Zend_Json_Server. Yet the implementation does not allow client code to set any error codes outside of this range, while that range should be private to that component. Client code should be allowed to use any code, other than the ones within that range.

I really cannot interpret the spec in any other way.

Please refer to http://jsonrpc.org/spec.html, section 5.1.

Just a simple misread - missed the word "only" in your bug description. I've never used JSON-RPC, and I don't pretend to know anything about it (as evidenced by the fact that I found the wrong spec).

After reading the spec you linked to, you are definitely right. The only constraints on the error code field are (1) that it must be an integer and (2) -32768 to -32000 are reserved.

Not being familiar with the usage of Zend_Json_Server, I have a (dumb) question: do clients listen for specific error codes? I ask this because the simple change below to implement your request will cause some response codes to change. Explanation:

Currently, when {{Zend_Json_Server_Error::setCode}} is given a code outside the reserved range it ignores it and the internal variable {{$_code}} remains set to the last "valid" code specified (-32000 by default). This is important because when I updated {{Zend_Json_Server_Error::setCode}} to accept any integer code:


Index: library/Zend/Json/Server/Error.php
===================================================================
--- library/Zend/Json/Server/Error.php  (revision 24665)
+++ library/Zend/Json/Server/Error.php  (working copy)
@@ -92,13 +92,7 @@
             return $this;
         }

-        $code = (int) $code;
-        if (in_array($code, $this->_allowedCodes)) {
-            $this->_code = $code;
-        } elseif (in_array($code, range(-32099, -32000))) {
-            $this->_code = $code;
-        }
-
+        $this->_code = (int) $code;
         return $this;
     }

A test fails:


1) Zend_Json_ServerTest::testHandleRequestWithExceptionShouldReturnErrorResponse
Failed asserting that 

Yes, clients MAY listen to error codes, obviously. If they did not, there would be no reason to change the component to comply to spec (a problem without symptoms wouldn't be a problem). I get your point though: any applications built on the faulty implementation that rely on the current faulty error code handling would fail.

Still, can we please fix this upstream? In all honesty I've already worked around this by subclassing some classes (who can wait for a ticket here to be resolved, honestly), but I'm just very disappointed in the quality of this component. Lets just fix it upstream, please.

I've opened a matching issue in the ZF2 space (ZF2-181).

Thank you. Still, I would like someone to asses the scope of the change that fixes this (partly) in the 1.9 cycle. In other words, can someone give some weight to the proposed break of BC by NOT casting application error codes to the reserved range? For many leads like myself ZF 2.0 is very, very far away.

I've flagged this issue for the CR Team to review.

Thank you. Glad someone finally took a look at this issue.