twitter-archive / CocoaSPDY

SPDY for iOS and OS X
Apache License 2.0
2.39k stars 233 forks source link

Note the use of custom HTTP status codes #148

Closed szrexzhu closed 8 years ago

szrexzhu commented 8 years ago

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":

- (void)didReceiveResponse:(NSDictionary *)headers
{
    _receivedReply = YES;

    NSInteger statusCode = [headers[@":status"] intValue];

    //by rex 我们浏览器的自定义状态码是8XX
    //    if (statusCode < 100 || statusCode > 599) {
    if (statusCode < 100 || statusCode > 1000) {
        NSDictionary *info = @{ NSLocalizedDescriptionKey: @"invalid http response code" };
        NSError *error = [[NSError alloc] initWithDomain:NSURLErrorDomain
                                             code:NSURLErrorBadServerResponse
                                         userInfo:info];
        [self closeWithError:error];
        return;
    }
kgoodier commented 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?

NSProgrammer commented 8 years ago

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.