몇번 코드를 넣었다가 뺐다가 해보니,
이 코드로 수정했을때 바로 오류가 사라지고, 되돌리니 바로 다시 CORS오류가 발생한다.
며칠동안 테스트를 한 결과 해당 오류가 다시 발생되지 않아서 이 방법으로 해결이 된것으로 판단된다.
(아래 내용은 제가 프로젝트 트러블슈팅에 작성했던 내용입니다!)
추정 원인
아마 원인은 aws-chrome간 캐싱 버그로 의심됩니다.
브라우저가 우리가 이미 본 이미지의 URL은 캐싱을 하고있고, 이 부분에서 브라우저가 캐싱된 리소스의 CORS헤더를
기억하고 있고, 우리가 새로운 요청을 보내도 이전 캐싱된 리소스를 사용하게 되어 문제가 발생하는걸로 보입니다.
위 사진으로 보면 오른쪽이 캐싱된 원본 요청이고, 가운데가 캐싱된걸 요청하는것인데, cors관련 헤더가 아에 없어진 채로 요청이 들어가는 것을 볼 수 있습니다.
그래서 이 캐시는 URL을 기준으로 저장이 되기 때문에, 이미지 수정 페이지에서 사진을 가져올때는 캐싱된 리소스를 우회하기 위해,
무의미한 값이라도 뒤에 붙여주면서 새로운 URL을 사용하여 캐싱을 우회할 수 있습니다 .
해결(우회) 방법
처음에는 아래처럼 무의미한 시간 스탬프를 붙여서 매번 새로운 url을 생성하도록 했었다.
//MyProfilePage.tsx
//66행
try {
const response = await axios.get(`${data.profileImgUrl!}?timestamp=${Date.now()}`, {
responseType: 'blob',
});
위 방법을 사용하기보다는, 필요한 부분만 우회하는게 더 좋다고 판단해서 아래와 같이 변경했다.
변경한 계기는, 사실 로직 자체에서 중복 요청이 있었는데, 위와 같이 우회하니 그런 에러를 걸러주지 못하지만,
아래와 같이 변경하는 경우 불필요한 중복요청은 알아서 캐싱을 하는, 본래 캐시의 순기능이 잘 작동되었기 때문.
물론 로직은 중복 없도록 추가 수정되었다.
try {
const response = await axios.get(
`${data.profileImgUrl!}?cacheblock=true`,
{
responseType: 'blob',
}
);
두 이미지를 비교해보면 거의 95%이상 시간이 줄어든것을 볼 수 있는데,
특히 연결은 아에 사라졌고, 콘텐츠 다운로드 속도가 27밀리초-> 0.3밀리초로 줄어들었다.
아무리 헤더만 캐싱을 한다고 이정도의 시간 차이를 가져올수 있다고 보지 않기 때문에,
서버에서 데이터를 가져오는게 아니라 브라우저에 저장된 캐시를 활용하는 걸로 보인다.
====
참고
https://gmyankee.tistory.com/270
https://blog.hwahae.co.kr/all/tech/tech-tech/5412
https://inpa.tistory.com/entry/%F0%9F%8C%90-CORS-%EC%BA%90%EC%8B%9C-%EC%97%90%EB%9F%AC
