JArchive 프로그래밍 일기

5. 일반 헤더 

단순한 정보성 헤더에 대해 알아보자.

From 

유저 에이전트의 이메일 정보. 잘 안씀. 검색 엔진 같은 곳에서 크롤링 할 때 주로 쓴다. 

Referer

현재 요청된 페이지의 이전 웹페이지 주소. 엄청 자주 씀. 

Referer를 활용해서 유입 경로를 분석할 수 있다. 

A->B 로 URL이 이동하는 경우, B를 요청할 때 Referer:A를 포함해서 요청한다. 

참고) referer는 referrer의 오타인데. 이미 스펙에 오타 째로 들어가서 범용으로 사용중이다. 

User-Agent 

유저에이전트 애플리케이션 정보 (== 클라이언트 애플리케이션 정보)

서버 입장에서 User-Agent 정보를 활용하면 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있다. 

로그를 비교해서 브라우저 별 통계 정보를 만들 수 있다. 

요청에서 사용하는 헤더다. 

Server 

요청을 처리하는 Origin 서버의 소프트웨어 정보 

HTTP 요청 응답 과정에서 여러 프록시 서버를 거치게 되는데, 실제 요청을 처리해주는 최종 목적지 서버를 origin서버라고 한다. 

응답에서 사용하는 헤더다. 

Date 

메시지가 발생한 날짜와 시간. 응답에서만 사용한다. 

6. 특별한 정보 헤더 

Host 

요청한 호스트 정보(도메인) 

요청에서 사용하는 필수 헤더다. 

하나의 IP 주소에 여러 도메인이 적용되어 있을 때 Host 헤더로 구분하여 서버가 처리할 수 있다. 

가상 호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버가 있다. 여러 애플리케이션이 같은 도메인을 사용할 수 있다. 

Host 헤더를 안쓰면 어떤 문제가 생길까? 

서버가 IP 로만 요청을 인지하면 어느 도메인에 매핑해야 하는 요청인지 알 수 없다.

Location

3xx응답 결과, Location 헤더 필드가 있으면 Location 위치로 리다이렉트 요청한다. 

201의 경우, 생성된 리소스의 URI를 의미한다. 

Allow 

허용 가능한 HTTP 메서드를 적어준다. 실무에서 잘 안씀.

URL경로는 있는데 get, head, put 만 제공하는 경우, 405 코드와 Allow 필드를 응답에 포함해야 한다. 

Retry-After

유저가 다음 요청을 하기까지 기다려야 하는 시간.(날짜 또는 초 단위)

503 코드에서 사용한다. 서비스가 언제까지 불능인지 Retry-After헤더에 시간을 실어서 알려줄 수 있다. 

7. 인증 헤더 

Authorization 

클라이언트 인증 정보를 서버에 전달한다 

인증 매커니즘에 따라 Authorization헤더에 넣을 내용이 달라진다. ex) O-auth, etc 

WWW-Authenticate 

리소스 접근 시 필요한 인증 방법을 정의한다. 

401 오류 발생 시, 이 헤더를 넣어줘야 한다. realm=‘apps’, title=‘example’ 등의 형태를 정의한다. 

8. 쿠키  

쿠키를 안 쓰는 시나리오 

브라우저 : 사용자가 로그인 정보를 서버에 보낸다. 

서버 : 로그인 성공했다고 응답한다. 

브라우저 : '마이페이지' 를 요청한다.  

서버 : (쿠키가 없으니까 요청 주는 사람이 누군지 모름) 누구지? 싶어서 메인 페이지를 응답한다. 

서버가 로그인 사용자를 모르는 이유

HTTP는 무상태 프로토콜이기 때문이다. (Stateless)

클라이언트와 서버가 요청과 응답을 주고받으면 연결이 끊어진다. 

따라서 클라이언트와 서버는 서로 상태를 유지하지 않는다. 

쿠키를 포함한 요청이 아니라면 서버는 이 사람이 로그인 했는지 누군지 모른다. 

그렇다고 모든 요청에 사용자 정보를 포함한다면? 

-> 메뉴를 하나 이동 하더라도 사용자 개인정보를 포함하면, 보안 취약점이 많아진다. 

쿠키를 사용하는 시나리오 

브라우저가 모든 요청에 쿠키를 자동으로 포함하는 방식을 생각해보자. 

로그인 성공 시, 서버는 set-cookie: user=홍길동  이라는 쿠키를 응답해준다. 

서버의 응답을 받은 브라우저는 쿠키 저장소(브라우저 내부)에 이 쿠키를 저장한다. 

브라우저는 요청을 보낼 때 마다 쿠키저장소에서 쿠키를 뒤지고, 있으면 쿠키를 넣어서 HTTP 요청을 보낸다. 

(하지만 이것도 문제점이 있는 방법이다.)

쿠키의 형태

set-cookie: sessionid=abcd123; expires= 26-dec-2021 path=/; domain=google.com

쿠키의 용도

1) 사용자 로그인 세션 관리 
2) 광고 정보 트래킹 

[유의점] 쿠키 정보는 항상 서버에 전송된다!
네트워크 트래픽 추가 유발한다. 그래서 최소한의 정보만 사용해야 한다. (세션 id, 인증 토큰)
서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹스토리지 참고. (localStorage, sessionStorage) 

[주의점]
보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등)

쿠키의 생명주기

expries : 만료일이 되면 쿠기가 자동으로 삭제되게 지정 
max-age : 0이나 음수를 지정하면 쿠키 삭제 

쿠키의 종류 2가지

세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시까지 유지 
영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지 

쿠키 도메인

특정 도메인을 명시하면 : 특정 도메인과 서브 도메인을 포함한 요청 시 해당 쿠키를 보낸다. 
만약 도메인을 생략하면 : 현재 문서 기준 도메인만 적용한다. 

쿠키 경로

이 경로를 포함한 하위 경로 페이지만 쿠키를 접근한다. 
일반적으로 path=/ 루트로 지정한다. 
하나의 도메인 내부의 ‘모든 경로’에서 쿠키를 쓰는 것이 일반적이기 때문이다. 

쿠키와 관련된 보안3가지

1) Secure

Secure를 넣으면 https인 경우에만 쿠키를 서버로 전송한다. 

2) HttpOnly

XSS 공격 방지 

자바스크립트에서 쿠키에 접근 불가하도록 제한한다.  
HTTP 전송에만 사용한다. 

3) SameSite

XSRF 공격 방지 
요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 서버로 전송한다. 
SameSite는 가장 최근에 나온 것이라서 브라우저의 지원 여부를 확인하고 사용하자. 

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다. 

HTTP 헤더 개요 

HTTP 헤더는 양이 많다. 크게 '일반 헤더'와 '캐시와 조건부 요청 관련 헤더'로 분류했다. 

이번 시간은 헤더의 모양, 용도, 스펙에 따른 변화를 알아보자. 

HTTP 헤더의 모양 

헤더필드 

필드이름:필드값 

필드 이름은 대소문자 구분이 없다. 필드값은 띄어 쓰기를 허용한다. 

HTTP 메시지 

스타트 라인 다음에 헤더 내용이 오고, 다음에 메시지 바디가 온다. 

헤더의 용도

HTTP 전송에 필요한 모든 부가정보. 

표준 헤더 내용이 매우 많다. 필요 시 임의의 헤더 필드를 추가할 수 있다. 

RFC 2616 과거의 헤더와 메시지 바디

과거의 헤더 분류는 아래와 같이 4가지다. 

General 헤더, Request 헤더, Response 헤더, Entity 헤더 

과거의 메시지 바디란? 

메시지 본문은 Entity 본문을 전달하는데 사용한다. 

Entity 본문은 요청이나 응답에서 전달할 실제 데이터를 의미한다. 

Entity 헤더는 Entity 본문의 데이터를 해석할 수 있는 정보를 제공한다. 

Entity 를 안쓰고, 표현(Representation) 이라는 용어를 쓰기 시작 

표현 = 표현 메타데이터 + 표현 데이터 

1991년 RFC 2616이 폐기되고, 2015년 RFC7230~7235가 나오면서 많이 변경됬다. 

RFC 7280(최신) 메시지 본문 

메시지 본문(== payload)을 통해 표현 데이터를 전달한다. 

표현은 요청이나 응답에서 잔달할 실제 데이터를 의미한다. 

표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. 

회원 이라는 리소스를 html 형태로 전달할 수 있고, json 형태로 전달할 수도 있다. 

그래서 실제 전달하는 형태를 '표현'이라는 용어로 정의했다. 

1. 표현과 관련된 헤더 

표현 헤더는 요청, 응답 두 경우 모두 사용한다.

표현 헤더 종류 4가지

1. Content-Type 표현 데이터의 형식 

ex) text/html, application/json, image/png, etc.. 

2. Content-Encoding 표현 데이터의 압축 방식 

ex) gzip, deflate, identity(압축 안함)

데이터를 보내는 쪽에서 압축 후 인코딩 헤더를 추가한다. 데이터를 읽는 쪽에서 인코딩 정보를 기반으로 압축을 해제한다. 

3. Content-Language 표현 데이터의 자연 언어 

ex) ko, en, en-us

한국어, 중국어, 영어 모두 제공하는 웹페이지를 떠올려보자. 

4. Content-Length 표현 데이터의 길이(byte 단위)

참고) Transfer-Encoding(전송 인코딩)을 사용하면 Content-Length를 쓰면 안된다.

전송 코딩은 chunk로 나뉘기 때문에 전체 길이가 아니라  chunk 마다의 길이를 포함하기 때문이다. (아래에서 배움)

2. 협상 헤더 ( == 콘텐츠 네고시에이션)

클라이언트가 원하는 표현 우선순위를 서버에 요청한다.  서버는 이것에 가능한 맞춰서 응답을 준다. 

협상 헤더는 요청 시에 만 사용한다. 

1. Accept: 클라이언트가 선호하는 미디어 타입 전달 
2. Accept-Charset: 클라이언트가 선호하는 문자 인코딩 
3. Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
4. Accept-Language: 클라이언트가 선호하는 자연 언어 

Accept-Language 적용 전 시나리오 

클라이언트가 한국에서 브라우저를 이용하는데 외국 사이트에 접속했다. 

다중 언어를 지원하는 서버는 응답을 줄 때 기본으로 영어를 선택한다. 

Accept-Language 적용 후 시나리오 

클라이언트가 Accept-Lanuage: ko 협상 헤더를 담아서 요청한다. 

서버가 한국어를 지원할 수 있다면 한국어를 선택하여 응답을 준다.

협상과 우선순위 (Quality Values) 

협상 헤더의 우선순위 시나리오 예시 

클라이언트가 Accept-Language: ko 협상 헤더를 실어서 요청했다. 
서버는 ko를 지원하지 않는 상황이다. 그리고 서버의 1순위(기본)독일어이고 2순위 영어 를 지원한다. 
클라이언트는 1순위 한국어 2순위 영어 로 응답 받고 싶다. 

1. Quality Values(q)를 사용한다.

Quality Values(q)는 0에서 1까지의 값을 갖는다. 생략하면 1이다. 

클라이언트의 협상 헤더 Accept-Lanuage:ko-KR, ko; 1=0.9, en-US; 1=0.8, en;q=0.7

-> 한국어 1순위로 선호. 2순위로 영어를 선호. 

따라서 서버는 2순위 영어 페이지를 응답해준다. 

2. 구체적인 것이 우선한다.

아래 중에 어떤 것이 우선 적용될까? 우선순위대로 나열해보자. 

text/* , text/plain , text/plain;format=flowed, */* 

[ 우선순위 대로 나열 ]

1순위 text/plain;format=flowed 

2순위 text/plain

3순위 text/* 

4순위 */*

3. 전송 방식 헤더 4가지 

1. 단순 전송 

contents 의 길이를 알고 있을 때 사용한다. 

2. 압축 전송 

content-Encoding: gzip

서버에서 gzip으로 압축했을 때, content-Encoding: gzip 전송 헤더 필드를 넣어서 gzip임을 클라이언트에 알려야한다. 

3. 분할 전송 

Transfer-Encoding: chunked 

큰 데이터를 "길이와 데이터'로 구성된 덩어리(chunk)들로 분할해서 보낸다.

이 때는 content-length 헤더를 넣으면 안된다. 덩어리가 여러개라서 content-length를 모르기 때문이다. 

4. 범위 전송

Range, Content-Range 

클라이언트: "1001부터 2000까지 주세요" 라고 요청 

서버 : "1002부터 2000까지 보냅니다" 라고 응답 

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다. 

4xx 클라이언트 오류 

클라이언트 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 

오류의 원인이 클라이언트에 있다! 

[중요] 4xx 오류인 경우, 재요청해도 실패한다.

이미 요청이 틀렸기 때문이다. 

하지만 서버 문제(5xx)인 경우, 재시도 하면 성공할 가능성이 있다.

서버 또는 DB 문제가 복구되면 받은 요청에 응답할 수 있게 되기 때문이다. 

400 Bad Request 

요청 구문, 파라미터, API 스펙이 맞지 않을 때 클라이언트 오류. 

백엔드 개발자는 모든 입력의 경우의 수를 생각해서 검증로직 validation을 철저히 해야 한다. 

401 Unauthorized

인증 실패. WWW-Authenticate 헤더와 함께 인증 방법을 설명

참고

인증 : 본인이 누구인지 확인(로그인)

인가 : 리소스 접근 권한 확인(일반 유저? 관리자?)

403 Forbidden

인가 실패. 

인증은 됬는데(로그인은 됬지만) 접근할 수 없는 리소스를 요청한 경우.

404 Not Found 

요청 리소스를 찾을 수 없음

클라이언트 요청 url에 오타 있을 수 있다. 

클라이언트가 권한이 없는 리소스에 접근할 때 403임을 숨기고 싶을 때, 일부러 404를 쓰기도 한다. 

5xx 서버 오류 

서버 문제 (NPE, DB 등의 문제)

서버 문제라서 클라이언트가 재시도 몇 번 하면 응답을 받을 수도 있다. 

500 Internal Server Error

서버 내부 문제 전반적으로 500 코드로 처리 

503 Service Unavailable

서비스 이용 불가. 

503보다는 거의 500을 내려준다. 

서버 개발자는 사용자에게 500에러를 보여주면 안된다 

비즈니스 로직에서 예외 처리는 전부 4xx 또는 200으로 해결해서 쌩 500 에러 화면을 보여주지 않도록 하자.  

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다. 

리다이렉션이란? 

요청을 완료하기 위해 클라이언트 프로그램(주로 웹 브라우저)에게 다시 보내는 것

3xx 응답 결과에 Location헤더가 포함되어 있으면 거기에 명시된 URL로 이동한다.

자동 리다이렉트 흐름 예시 

1) 클라이언트 : 이벤트 페이지 /event 요청보냄

2) 서버 : /event 이젠 안씀! 헤더의 Location 필드 실어서 301 코드 응답보냄  Location :/new-event

3) 웹 브라우저가 301코드의 Location 필드를 읽고 URL을  /new-event로 인식. 서버에 /new-event 로 요청보냄 

리다이렉션 3가지 종류 

1. 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동 

2. 일시 리다이렉션 : PRG 패턴. 일시적인 변경 ex) 주문 완료 후 주문 내역 화면으로 리다이렉트 

3. 특수 리다이렉션 : 캐시 만료 여부를 서버에 요청. 캐시를 사용하니까 메시지 바디 쓰면 안됨.

영구 리다이렉션 

301, 308 둘 다 경로가 완전히 바뀌었음을 알려준다. 

리소스의 URI가 영구적으로 이동한다. 검색 엔진 등에서도 변경을 인지한다. 

301: 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수도(MAY)있다. 

308: 리다이렉트 시 요청 메서드와 body의 데이터를 유지한다. 

실무에서는 post로 와도 get으로 돌리는 형태 301로 구현한다. 

새로운 페이지로 가면 페이지의 내용이나 요구하는 데이터가 달라지는 경우가 많기 때문에 post를 유지할 필요가 거의 없기 때문이다. 

일시 리다이렉션 

302를 실무에서 디폴트로 많이 쓴다. 

302는 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도(MAY)있다. 

307 리다이렉트 시 요청 메서드와 본문을 유지한다. 

303 리다이렉트 시 요청 메서드가 GET으로 변경된다. 

[중요] PRG패턴 : Post / Redirect / Get 

Post 로 주문 후에 웹 브라우저를 새로고침 하면 어떻게 될까? 

'새로고침'은 '재요청'과 같다. 따라서 이 경우 새로고침 하면 post를 2번 요청한 것이 되니까 중복 주문이 발생하는 문제가 있다. 

post로 주문 요청 후에, 주문 결과 화면을 get메서드로 리다이렉트 한다. 

이렇게 하면 '새로고침' 해도 post가 아니라 get요청이 되니까 중복 주문을 피할 수 있다. 

그래서 뭘 써야 하나요?

처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었다. 하지만 대부분의 웹브라우저들이 GET으로 바꿔버린다. 

모호한 302를 보완하기 위해 303, 307이 등장한다. 

303, 307을 권장하지만 이미 현실의 많은 애플리케이션 라이브러리들이 302를 디폴트로 사용중이다. 

자동 리다이렉션 시에 GET으로 변해도 되면 302를 써도 문제가 없다. 

기타 리다이렉션 

304 Not Modified 

캐시로 리다이렉트 한다. 엄청 자주 쓴다. 

클라이언트에게 "리소스가 수정되지 않았으니 로컬PC에 저장된 캐시를 재사용하세요" 라고 알리면서 캐시로 리다이렉트 한다. 

캐시로 리다이렉트 하니까 응답에 메시지 바디를 포함하면 안된다. 

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다.