2019-11-04 개발일지

# 오늘의 TODO

• 프론트팀 IE11에서 로그아웃 통신 이슈 분석 서포트
  • IE11에서 fetch API로 통신을 했을 때, 로그아웃 통신이 최초 1회만 통신이 수행되고 이후 통신이 서버로 전달되지 않는 문제를 분석했다.

 

---

 

# 프론트팀 IE11에서 로그아웃 통신 이슈 분석 서포트 내용

1. 문제

로그인 로그아웃 HTTP API 통신을 프론트 팀에서 구현하고 있었다.

fetch API로 통신을 구현하고 있는데, HTTP GET 메소드 통신에서 1회 통신은 정상적으로 요청 및 응답받고 2회 째 같은 통신은 요청이 서버로 전달되지 않는 문제가 IE 브라우저에서 발생했다.

이로 인해 세션을 지우는 로그아웃 기능이 로그인 / 로그아웃을 반복하면 먹통이 되는 문제가 발생하고 있었다.

 

2. 해결 과정

정말 다양한 뻘짓을 한 것 같다.

처음엔 fetch API를 잘못 쓴 것이 아닌가서 부터 요청 및 응답 시 Cache-Control 요청 헤더 속성 값을 no-cache로 설정도 해보고, 리액트에서 DOM에 함수 바인딩 방법이 잘못된 것이 아닌가 등...

그러나 결국 문제는 'IE 브라우저의 자체 캐시'기능이었다.

 

IE 브라우저의 웹 사이트 데이터 설정을 들어가보면 캐시 및 데이터베이스 탭이 있고, 이 곳에서 캐시를 허용하는 옵션이 있다.

 

이 옵션이 켜져 있는 경우, 한 번이라도 HTTP GET 메소드 규격으로 통신한 대상은 매번 새로 요청하지 않고 캐싱된 응답을 가져온다.

 

보통 요청 헤더를 보면 다음과 같이 Cookies에 세션 정보를 비롯하여 클라이언트 정보들도 존재한다.

 

요청 헤더에 세션 쿠키가 포함되어 서버에게 요청이 오는 경우 서버에서 세션을 핸들링 할 수 있지만, 클라이언트가 PC에 저장되어 있는 캐싱된 데이터를 가져오는 경우 서버는 실제 요청을 받지 않기 때문에 아무런 작업을 하지 않는다.

 

아래의 그림을 보자.

 

MDN HTTP caching 글의 이미지

난 오늘 브라우저의 캐시 기능으로 인해 문제를 맞딱트렸다.

브라우저의 캐시 기능이니 Local cache의 구조였다.

 

 

실제 캐시는 HTTP GET 메소드 타입에서만 작동하도록 만들어져있다.

MDN HTTP caching 글의 이미지 2

 

로그아웃 기능을 GET 요청으로 만들어놨더니 캐싱되서 요청이 안온거였다. -_-

 

근데 크롬하고 파이어폭스는 정상적으로 작동했는데, 브라우저마다 캐시를 구현하는 방식이나 동작하는 기능이 다른가보다.

 

왜 IE만 다르지..

 

 

평소에 캐시라고 하면 항상 모호한 개념이었는데 오늘을 계기로 확실하게 감이 왔다.