Spring Controller 의 View Return redirect 처리

예전에 jsp 에서 데이터를 전송하면 반드시 form submit 을 사용하던 시절....즉, Async 개념이 없던 시절에 CRUD 처리시 화면 관련 중요한 이슈중 하나는 데이터 submit 후 F5(refresh) 시에 Request 에 전송값이 재전송되는 문제였다.

조회는 Request 를 재전송 해도 데이터를 갱신해 주니 문제없었고...아니 오히려 갱신이 안되면 그게 더 문제 였고....

문제는 데이터 변경이 발생하는 CUD 인데....F5 해서 Request의 값이 재전송할 때 입력의 중복 또는 충돌, 수정의 원치 않는 재갱신, 삭제의 재처리 등이 발생한다.

그래서 CUD 가 Controller 에서 발생하면 결과값의 View를 별도로 하나 만들어(공통화면으로) "처리되었습니다." 라는 화면을 하나 만들고 이 화면이 Request 값을 초기화 시켜서 다시 원래의 화면으로 돌려주는 처리를 했다.

즉,

• A 화면 -> CUD 이벤트 발생 -> Controller 에서 정상 처리
• Controller는 결과화면으로 B 화면으로 forward 하면서 Req. 에 A화면 url 저장(돌아갈 주소)
• B 화면으로 화면이 change 되면서 init 에서 "처리되었습니다." 메세지 출력
• Req. 에서 돌아갈 주소를 꺼내서 몇 초뒤 다시 A화면으로 화면 전환

이렇게 하므로써 redirect 를 강제로 구현했다...

Spring Controller 에 return 값을 String 으로 지정하면 해당 View로 이동하게 되는데 이때 기본값은 forward 이다. 즉, CUD 가 발생한 후 String으로 주소를 지정하면 사용자가 F5를 연타하는 순간 엄한 데이터 갱신이 발생한다.

return String을 "redirect://xxxxxxx/xxxx" 로 지정하면 Controller 는 결과 View를 redirect 처리하고 Request 의 재전송에서 안전한다.....

그런데 ...궁금했다....어떻게 서버에서 클라이언트의 재전송을 제어하는 거지? 이거 뭔가 해킹 아님? ...그래서 네트워크를 봤더니....redirect 로 지정하는 순간 http status 값이 200 이 아닌 302 가 떨어진다........응? 이건 뭐지?

찾아봤더니 http status 302 는 브라우저에게 해당 url 로 redirect 하라는 규약 이었다.....(헐...이런게 있었던가...?)

결국 Spring Controller 는 forward 인 경우 http status 를 200 , redirect 인 경우 http status 는 302 를 넘긴다.....브라우저는 200 이면 forward (사실 forward는 서버에서 발생하므로 브라우저는 알 방법이 없고 그냥 HTML 만 받는다), 302 면 해당 URL 로 redirect 를 한다.