[SOLVED] NSMutableURLRequest http status code 413

NSMutableURLRequest http status code 413

I have a web service. I use it to accept a base 64 string representation of a small (thumbnail size) image. This web service works awesome when using it with Fiddler and manually posting the request. When I run the same request with NSMutableURLRequest (or ASIHTTPRequest), it always returns a 413 status code (413 is Request Entity is Too Large).

Why would NSMutableURLRequest cause it to come up with a 413, whereas Fiddler returns 200 every time?

Here is my NSMutableURLRequest code. I could really use a push, if anybody has any ideas.

        //the image request
        NSMutableURLRequest *imageRequest=[NSMutableURLRequest requestWithURL:[NSURL URLWithString:POST_IMAGE_API_URL] 
                                                                  cachePolicy:NSURLRequestUseProtocolCachePolicy
                                                              timeoutInterval:240.0];

        //the post parameters
        [imageRequest setHTTPMethod:@"POST"];
        [imageRequest setHTTPBody:[imageMessage dataUsingEncoding:NSUTF8StringEncoding]];
        [imageRequest setValue:@"text/xml" forHTTPHeaderField:@"Content-Type"];


        //a few other things
        NSURLResponse* imageresponse;
        NSError *imageerror;


        NSData* imageresult = [NSURLConnection sendSynchronousRequest:imageRequest returningResponse:&imageresponse error:&imageerror];
        NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse*)imageresponse;

        NSLog(@"imageresponse: %d", httpResponse.statusCode);

Solution

I found a solution for this. The issue was not on the Apple end, but on the IIS end. There is an additional parameter for IIS hosted applications (one of which being my WCF service) beyond what is specified in the WCF's web.config file that specifies the "uploadReadAheadSize" for each service. I increased this and the 413 went away. Interestingly enough, I didn't get this error when sending the HTTP request from Fiddler on a desktop client on the same network as the server where the service resides. Basically, I had the solution to this guy's problem but not his context. My solution was his context.