Steady and right

(참고: Spring Boot와 Thymeleaf를 기준으로 작성된 글입니다) HTML Form 전송 방식 HTML Form을 통한 파일 업로드를 이해하기 위해서는 두 가지 방식의 차이를 알아야 한다 • application/x-www-form-urlencoded //kim //20 전송 application/x-www-form-urlencoded 방식은 HTML 폼 데이터를 서버로 전송하는 가장 기본적인 방법이다, Form 태그에 별도의 enctype옵션이 없다면 웹 브라우저는 요청 HTTP의 헤더에 다음과 같이 추가하여, 폼에 입력한 항목을 HTTP 바디와 함께 전송한다 POST/save HTTP/1.1 Host:localhost:8080 Content-Type:application/x-www-for..

(참고: Spring Boot, Thymeleaf, Gradle을 기준으로 작성된 글입니다.) 웹 애플리케이션의 경우 클라이언트가 보내는 데이터와 서버에서 다시 반환하는 데이터 간의 타입이 불일치하는 경우가 빈번하게 발생한다, 예를 들어 String으로 보낸 데이터를(HTTP 요청 파라미터의 경우 모두 문자 타입으로 처리됨) int타입으로 변환해야 한다던지, 보낸 데이터를 개발자가 지정한 객체에 담아서 받는 상황이 대표적인 경우다 Converter Interface 이러한 변환 과정을 편리하게 사용할 수 있도록 스프링은 기본적으로 컨버터를 적용시키지만 개발자가 직접 원하는 타입으로 변환을 위하여 컨버터 인터페이스의 구현체를 만들 수도 있다 package org.springframework.core.con..

(참고: Spring Boot를 기준으로 작성된 글입니다) HTML 페이지 vs API 오류 단순히 HTML 웹페이지를 반환하였던 오류의 경우에는 스프링 부트가 제공하는 BasicErrorController로 충분하였다, 404 혹은 4xx의 오류코드만 확인하여 해당 HTML을 클라이언트(사용자)에게 반환해주었으면 그만이니 말이다 하지만 API의 경우 이것보다 훨씬 세밀하고 복잡한 상황을 마주한다, API 같은 경우는 안드로이드와 아이폰 혹은 기업과 기업 간의 다양한 객체들이 소통하며 각기 다른 조건과 요구사항을 만족하여 오류처리를 하여야 하기 때문이다 예를 들어 회원관리에서만 발생하는 오류와, 상품관리에서만 발생하는 오류를 각각 묶어서 처리하고 싶다면 기존의 단순히 HTML을 반환하는 오류처리와는 다르..

(참고: Spring Boot와 Thymeleaf 그리고 IntelliJ(Gradle)를 기준으로 작성된 글입니다) Error Pages 클라이언트(사용자)가 잘못된 데이터를 입력하여 Form을 전송하거나, 잘못된 요청을 보내 에러가 나는 경우가 있다 (404, 500 등등) 이때 클라이언트에게 조금 더 사용자 친화적인 오류 페이지를 보여주는 게 좋다 스프링 부트로 매우 간단하게 설정할 수 있지만 그전에 이 오류 페이지를 띄우기 위해서 서버에서의 작동원리를 먼저 살펴보고자 한다 Servlet Container의 예외 흐름 보통 예외가 발생하는 경우는 클라이언트가 웹 애플리케이션에 요청을 하였을때, 애플리케이션은 스레드를 할당하여 해당 로직을 수행한다, 이때 예외가 발생하게 된다면 try ~ catch로 ..

Filter와 Interceptor가 필요한 이유 로그인과 로그를 찍는 작업을 비롯하여 하나의 컨트롤러(핸들러)에게만 적용하는 것이 아닌, 서비스 단위로 공통적으로 처리해야 하는 작업들이 있다. AOP가 공통 관심사를 처리하는 역할을 했지만 웹 관련된 공통 관심사에 적용할 때는 HTTP 헤더 및 URL을 이용하여야 하기 때문에, 서블릿이 제공하는 필터 혹은 스프링의 인터셉터를 사용하는 것이 더 좋다 Servlet Filter 서블릿이 지원하는 Filter는 무언가를 여과시켜주는 필터처럼 클라이언트가 요청하는 호출을 컨트롤러단에 가기전에 미리 살펴보아 필터 처리를 해준다 필터의 흐름은 아래와 같다 • 필터 흐름 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤 만약 로그인을 검증하는 필터를 만..

(참고 : Spring Boot와 IntelliJ를 기준으로 작성된 글입니다.) Cookie 클라이언트(사용자)가 로그인을 하였을 때 가장 핵심은 서버와의 상태를 유지시켜야 한다는 것이다 기본적으로 비연결성을 유지하는 HTTP의 특성상, 상태를 유지시켜주기 위해서 Cookie와 Session을 사용한다 쿠키를 사용하여 연결상태를 유지시키는 과정은 대략적으로 아래와 같다 하지만 쿠키만 사용 할 시 아래와 같은 문제점이 있다 1. 클라이언트쪽에서 쿠키의 값을 변경할 수 있다 (쉬운 규칙으로 이루어져 있다면 다른 쿠키값으로 접근을 할 수 있다) 2. 쿠키에 보관된 정보를 훔쳐갈 수 있다 3. 쿠키를 한번 훔쳐가면 평생 사용할 수 있다 Session 위에서 살펴본 문제점들을 해결하기 위하여 Session을 사용..