sj_.log

[]

Mon, 27 Feb 2023 13:55:11 GMT

[]

Mon, 27 Feb 2023 13:55:04 GMT

[2023.01.06]

Fri, 06 Jan 2023 09:47:59 GMT

[2023.01.05]

Fri, 06 Jan 2023 09:47:43 GMT

[2023.01.04]

Fri, 06 Jan 2023 09:47:26 GMT

[2023.01.03]

Fri, 06 Jan 2023 09:47:12 GMT

[2023.01.02]

Fri, 06 Jan 2023 09:46:56 GMT

[2023.01.01]

Fri, 06 Jan 2023 09:46:40 GMT

[2022.12.30] 간단한 REST API 게시판 구현 - 3

Fri, 06 Jan 2023 09:44:12 GMT

[2022.12.29] 간단한 REST API 게시판 구현 - 2

Fri, 06 Jan 2023 09:43:45 GMT

[2022.12.28] 간단한 REST API 게시판 구현 - 1

Fri, 06 Jan 2023 09:43:03 GMT

[2022.12.27] 스프링 MVC 기본 기능

Fri, 06 Jan 2023 09:38:33 GMT

[2022.12.26] 스프링 MVC 구조

Fri, 06 Jan 2023 09:37:59 GMT

[2022.12.25]

Fri, 06 Jan 2023 09:37:16 GMT

[HTTP] HTTP Header(2) - 캐시와 조건부 요청

Mon, 26 Dec 2022 01:23:33 GMT

캐시 기본 동작

캐시가 없을 때

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
인터넷 네트워크는 매우 느리고 비싸다.
브라우저 로딩 속도가 느리다.
느린 사용자 경험

캐시 적용

캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
비싼 네트워크 사용량을 줄일 수 있다.
브라우저 로딩 속도가 매우 빠르다.
빠른 사용자 경험

max-age: 캐시가 유효한 시간(초)

HTTP/1.1 200 OK Content-Type: image/jpeg
cache-control: max-age=60
Content-Length: 34012

lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjkla
slkjdfl;qkawj9;o4ruawsldkal;skdjfa;ow9ejkl3123123

응답 결과를 캐시에 저장

캐시 시간 초과

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
이때 다시 네트워크 다운로드가 발생한다.

검증 헤더와 조건부 요청1

검증 헤더 추가

검증 헤더와 조건부 요청2

검증 헤더 추가

캐시와 조건부 요청 헤더

캐시 제어 헤더

프록시 캐시

캐시 무효화

Cache-Control

캐시 지시어(directives) - 확실한 캐시 무효화

Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

no-cache vs. must-revalidate

no-cache

캐시 서버 요청 no-cache + ETag
원 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수 있음 Error or 200 OK(오류 보다는 오래된 데이터라도 보여주자)
응답 200 OK

must-revalidate

캐시 서버 요청 must-revalidate + ETag
원 서버에 접근할 수 없는 경우, 항상 오류가 발생해야 함 504 Gateway Timeout (매우 중요한 돈과 관련된 결과로 생각해보자)
응답 504 Gateway Timeout

[HTTP] HTTP Header(1) - 일반 헤더

Mon, 26 Dec 2022 01:23:16 GMT

HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
field-name은 대소문자 구문 없음

용도

HTTP 전송에 필요한 모든 부가정보
e.g.) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보
표준 헤더가 너무 많음
- https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
필요시 임의의 헤더 추가 가능

HTTP Body

메시지 본문(message body)을 통해 표현 데이터 전달
메시지 본문 = 페이로드(payload)
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
- 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

Representation

Content-Type

표현 데이터의 형식 설명

미디어 타입, 문자 인코딩
e.g.)
- text/html; charset=utf-8
- application/json
- image/png

Content-Encoding

표현 데이터 인코딩

표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
e.g.)
- gzip
- deflate
- identity

Content-Language

표현 데이터의 자연 언어

표현 데이터의 자연 언어를 표현
e.g.)
- ko
- en
- en-US

Content-Length

표현 데이터의 길이

바이트 단위
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

Content Negotiation

클라이언트가 선호하는 표현 요청

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

Accept

클라이언트가 선호하는 미디어 타입 전달

Accept-Charset

클라이언트가 선호하는 문자 인코딩

Accept-Encoding

클라이언트가 선호하는 압축 인코딩

Accept-Language

클라이언트가 선호하는 자연 언어

우선 순위

Quality Values(q) 값 사용
0~1, 클수록 높은 우선순위
생략하면 1
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
- 1. ko-KR;q=1 (q생략)
- 1. ko;q=0.9
- 1. en-US;q=0.8
- 1. en:q=0.7
구체적인 것이 우선한다.
Accept: text/*, text/plain, text/plain;format=flowed, /\
- 1. text/plain;format=flowed
- 1. text/plain
- 1. text/*
- 1. /\

전송 방식

단순 전송

Request

GET /event

Response

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8 
Content-Length: 3423

 
    ...

압축 전송

Request

GET /event

Response

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8 
Content-Encoding: gzip Content-Length: 521

lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjkl

분할 전송

Request

GET /event

Response

HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked

5
Hello
5
World
0
\r\n

범위 전송

Request

GET /event
Range: bytes=1001-2000

Response

HTTP/1.1 200 OK
Content-Type: text/plain 
Content-Range: bytes 1001-2000 / 2000

qweqwe1l2iu3019u2oehj1987askjh3q98y

일반 정보

From

유저 에이전트의 이메일 정보

일반적으로 잘 사용되지 않음
검색 엔진 같은 곳에서 주로 사용
요청에서 사용

Referer

이전 웹 페이지 주소

현재 요청된 페이지의 이전 웹 페이지 주소
A ➞ B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
Referer를 사용해서 유입 경로 분석 가능
요청에서 사용
참고: referer는 단어 referrer의 오타

User-Agent

유저 에이전트 애플리케이션 정보

e.g.) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
통계 정보
어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용

Server

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

e.g.) Server: Apache/2.2.22 (Debian)
e.g.) server: nginx
응답에서 사용

Date

메시지가 발생한 날짜와 시간

Date: Tue, 15 Nov 1994 08:12:31 GMT
응답에서 사용

특별한 정보

Host

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

요청에서 사용
필수
하나의 서버가 여러 도메인을 처리해야 할 때
하나의 IP 주소에 여러 도메인이 적용되어 있을 때

Location

페이지 리다이렉션

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

Allow

허용 가능한 HTTP 메서드

405 (Method Not Allowed) 에서 응답에 포함해야함
Allow: GET, HEAD, PUT

Retry-After

유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
Retry-After: 120 (초단위 표기)

인증

Authorization

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

Authorization: Basic xxxxxxxxxxxxxxxx

WWW-Authenticate

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

401 Unauthorized 응답과 함께 사용
WWW-Authenticate: Newauth realm="apps", type=1, title="Login to "apps"", Basic realm="simple"

쿠키

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

예시

로그인 이후 welcome 페이지 접근

Request(쿠키 저장소에서 조회)

GET /welcome HTTP/1.1 
Cookie: user=홍길동

Response

HTTP/1.1 200 OK 

안녕하세요. 홍길동님

모든 요청에 쿠키 정보 자동 포함

GET /welcome HTTP/1.1 
Cookie: user=홍길동

GET /board HTTP/1.1 
Cookie: user=홍길동

GET /order HTTP/1.1 
Cookie: user=홍길동

정리

e.g.) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure
사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹
쿠키 정보는 항상 서버에 전송됨
- 네트워크 트래픽 추가 유발
- 최소한의 정보만 사용(세션 id, 인증 토큰)
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
주의
- 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

생명주기

Expires, max-age

Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
- 만료일이 되면 쿠키 삭제
Set-Cookie: max-age=3600 (3600초)
- 0이나 음수를 지정하면 쿠키 삭제
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

도메인

Domain

e.g.) domain=example.org
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
domain=example.org를 지정해서 쿠키 생성
- example.org는 물론이고
- dev.example.org도 쿠키 접근
생략: 현재 문서 기준 도메인만 적용
- example.org 에서 쿠키를 생성하고 domain 지정을 생략
  - example.org 에서만 쿠키 접근
  - dev.example.org는 쿠키 미접근

경로

Path

e.g.) path=/home
이 경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/ 루트로 지정
e.g.)
- path=/home 지정
- /home ➞ 가능
- /home/level1 ➞ 가능
- /home/level1/level2 ➞ 가능
- /hello ➞ 불가능

보안

Secure

쿠키는 http, https를 구분하지 않고 전송
Secure를 적용하면 https인 경우에만 전송

HttpOnly

XSS 공격 방지
자바스크립트에서 접근 불가(document.cookie)
HTTP 전송에만 사용

SameSite

XSRF 공격 방지
요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

[HTTP] HTTP Status

Mon, 26 Dec 2022 01:22:17 GMT

상태 코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

1xx (Informational): 요청이 수신되어 처리중
2xx (Successful): 요청 정상 처리
3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

1xx(Informational)

요청이 수신되어 처리중

거의 사용하지 않는다.

2xx(Successful)

클라이언트의 요청을 성공적으로 처리

200 OK

요청 성공

201 Created

요청 성공해서 새로운 리소스가 생성됨

202 Accepted

요청이 접수되었으나 처리가 완료되지 않았음

배치 처리 같은 곳에서 사용
e.g.) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

e.g.) 웹 문서 편집기에서 save 버튼
save 버튼의 결과로 아무 내용이 없어도 된다.
save 버튼을 눌러도 같은 화면을 유지해야 한다.
결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

3xx(Redirection)

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

리다이렉션

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

요청 URL: /event

GET /event HTTP/1.1 
Host: localhost:8080

응답

HTTP/1.1 301 Moved Permanently 
Location: /new-event

자동 리다이렉트 URL: /new-event

요청

GET /new-event HTTP/1.1 
Host: localhost:8080

응답
```
HTTP/1.1 200 OK 
...
```

영구 리다이렉션 - 301, 308

리소스의 URI가 영구적으로 이동
원래의 URL를 사용하지 않음
검색 엔진 등에서도 변경 인지
301 Moved Permanently
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
308 Permanent Redirect
- 301과 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시 리다이렉션

주문 완료 후 주문 내역 화면으로 이동

리소스의 URI가 일시적으로 변경
따라서 검색 엔진 등에서 URL을 변경하면 안됨
302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
303 See Other
- 302와 기능은 같음
- 리다이렉트시 요청 메서드가 GET으로 변경
307 Temporary Redirect
- 302와 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)

PRG: Post/Redirect/Get

POST로 주문 후에 웹 브라우저를 새로고침하면?
- 새로고침은 다시 요청
- 중복 주문이 될 수 있다.
POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
새로고침해도 결과 화면을 GET으로 조회
중복 주문 대신에 결과 화면만 GET으로 다시 요청
PRG 이후 리다이렉트
- URL이 이미 POST ➞ GET으로 리다이렉트 됨
- 새로 고침 해도 GET으로 결과 화면만 조회

302, 303, 307

정리
- 302 Found ➞ GET으로 변할 수 있음
- 303 See Other ➞ 메서드가 GET으로 변경
- 307 Temporary Redirect ➞ 메서드가 변하면 안됨
역사
- 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것
- 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림(일부는 다르게 동작)
- 그래서 모호한 302를 대신하는 명확한 303, 307이 등장함(301 대응으로 308도 등장)
현실
- 303, 307을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

기타 리다이렉션

300 Multiple Choices: 안쓴다.
304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
- 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로) - 조건부 GET, HEAD 요청시 사용

4xx(Client Error)

클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
오류의 원인이 클라이언트에 있음
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음

요청 구문, 메시지 등등 오류
클라이언트는 요청 내용을 다시 검토하고, 보내야함
e.g.) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요함

인증(Authentication) 되지 않음
401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
참고
- 인증(Authentication): 본인이 누구인지 확인, (로그인)
- 인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
- 오류 메시지가 Unauthorized 이지만 인증 되지 않음 (이름이 아쉬움)

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
e.g.) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

404 Not Found

요청 리소스를 찾을 수 없음

요청 리소스가 서버에 없음
또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

5xx(Server Error)

서버 문제로 오류 발생
서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등)

500 Internal Server Error

서버 문제로 오류 발생

서버 내부 문제로 오류 발생
애매하면 500 오류

503 Service Unavailable

서비스 이용 불가

서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

[2022.12.23] 프론트 컨트롤러 패턴

Mon, 26 Dec 2022 01:21:57 GMT

[2022.12.22] MVC 패턴

Mon, 26 Dec 2022 01:21:45 GMT

[2022.12.21] 서블릿

Mon, 26 Dec 2022 01:21:31 GMT