Closed szrexzhu closed 8 years ago
My first suggestion: can you just use status codes within the 100 to 599 range for your custom ones? There are plenty of undefined codes, if you're just needing something for internal use. Or use an appropriate existing one with a custom payload?
I don't see anything in the SPDY spec explicitly prohibiting status codes greater than 599. A missing status code (statusCode < 100 works, or statusCode == 0) is really all this check needs to do. I'm not opposed to changing, but would prefer staying within 100 to 599 if possible. What do you think?
SPDY does not explicitly call out the range, but status codes are defined by the HTTP spec (which SPDY and HTTP/2 adhere to) and do have a defined range of status codes with a "page" per status code type:
1xx Informational 2xx Success 3xx Redirection 4xx Client Error 5xx Server Error
I would definitely recommend not only conforming to these pages of codes, but actually using the correct status code for the errors you are eliciting. If more fine grained context is required, you can provide either an additional header for an the API error code (could call it "X-api-error-code") or a payload that details the error. Networking layers around on all sorts of platforms have built in assumptions based on the server returning an accurate status code, I definitely recommend conforming.
We use the SPDY proxy server to define some custom HTTP status codes such as 800. But CocoaSPDY will throw an error. Here we have a better way to deal with it? Here is my code in "SPDYStream.m":