NSData Multipart answer from NSURLConnection

I need to make a web service call that returns an IMAGE in multipart / related response (The answer I pasted below after the code.)

I cannot read the image data. Please help. I AM to get an answer to POSTMAN. But I don't know how to parse it in code. Also, I need help converting NSData to JSON or NSDictionary so that I can read the image data. I tried NSJSONSerialization but it returns NULL.

  • CODE I WRITING:

    NSURL *url = [URIStringsClass messageAttachmentURI];  // Gets me our organization URI
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    NSURLResponse *response = nil;
    NSError *error = nil;
    
    // These are the headers that we need to set as per WebServices team documentation
    [request setHTTPMethod:@"GET"];
    [request setValue:self.message.system forHTTPHeaderField:@"X-systemID"];
    [request setValue:[NSString stringWithFormat:@"%@",self.message.messageId] forHTTPHeaderField:@"X-messageID"];
    [request setValue: [[[_message attachments] objectAtIndex:[indexPath row] - 2]JSONStringForKey:@"name"] forHTTPHeaderField:@"X-attachmentID"];
    
    // I AM NOT SURE IF I HAVE TO MENTION THIS    
    //    [request setValue:@"multipart/related" forHTTPHeaderField:@"content-type"];
    NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
    
    if(data != nil)
    {
        UIView *aView = [[UIView alloc] initWithFrame:CGRectMake(30, 30, 200, 200)];
        UIImageView *imageView = [[UIImageView alloc]initWithFrame:CGRectMake(30, 30, 200, 200)];
        imageView.image = [UIImage imageWithData:data];
        aView.backgroundColor = [UIColor redColor];
        [aView addSubview:imageView];
        [self.subjectView addSubview:aView];
    
        NSString *newStr = [NSString stringWithUTF8String:[data bytes]];
        NSLog(@"JSON Data : %@", newStr);
    }
    
          

  • NSURLResponse

    after executing the code

    (lldb) po response
    <NSHTTPURLResponse: 0x7c9965f0> { URL: https://............ } { status code: 200, headers {
        Connection = "keep-alive";
        "Content-Language" = "en-US";
        "Content-Length" = 64159;
        "Content-Type" = "multipart/related; boundary=\"MIMEBoundaryurn_uuid_53A435D3A5CC74CCF71420587543829\"; type=\"text/xml\"; start=\"<0.urn:uuid:53A435D3A5CC74CCF71420587543830@apache.org>\"";
        Date = "Tue, 06 Jan 2015 23:28:56 GMT";
        Server = "WebSphere Application Server/7.0";
        "Set-Cookie" = "BIGipServerebiz-isqa-9444=1574180012.58404.0000; path=/";
        Via = Gateway;
        "X-Archived-Client-IP" = "127.0.0.1";
        "X-Backside-Transport" = "OK OK,OK OK";
        "X-Client-IP" = ".................";
        "X-CorrelationID" = "Id-54ac6fb500dfd23a00002862f08e4067 0; Id-54ac6fb50028d4fe000024d97aae61c6 0";
    } }
    
          

  • Web services response to POSTMAN:

    --MIMEBoundaryurn_uuid_53A435D3A5CC74CCF71420585641061
    Content-ID: <0.urn:uuid:53A435D3A5CC74CCF71420585641062@apache.org>
    Content-Type: application/json;
        charset="utf-8"
    
    {"GetAttachmentResponse":{"executionContext":null,"attachment":{"attachInfo":{"name":4,"attachmentID":"0","mimiType":"application/octet-stream"},"attachRef":"cid:urn:uuid:53A435D3A5CC74CCF71420585641037@apache.org"}}}
    --MIMEBoundaryurn_uuid_53A435D3A5CC74CCF71420585641061
    Content-ID: <urn:uuid:53A435D3A5CC74CCF71420585641037@apache.org>
    Content-Type: application/octet-stream
    
    ????JFIFHH??@ICC_PROFILE0ADBEmntrRGB XYZ ?acspAPPLnone???-ADBE
    
    [rest of binary data snipped out of question: see hex below or look at revision history]
    
    --MIMEBoundaryurn_uuid_53A435D3A5CC74CCF71420585641061--
    
          

    If anyone wants to see a lovely JSON version, it was:

    {
        "GetAttachmentResponse": {
            "executionContext": null,
            "attachment": {
                "attachInfo": {
                    "name": 4,
                    "attachmentID": "0",
                    "mimiType": "application/octet-stream"
                },
                "attachRef": "cid:urn:uuid:53A435D3A5CC74CCF71420585641037@apache.org"
            }
        }
    }
    
          

  • NSData

    which I got from code:

    2015-01-06 14:56:53.682 KPFlagshipMessages[10676:147391] DATA : <0d0a0d0a 2d2d4d49 4d45426f 756e6461 72797572 6e5f7575 69645f35 33413433 35443341 
    35434337 34434346 37313432 30353835 36313938 34340d0a 436f6e74 656e742d 49443a20 3c302e75 726e3a75 
    7569643a 35334134 33354433 41354343 37344343 46373134 32303538 35363139 38343640 61706163 68652e6f 
    72673e0d 0a436f6e 74656e74 2d547970 653a2061 70706c69 63617469 6f6e2f6a 736f6e3b 0d0a0963 68617273 
    65743d22 7574662d 38220d0a 0d0a7b22 47657441 74746163 686d656e 74526573 706f6e73 65223a7b 22657865 
    63757469 6f6e436f 6e746578 74223a6e 756c6c2c 22617474 6163686d 656e7422 3a7b2261 74746163 68496e66 
    6f223a7b 226e616d 65223a22 494d475f 30313534 222c2261 74746163 686d656e 74494422 3a223022 2c226d69 
    6d695479 7065223a 22617070 6c696361 74696f6e 2f6f6374 65742d73 74726561 6d227d2c 22617474 61636852 
    6566223a 22636964 3a75726e 3a757569 643a3533 41343335 44334135 43433734 43434637 31343230 35383536 
    31393831 39406170 61636865 2e6f7267 227d7d7d 0d0a2d2d 4d494d45 426f756e 64617279 75726e5f 75756964 
    5f353341 34333544 33413543 43373443 43463731 34323035 38353631 39383434 0d0a436f 6e74656e 742d4944 
    3a203c75 726e3a75 7569643a 35334134 33354433 41354343 37344343 46373134 32303538 35363139 38313940 
    61706163 68652e6f 72673e0d 0a436f6e 74656e74 2d547970 653a2061 70706c69 63617469 6f6e2f6f 63746574 
    2d737472 65616d0d 0a0d0aff d8ffe000 104a4649 46000101 01006000 600000ff db004300 01010101 01010101 
    01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 
    01010101 01010101 01010101 ffdb0043 01010101 01010101 01010101 01010101 01010101 01010101 01010101 
    01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 01010101 01ffc000 1108014d 
    00fa0301 22000211 01031101 ffc4001f 00000105 01010101 01010000 00000000 00000102 03040506 0708090a 
    0bffc400 b5100002 01030302 04030505 04040000 017d0102 03000411 05122131 41061351 61072271 14328191 
    a1082342 b1c11552 d1f02433 62728209 0a161718 191a2526 2728292a 34353637 38393a43 44454647 48494a53 
    54555657 58595a63 64656667 68696a73 74757677 78797a83 84858687 88898a92 93949596 9798999a a2a3a4a5 
    a6a7a8a9 aab2b3b4 b5b6b7b8 b9bac2c3 c4c5c6c7 c8c9cad2 d3d4d5d6 d7d8d9da e1e2e3e4 e5e6e7e8 e9eaf1f2 
    f3f4f5f6 f7f8f9fa ffc4001f 01000301 01010101 01010101 00000000 00000102 03040506 0708090a 0bffc400 
    b5110002 01020404 03040705 04040001 02770001 02031104 05213106 12415107 61711322 32810814 4291a1b1 
    c1092333 52f01562 72d10a16 2434e125 f1171819 1a262728 292a3536 3738393a 43444546 4748494a 53545556 
    5758595a 63646566 6768696a 73747576 7778797a 82838485 86878889 8a929394 95969798 999aa2a3 a4a5a6a7 
    a8a9aab2 b3b4b5b6 b7b8b9ba c2c3c4c5 c6c7c8c9 cad2d3d4 d5d6d7d8 d9dae2e3 e4e5e6e7 e8e9eaf2 f3f4f5f6 
    f7f8f9fa ffda000c 03010002 11031100 3f00fb87 e19fc3ff 00829a4f c1df851a af887e1a fc15d3a0 93e12fc3 
    39eeb53d 6be1f7c3 cb749649 7c0da13c b733dedf 6880bcd2 c8c6599e 579269a4 767625dd b3e63e32 f8d3fb19 
    f84a2b98 2cbe1cfc 2df1b6a5 047238b2 f0c7c22f 024b6ecc 8c5407d5 af3c3b65 a6471b31 00b4335e 328da180 
    e2bf1b34 ff0089cb aaf83fc0 52789bc5 3ab7886f a0f01782 ada26bfb bbbd5e6b 4860f0e6 94915bda da38992d 
    aded2183 ecf12430 a46a170c bbc2b1c9 b9f88b71 >
    
          

+3


source to share


1 answer


This looks like a very plausible multipart answer, I see there seems to be a valid JPEG (or at least the beginning of one) in the second part. It's extremely unusual to see multipart responses: we are constantly building multiprocessing requests in our iOS code, but we don't handle multipart responses at all.

Your Objective-C code, though trying to load this as an image, is not a simple image. You really have to parse the multipart answer.

Before dragging you through the weeds of the ugly parsing process of this multipart answer, are you stuck with an answer like this? I would prefer a simple JSON response with image-64 encoding. Or a JSON response with a URL for an image that can be downloaded separately.

It will take a lot of ugly code to parse this non-standard answer, so the question is if there is a chance to change the answer.




It looks like you are stuck with this format. In this case, in order to parse this answer, you first need to get boundary

from Content-Type

in the headers NSURLResponse

. Then you can scan a useful response burden NSData

for --

, followed by this boundary line. Then you will have multiple headers for each part, followed by a blank line, followed by the payload. The first payload is JSON. The second is the image. You just read in bytes, until you meet the next \r\n

, followed by --

followed by a border. It all ends with a character --

, followed by a border, then another --

.




For a discussion of how multiple responses are constructed, see the discussion of multipart responses in RFC 1341 (the MIME specification). Or see RFC 2388 (Multipage Request Generated by HTML Forms). Or check out this example on how to create a multipart query in Objective-C. Or just Google "create a multipage query". Once you have a weapon around how multiple responses are generated, paired response analysis is fairly intuitive. But be sure to make sure you've loaded the multiplayer load before going too far.

See Parsing parsing for loading images in ios for some forward looking Objective-C code for parsing these kinds of responses.

0


source







All Articles