1

AFNetworking を使用して Rackspace リポジトリからファイルをダウンロードする際に問題が発生しました。

基本的に、ファイルが完全に転送されないことがありますが、AFNetworking は成功ブロックを起動します。また、受信した http 応答コードは 200 OK に設定されます。

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

この動作の原因について誰かヒントを教えてください。

編集、2012-05-10 問題が他の場所にある可能性があることを検出しました。ファイルの CRC をチェックして、予想される CRC と比較しています。ただし (接続が 3G 経由の場合にのみ発生します)、CRC チェックは失敗します。以下は、ファイルをダウンロードして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];

そして、コールバック メソッドで:

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] )
    {
       (...)

AFNetworking からの出力ストリームが完全に書き込む前に、[NSData dataWithContentsOfFile:] 命令がファイルを読み取っている可能性はありますか? ある種の iOS ディスク キャッシュなどに遭遇しているのかもしれません。

4

2 に答える 2

7

他のデータがない場合、私はワイルドな推測をします：

特定のファイル タイプは、3G 経由の透過プロキシの対象となる場合があり、これらのファイルが変更される可能性があります。これは、広く認識されている非可逆圧縮のファイル タイプです。基本的に、JPEG をダウンロードしようとしている場合、プロキシは予想よりも小さい JPEG を配信する可能性があります。セルプロバイダーはそれを「十分に近い」と見なしており、二重圧縮された JPEG は小さくなっています (そしてはるかに醜いです)。当然、再圧縮された画像の CRC は異なります。

これは、他のファイル タイプにも当てはまる場合があります。

T-Mobile がこれを行っているという報告を読んだことがあります。他のセルプロバイダーでも指摘されていると思います。

次の 2 つの修正方法があります。

以下のコメントで Tony Million が指摘したように、HTTPS に切り替えると、プロキシが通信の途中でなくなるため、この問題は解決されます。

リソースが HTTPS 経由で利用できる場合、これは素晴らしい簡単な修正です。

そうでない場合は、これを無効にするための HTTP ヘッダーを追加してみてください。私の携帯プロバイダーはこの特定のゲームをプレイしていないため、それがあなたのために機能することを確認できません:

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

アイデアは、no-transform cache-control HTTP ヘッダーをリクエストに追加することです。これにより、サーバーはこの種の変更を行うことができなくなります。

于 2012-05-11T02:15:49.790 に答える
1

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

サーバー側の詳細がなければ、私たちは本当にあなたを助けることはできません.

于 2012-05-08T14:23:27.210 に答える