服务器端代码如下:
@RequestMapping(value = "/test")
@ResponseBody
public Result test(){
result.setSuccess(true);
result.setData(new Random().nextDouble() + System.currentTimeMillis());
return result;
}
chorme的network截图如下,发现两次请求返回的内容是同一个
请求一
请求二
经过多次试验,发现请求是都走到Controller里,但是第一次请求的响应数据没有马上返回给浏览器端,而是和第二次请求的响应一起返回给了前端,并且第一次请求的响应内容居然是第二次响应的内容。
有时候两次请求的响应能不相同,有时候却相同,不知道是什么原因。
我的实际应用场景是,前台上传多个附件,但是本质是多次上传,然后由后台返回此文件在数据库中的文件id。然后我发现有时上传多个文件时,返回的文件id都是同一个。
如下图所示:两个上传的文件长度是不一样的
文件一
文件二
但是服务器返回的文件id却是一样的:
文件一
文件二
文件一
请求消息
响应消息
文件二
请求消息
响应消息
ブラウザによってリクエストされた URL の後にキャッシュを防ぐためにタイムスタンプを追加してみてください
コメントを読んだ後、応答コードが 304 であれば、前回と同じである可能性があります。リクエストされた URL は同じであるため、リクエストにランダムなパラメーター (タイムスタンプ) を追加して、ブラウザーが使用するデータをキャッシュして、URL が毎回不一致になるようにすることができます。
Spring MVC コントローラーのログを見て、リクエストがサーバーに到達する時間が同じミリ秒であるかどうかを確認します
部長、また来ましたね。
System.nanoTime()
を使って戻り値を確認してみてください。リクエスト データ (GET リクエストなのか POST リクエストなのか? これら 2 つのリクエストはどのように開始されるのか? 関連するクライアント コードはどのように書かれているのか?) などの重要な情報が不足しているため、以下は個人的な推測にすぎません。
1、2 つのリクエストはほぼ同時にサーバーに対して開始されます。
2. 推測 1、
new Random().nextDouble() + System.currentTimeMillis()
に基づいて、違いはほとんどないと考えられます (特にローカルでテストする場合)。3. Use double を使用してこの乱数を保存すると、Jackson は double 値をシリアル化するときに精度を失う可能性があります (js の精度損失の問題については自分で調べてください)。そのため、クライアント側では 2 つの値を全く同じようです
1、に基づく仮説の検証方法は以下の通りです:
リーリー出力結果を見て、ブラウザーのコンソールで JSON.parse (ログに記録された値) を使用して、それらが同じであるかどうかを確認します。
解決策: この乱数を保存するために文字列を使用します。 以下は、数桁の乱数を生成するために私が自分で書いたメソッドです (Java8):
リーリー分割線以降の問題については、コードがないため解析できません。
サーバー側で、要求された URL パス パラメーターをコンソールに出力します。サーバーに出力される 2 つのリクエストはまったく同じである必要があるため、サーバーはそれらを 1 つのリクエストとして処理します。上記の System.nanoTime() メソッドを試してみてください。