2

しばらくの間、これの何が問題なのかを理解しようとしてきました。サーバーAPIへのjson本体を使用してHttpClient.executeで投稿リクエストを作成しています。通常の Wi-Fi とほとんどの 3g では正常に動作しますが、特に AT&T データプランを備えた電話で 3g を使用している場合、リクエストを実行しようとすると HttpResponseException が返されます。ステータス コード 422 です。に：

「422 Unprocessable Entity (WebDAV) (RFC 4918)、要求は整形式でしたが、セマンティック エラーのため従うことができませんでした。」

したがって、リクエストの送信方法に問題があると推測していますが、Wi-Fi を使用しているか 3G を使用しているかにかかわらず、リクエストを作成する際に同じことを行っています。このエラーの原因について何か考えはありますか?

編集：私のサーバーが偽造防止で投稿をキャッチしているように見えました。オフにしてエラーは止まりましたが、APIは通りませんでした。もう少し深く掘り下げて、サーバーが実際に受信しているものを出力し、wifi のオンとオフを比較して、2 つの違いに気付きました。まず、3g で本文が空だったのですが、何らかの理由で送信がブロックされたようです。次に、ヘッダーによって、送信されるコンテンツ タイプが変更されました。

wifi: "HTTP_CONTENT_TYPE"=>"application/json" att 3g: "HTTP_CONTENT_TYPE"=>"text/plain; charset=ISO-8859-1,application/json"

次のように接続を設定していることを考えると、「application/json」を期待しています。

StringEntity se = new StringEntity(json.toString());
se.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE, "application/json"));

3g に移行したときに状況が変わる理由はありますか?

更新: tcpdump を実行したところ、Android から送信しているものは wifi と 3g でまったく同じであるように見えるため、データを変更しているのはプロバイダーのようです。HTTPS 以外に提案された戦略はありますか?

4

1 に答える 1

7

解決しました！

古いコード:

    mPost = new HttpPost(ur);
    StringEntity se = new StringEntity(json.toString());
    se.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE, "application/json"));
    mPost.setEntity(se);

新しいコード:

    mPost = new HttpPost(ur);
    ByteArrayEntity baEntity = new ByteArrayEntity(json.toString().getBytes("UTF8"));
    baEntity.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE, "application/json"));
    mPost.setEntity(baEntity);

私の投稿の本文は3gで動作するため、StringEntityの代わりにByteArrayEntityを使用しているように見えます。StringEntity を使用している間、wifi と 3g の間の tcpdump がまったく同じように見えた理由が正確にはわかりませんが、問題は修正されたようですので、文句はありません。

于 2012-07-13T19:30:43.830 に答える