服务器端代码如下:
@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 요청입니까? 이 두 요청은 어떻게 시작됩니까? 관련 클라이언트 코드는 어떻게 작성됩니까?)와 같은 중요한 정보가 부족하기 때문에 다음은 개인적인 추측일 뿐입니다.
1 두 요청이 거의 동시에 서버에 시작됩니다.
2. 추측 1에 따르면
new Random().nextDouble() + System.currentTimeMillis()
차이가 거의 크지 않다고 볼 수 있습니다(특히 로컬에서 테스트할 때).3. Use double을 사용하여 이 난수를 저장하면 Jackson은 double 값을 직렬화할 때 정밀도를 잃을 수 있습니다(js의 정밀도 손실 문제는 직접 검색해 보세요). 따라서 클라이언트 측에서는 두 값을 똑같은 것 같아요
1을 바탕으로 한 추측, 가설적 검증 방법은 다음과 같습니다.
으아악출력 결과를 살펴보고 브라우저 콘솔에서 JSON.parse(기록된 값)를 사용하여 동일한지 확인합니다.
해결책: 문자열을 사용하여 이 난수를 저장합니다. 다음은 여러 자리 난수를 생성하기 위해 직접 작성한 방법입니다(java8).
으아악구분선 이후의 문제는 코드가 없어 분석할 수 없습니다.
서버 측에서는 요청된 URL 경로 매개변수를 콘솔에 인쇄합니다. 서버에 인쇄된 두 요청은 정확히 동일해야 서버가 이를 하나의 요청으로 처리합니다. 위의 System.nanoTime() 메서드를 사용해 볼 수 있습니다.