java - 浏览器发送了两次请求给服务器，服务器只返回后一次请求的内容

Question

浏览器调用同一个接口，发送了两次请求给服务器端，服务器端代码返回一个随机数给浏览器

框架是SpringMvc+Spring+MyBatis

服务器端代码如下：

@RequestMapping(value = "/test")
@ResponseBody
public Result test(){
    result.setSuccess(true);
    result.setData(new Random().nextDouble() + System.currentTimeMillis());
    return result;
}

chorme的network截图如下，发现两次请求返回的内容是同一个

• 请求一
  

• 请求二
  

有以下几个疑问：

• 经过多次试验，发现请求是都走到Controller里，但是第一次请求的响应数据没有马上返回给浏览器端，而是和第二次请求的响应一起返回给了前端，并且第一次请求的响应内容居然是第二次响应的内容。

• 有时候两次请求的响应能不相同，有时候却相同，不知道是什么原因。

---

分割线1

不少朋友说是因为我发的get请求，导致浏览器认为是缓存原因。

我的实际应用场景是，前台上传多个附件，但是本质是多次上传，然后由后台返回此文件在数据库中的文件id。然后我发现有时上传多个文件时，返回的文件id都是同一个。

如下图所示：两个上传的文件长度是不一样的

• 文件一
  

• 文件二
  

但是服务器返回的文件id却是一样的：

• 文件一
  

• 文件二
  

---

分割线2

我已经在URL上加了随机数，来区分是不同的请求，服务器的响应码是200，但是服务器返回的内容还是将第二次请求的响应内容覆盖掉了第一次响应内容

• 文件一

  • 请求消息
    

  • 响应消息
    

• 文件二

  • 请求消息
    

  • 响应消息
    

Answer 1

Essayez d'ajouter un horodatage pour empêcher la mise en cache après l'URL demandée par le navigateur

Answer 2

Après avoir lu les commentaires, c'est peut-être le cas. Jetez un œil au code de réponse. Si c'est 304, ce sera le même que la dernière fois. Étant donné que l'URL demandée est la même, vous pouvez ajouter un paramètre aléatoire (horodatage) à la demande pour mettre en cache les données utilisées par le navigateur afin de garantir que l'URL est incohérente à chaque fois.

Answer 3

Regardez le journal du contrôleur Spring MVC pour voir si l'heure à laquelle la requête atteint le serveur est la même milliseconde

Answer 4

Chef, vous êtes à nouveau ici, essayez d'utiliser System.nanoTime() pour voir la valeur de retour.

Answer 5

En raison du manque d'informations importantes telles que les données de la requête (s'agit-il d'une requête GET ou d'une requête POST ? Comment ces deux requêtes sont-elles initiées ? Comment le code client correspondant est-il écrit ?), ce qui suit n'est qu'une supposition personnelle :
1 , vos deux requêtes sont initiées sur le serveur presque en même temps
2 Sur la base de la conjecture 1, new Random().nextDouble() + System.currentTimeMillis() on peut presque considérer que la différence n'est pas grande (surtout lors de tests locaux) ;
3. Vous utilisez Utiliser double pour stocker ce nombre aléatoire, et Jackson peut alors perdre en précision lors de la sérialisation de la valeur double (veuillez rechercher vous-même le problème de perte de précision de js), donc côté client, vos deux valeurs ​​​​semblent être exactement les mêmes ;

Conjecture basée sur 1,

La méthode de vérification hypothétique est la suivante :

@RequestMapping(value = "/test")
@ResponseBody
public Result test(){
    result.setSuccess(true);
    result.setData(new Random().nextDouble() + System.currentTimeMillis());
    log.info(result.getData());
    return result;
}

Jetez un œil aux résultats de sortie et utilisez JSON.parse (la valeur enregistrée) dans la console du navigateur pour voir s'ils sont identiques.

Solution : Utilisez une chaîne pour stocker ce nombre aléatoire. Voici une méthode que j'ai écrite moi-même pour générer plusieurs chiffres de nombres aléatoires (java8) :

public static String generateRandomNum(int size) {
    return new Random().ints(size, 0, 10).boxed().map(String::valueOf).collect(Collectors.joining(""));
}

Quant au problème après votre ligne de démarcation, il n'y a pas de code et ne peut pas être analysé.

Answer 6

Côté serveur, imprimez les paramètres de chemin d'URL demandés sur la console. Les deux requêtes imprimées sur le serveur doivent être exactement les mêmes, afin que le serveur les traite comme une seule requête. Vous pouvez essayer la méthode System.nanoTime();