[Error Handling] Payload Too Large 등 에러코드의 종류

 에러가 발생하면 기록을 남겨야지 해놓고, 막상 에러가 생기면 핸들링하기에만 급급해서 기록할 생각을 못했는데, 이번에는 같이 프로젝트를 진행중인 팀원분께서 궁금해하셔서 좋은기회에 첫 에러핸들 포스팅을 작성해봅니다. 이글을 작성하는 지금 아직 에러핸들링 시작하지 않았고 어떤 문제인지 차근차근 살펴보려 합니다. 근데 왠지 좀 보니까 제가 작성한 코드로 인하여 발생한 문제인 것 같습니다. 제 실수중에서도 너무 보잘것 없다고 말할 수 있는 실수로 생긴 에러라고 생각되며 금방 해결할 수도 있을 것 같아서 글을 쓰면서 해결해보려합니다.

 

 에러가 생긴 근본이유는 조금 하찮다고 말할 수 있겠지만, 이런 메시지를 내 뿜는 에러는 어떤에러인지 공부가 될 것같다고 생각 하였습니다. 에러 이름은 Payload too large라는 에러인데요. 에러는 보통 처음보는 에러가 많지만, 이 녀석도 뭔가 생소한 에러라고 느껴졌습니다. status 숫자는 본인이 직접 설정한 숫자인 413이었습니다. 흔히 쓰이는 400번대로 에러를 설정하면 추후 에러 발생시 내가 만든 에러인지 아닌지 헷갈릴거 같아서 알아보기위해 410번대로 사용하였었던 것으로 기억합니다. 신기한것은 당시에 413에러가 왜 생겼는지 팀원들가 이야기 하던때에, 413이라는 에러코드를 내가 만들어 놓고도 전혀 기억에도 없었었지만, 왠지 "제가 작업 한 것중에 에러가 발생한 것 같습니다."라고 하였던 기억이 있다. 그래서 413에러코드가 프로젝트내에서 설계되었던 에러코드인지 코드내에서 찾아보았고, 본인이 직접 코드를 친 에러였다는 것을 알고 금방 작업을 할 수 있었다.

 

 아무튼 에러메시지 payload too Large. "보내야할 본문의 데이터가 너무 크다" 라고 알려주는 것 같다. 보통 데이터 전송시에 페이로드라는 단어를 사용하는데, 그게 너무 크다고 한다. 코드를 봐보자.

클라에서는 평범하게 헤더에 토큰을 넣어서 서버에 요청을 보낸다. 

서버에서는 정상적인 토큰이 있기만 하다면 true값을 돌려주고, 아니면 에러코드 413을 뱉는다. 여기에서 에러코드 413이 기원된 것이다.

 

 한마디로 내가 짠 코드에서 이 에러코드는 헤더에 토큰이 없습니다~ 하고 알려주는 에러이다.(코드를 짤때 살짝 생각이 들긴했지만, 리뷰하려고 포스트로 옮겨놓고 보니 정말 형편없이 짠 코드같아 부끄럽다. 서버가 클라이언트로 보내는 응답에 boolean값을 보내는 설계는 어디에서도 본적이 없어서 이유는 잘모르겠지만 딱히 잘했다는 느낌이 안드는 코드이다. 솔직히 불린값을 보내 보면서 제대로 받아지는지 테스트해보고, 나름 신박했다고 좋아햇다) 

 

 그런데 왜 payload too Large가 뜬걸까 고민해봤다. 겨우 보내는건 토큰밖에 없는데? 텍스트 몇글자 밖에 되지 않는다.  크다면 얼마나 크다고 그럴까?

 

 검색도 해봤다. 오늘 하루죙일 잠도 3시간밖에 못자게만들고 매달리게한 nginx관련 내용도 나온다(순간 내가 테스트하고 있는 nginx코드를 잘못 커밋 및 PR해서 발생한 에러인줄 알았다). 검색결과에 express도 나온다. 서버에서 통신할때 용량이 몇십메가 급으로 넘어가며 통신량이 커지면 통신이 실패 되고, 해당 에러를 뱉는 경우도 있는 모양이다. 페이로드의 용량에 제한을 줌으로써 해결한다고 한다.

 

 하지만 내 경우와는 완전 상관이 없어서 이상하다고 생각했다. 너무 말이 안되는 에러내용이라 문제는 다른데 있을 것이라 합리적으로 생각했고, 그래서 혹시 413에러코드에 관례적으로 정해진 코드내용이 있는게 아닐까 하고 뇌리에 번뜩였다. 에러코드를 414로 바꾸어 봤다.

 에러 상태코드가 414로 바뀌고 에러메시지도 바뀌었다. URI Too Long. 이거였다! 에러 내용이 무엇인지도 모르면서 그냥 에러 코드에 따라 일종의 미리 맵핑되어 있는 메시지를 출력하도록 되어 있는 것이었다. 우리가 잘못이 덜하더라도 이 친구들은 무자비하게 에러메시지를 내뱉는 것이었다. 아마 여태까지 했던 에러핸들링중에서도 이런게 있었을텐데 엉뚱하게 핸들링 했던 것도 있었겠지..라고 생각했다. 나름 내가 사용한 status코드는 알아보기 위해 410번대를 사용한 것인데, 410번대까지도 전용 에러 코드가 예약되어 있던 것이었다. 생각이 여기까지 미치니 내친김에 각잡고 몇번까지 있나 궁금해졌다. 한번 알아보았다.(지금 글쓰면서 열심히 받아적고있다)

 

400 (Bad Request): 나쁜요청(자주봄)

401 (Unauthorized): 권한없음(자주봄)

402 (Payment Required): 결제 필요

403 (Forbidden): 금지됨(종종 봄)

404 (Not Found): 찾을 수 없음(제일 많이 봄)

405 (Method Not Allowed): 허용되지 않은 방법(처음봄)

406 (Not Acceptable): 허용되지 않음

(407)net::ERR_UNEXPECTED_PROXY_AUTH 406(하다가 신기한 것을 발견했다. 407은 존재하지 않는다. 406도 406이고 407도 406이다. 근데 내용은 틀리다.  찾아보니까 또 오늘 하루죙일 괴롭힌 프록시의 인증필요 라고 한다)

408 (Request Timeout): 요청시간 초과( 많이봤다)

409 (Conflict): 충돌 (P/R하다가 잠깨게 해주는 녀석)

410 (Gone): 사라짐 (빨리 자러가고싶다)

(411) 410 (Gone) (410이 사라짐인데, 411이 사라졌다)

(412) 410 (Gone) (이것도 410)

413 (payload too Large):페이로드 너무 큼

414 (URI Too Long): uri너무김

 

여기까지 하고 있는데, 에러코드를 수정해도 오류메시지가 바뀌지 않는다. 에러를 조사하는데 에러가 발생한 느낌이다.(로컬에서는 오류메시지가 바뀌지 않지만, 배포서버에서는 변경된 내역이 적용되었다. 추측성이지만 해당 에러코드를 할당해주는 횟수가 정해진 모양이다) 이 다음은 다음에 알아보거나 구글링에 맡겨야 겠다. 무튼 이 코드는 토큰이 로컬스토리지에 없기 때문에 생긴 버그이다. 한마디로 로그인을 해서 로컬스토리지에 토큰이 생기는 순간 axios 헤더에 보낼 토큰이 생기게 되기 때문에 자동으로 오류는 사라진다. 일단 위에서 삽질한내용을 토대로 제일 그럴듯한 에러코드를 만들어 주었다. 

토큰이 없는것이기 때문에 권한 없음인 401 (Unauthorized): 권한없음 상태코드를 부여하였다.

 

클라이언트에서 코드자체를 개선해보자면, 소셜로그인이나 자체로그인시 로컬스토리지에 "ATOKEN"이라는 이름을 가진 토큰이 생성되게 되어 있다. 이 코드의 기능은 새로고침시에도 로그인상태를 유지시켜주는 코드이다. 그렇기 때문에 이 코드는 토큰이 있을때만 작동되도록 수정해주면 된다.

왼쪽코드를 if문 감싸준다. 로컬스토리지에 ATOKEN이 있으면서 로그인상태가 참일 경우에만 axios통신을 요청하도록 변경하였다.

 

원래 이랬던 왼쪽 오류화면에서 => 오류가 없이 말끔해진 오른쪽 사진을 볼 수 있다.

 의도치 않는 설계로 꽤 많은 오류코드를 알아가는 시간이었다. 또한 에러코드도 나름 컨벤션을 지켜가며 코드를 할 수 있다면 좋겠다는 생각이 들었다. 또한 이 문제를 궁금해한 팀원으로 인하여 첫 에러핸들링 포스팅을 진행하였는데, 앞으로도 포스팅을 꾸준히 이어나갈 생각이다.

 

끝~읽어주셔서 감사합니다~