말은 쉽지, 코드를 보여줘!

아파치와 톰캣이 각각 별도로 구성되어 있는 환경에서 GET 요청을 처리하는 API를 만들었다. 파라미터로 한글을 받는데 이게 계속 깨져서 들어왔다. 결국 해결했는데 반나절을 꼬박 날려버려서 해결하는 과정에서 알게된 사실들을 기록한다. URL에 포함된 한글 파라미터는 반드시 인코딩을 할 필요는 없다. 기본적으로 인코딩 하지 않아도 http 프로토콜 내에서 자동으로 인코딩 된다. 명시적으로 인코딩이 필요한 경우는 공백이나 특수문자가 포함된 경우이다. 다만 인코딩을 해서 보내면 아파치에서 그걸 그대로 읽어들이지만 인코딩을 하지 않을 경우 한글을 바이트배열로 인코딩한다. 아무튼 이런 상황에서 톰캣의 server.xml 파일에는 Connector URIEncoding 이 UTF-8로 잘 되어 있었는데 컨트롤러에서..

http 통신에서 한글을 사용한다면 인코딩은 필수이다. 기본적으로 일부 한글과 특수문자, 공백 등의 문자들은 그대로 http 프로토콜에 포함될 수 없고 별도로 인코딩을 해서 보내야 한다. 일반적으로 인터넷 브라우저나 코드상에서 사용하는 RestTemplate 같은 RestClient 에서는 이러한 인코딩을 자동으로 해준다. 인코딩된 데이터를 받는 쪽에서는 역시 디코딩이 필요하다. 이는 일종의 통신규약으로 인코딩과 디코딩의 기준이 되는 문자셋(ISO-8859-1, EUC-KR, UTF-8)은 서로 동일해야 하고 한글을 사용한다면 EUC-KR 또는 UTF-8을 문자셋으로 선택해야 한다. 참고로 ISO-8859-1는 알파벳과 일부 특수기호만을 처리할 수 있고 한글은 처리할 수 없다. 결국 시작은 인코딩인데 P..

둘 다 HTTP 헤더 요소 중 하나인데 각각 구분해서 설명하면 아래와 같다. Content-Type request, response 에 모두 지정할 수 있는 헤더로 전송하는 데이터 형식을 명시한다. HTTP 표준 스펙을 따르는 브라우저와 웹서버는 Content-Type 헤더를 기준으로 HTTP 메시지에 담긴 데이터를 분석해서 파싱한다. 만약 Content-Type 헤더를 지정하지 않는다면 특정한 형식의 데이터일지라도 데이터를 받는 입장에서는 단순히 텍스트 데이터(text/plain)로 받아들인다. Get 방식의 경우 url의 쿼리스트링만으로 데이터 형식을 파악할 수 있기 때문에 굳이 Content-Type 을 지정하지 않아도 되지만 PUT, POST 처럼 메시지를 body 에 넣어서 보낼때는 반드시 지정..

HTTP 프로토콜은 기본적으로 Stateless 하다. 하지만 경우에 따라 클라이언트의 상태를 기억해야 할 수 있고 이때 Cookie가 활용된다. Cookie는 기본적으로 클라이언트에 저장되는 정보이기 때문에 javascript로 아래와 같이 간단하게 생성할 수 있다. document.cookie = "test01=test01"; document.cookie = "test02=test02"; console.log(document.cookie); //test01=test01; test02=test02 이렇게 생성한 Cookie는 크롬브라우저 개발자 도구에서 아래와 같이 확인할 수 있고 Request에 자동으로 포함되어 서버단에서는 아래와 같이 확인할 수 있다. @GetMapping("/hello") pub..

지금은 이렇게들 안하지만 내가 Jsp 로 개발할때는 로그인 처리시 Session을 활용했다. 로그인에 성공하면 Session에 아이디 값을 저장하고 추후 페이지 접근시 마다 Session에 해당 아이디 값이 있는지에 따라 로그인 여부를 체크했다. 이때 아이디 값을 저장하고 읽어오는 방법은 아래와 같았다. Session의 키값은 당연히 동일했다. request.getSession().setAttribute("id", "user01"); request.getSession().getAttribute("id"); 저장하는 구조를 보면 대략 Map과 비슷하고 우리가 아는 Map은 key, value 구조로 되어 있고 key가 중복될 수 없다. 그런데 A유저는 PC브라우저에서 로그인하고 B유저는 모바일브라우저에서 ..

특정페이지로 리다이렉트 시키고 싶은 경우 response.sendRedirect() 메소드를 사용하곤 한다. 그런데 너무 예전에 생각없이 쓰던거라 이제라도 잘못된 지식을 바로 잡고자 한다. 나는 이 메소드를 사용할 경우 암시적으로 프로그램의 흐름이 종료되는 것으로 알고 있었다. 즉, return 과 같은 역할이 기본적으로 포함되어 있다고 착각하고 있었다. 결론부터 말하면 전혀 그렇지 않다. 지금까지 이렇게 착각하고 있어도 아무 문제가 없고 더 찾아보지 않았던 이유가 response.sendRedirect() 를 항상 마지막에 처리했기 때문인데 response.sendRedirect() 메소드는 response 헤더에 어느 페이지로 리다이렉트 하라는 정보를 넣는 것 뿐 실제로 프로그램의 흐름을 종료하진 않..