2012-05-08 8 views
1

AFNetworkingを使用してRackspaceリポジトリからファイルをダウンロードする際に問題が発生しました。ラックスペースからファイルをフェッチする際に3G経由のIOS AFネットワークが信頼できない

ファイルが完全に転送されないことがありますが、AFNetworkingが成功ブロックを発生させることがあります。受信したhttp応答コードも200 OKに設定されています。

この状況は、3G接続でのみ発生します。 WiFiでは、すべてのファイルを正しく受信します。

誰でもこの動作の原因となる可能性のあるヒントを教えてください。

編集、2012年5月10日 私はこの問題は、他の場所で、私がやっていることは、ファイルのCRCをチェックし、予想CRCと比較されることができることを検出しました。ただし、(接続が3Gを超えている場合にのみ発生します)、CRCチェックは失敗します。 NSDataの[

if(error == nil) 
{ 
    NSData * data = [NSData dataWithContentsOfFile:imgData.destinationFilename]; 
    uint32_t fileCrcInt = [data crc32]; 
    NSString * fileCrcHex = [NSString stringWithFormat:@"%2X", (int) fileCrcInt] ; 
    NSString * fileCrcHex2 = [NSString stringWithFormat:@"000000%@", fileCrcHex] ; 
    fileCrcHex2 = [fileCrcHex2 substringFromIndex:[fileCrcHex2 length]-8]; 

    // Compare CRC 
    if([expectedCRC isEqualToString:fileCrcHex2]) 
    { 
     (...) 

命令ということが可能です:以下は、私は、ファイルをダウンロードし、それがCRCです確認するために使用しているコードの一部抜粋です:

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:urlNS]; 

AFImageRequestOperation * imageRequestOperation = [AFImageRequestOperation imageRequestOperationWithRequest:request 
                imageProcessingBlock:nil 
                cacheName: nil 
                success: ^(NSURLRequest * request, NSHTTPURLResponse * response, UIImage * image) 
                { 
                 [self.class postProcessDownloadAfNetworking: request andResponse: response resultImage: image error: nil]; 
                } 
                failure: ^(NSURLRequest * request, NSHTTPURLResponse * response, NSError * error) 
                { 
                 [self.class postProcessDownloadAfNetworking: request andResponse: response resultImage: nil error: error];               
                }]; 

imageRequestOperation.outputStream = [NSOutputStream outputStreamToFileAtPath:obj.destinationFilename append:NO]; 


[imageRequestOperation start]; 

そして、コールバックメソッドにdataWithContentsOfFile:]は、AFNetworkingからの出力ストリームが完全に書き込む前にファイルを読み込んでいますか?おそらく、私は何らかの種類のiOSディスクキャッシュやそのようなものに遭遇しています。

答えて

7

、私は野生の推測を取るよ:

特定のファイルタイプには、それらのファイルを変更することができる第3世代にわたる透過プロキシ、を受ける可能性があります。これは、ロッシー圧縮を使用して広く認識されているファイルタイプです。基本的に、JPEGをダウンロードしようとしている場合、プロキシは予想よりも小さいJPEGを配信するかもしれません。セルプロバイダーはそれを「十分に近い」ものと見なし、二重に圧縮されたJPEGはより小さく(そしてはるかに醜い)。もちろん、再圧縮された画像は異なるCRCを有することになる。

これは他のファイルタイプにも当てはまります。

私はこれをやっているTモバイルのレポートを読んだ。私はそれが他の携帯電話提供者にも注目されていると思います。プロキシは、もはや通信の途中でできなくなりますようにこの問題を修正するHTTPSへの切り替え、以下のコメントでトニー百万円で述べたように

2つの可能な修正があります。

あなたのリソースがHTTPS経由で利用可能な場合、これは素晴らしいと簡単な修正です。

そうでない場合は、これを無効にするためのHTTPヘッダーを追加できます。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5

アイデアはあなたの要求に無変換のCache-Control HTTPヘッダーを追加することです:私は私の細胞提供者は、この特定のゲームをプレイしていないとして、それは、あなたのために動作します確認することはできません。これにより、サーバーはこの種の変更を行うことができなくなります。

+0

これを避け、指定されたとおりにプロキシにコンテンツを配信させる方法はありますか? – epocas

+0

あなたは開発者ですか?影響を受けていない別の画像形式に切り替える(または、画像をZIPファイルに入れたり、プロキシから隠すなど)以外に、これを行うすべての3Gキャリアで動作する信頼性の高い方法ではない可能性があります。私はエンドユーザーがプロキシを完全に無効にできると信じています。 –

+0

答えが更新されました。 –

1

これはRackspace /サーバーの問題のようです。サーバーが200応答コードを送り返している場合は、成功した接続とファイル/データ転送を示します。

サーバーサイドの詳細がなければ、私たちは本当に助けてはいけません。他のデータが存在しない場合には

関連する問題