Dev

캐시 제어 헤더 • Cache-Control: 캐시 제어 • Pragma: 캐시 제어(하위 호환) • Expires: 캐시 유효 기간(하위 호환) Cache-Control 캐시 지시어(directives) • Cache-Control: max-age • 캐시 유효 시간, 초 단위 • Cache-Control: no-cache • 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용 • Cache-Control: no-store • 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제) Pragma 캐시 제어(하위 호환) • Pragma: no-cache • HTTP 1.0 하위 호환 • 지금은 거의 사용하지 않음, 하위 호환이 필요하면 사용하기도 한다 E..

검증 헤더와 조건부 요청 검증 헤더 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 Last-Modified , ETag 조건부 요청 헤더 검증 헤더로 조건에 따른 분기 If-Modified-Since: Last-Modified 사용 If-None-Match: ETag 사용 조건이 만족하면 200 OK 조건이 만족하지 않으면 304 Not Modified 검증 헤더와 조건부 요청 If-Modified-Since: 이후에 데이터가 수정되었으면? • 데이터 미변경 예시 • 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00 • 304 Not Modified, 헤더 데이터만 전송(BODY 미포함) • 전송 용량 0.1M (헤더 0.1M) 데이터 변경 예시 ..

클라이언트에서 서버에 다시 요청하면 2가지 상황이 나타난다. 다시 요청했더니 서버에서 다른 이미지를 줬을때 (데이터가 바뀐것) 이러면 당연히 데이터를 바꿔서 클라이언트에게 보여줘야한다. 그런데 60초 초과해서 다시 요청했더니 데이터가 똑같다면? 기존이랑 똑같은 이미지를 처음부터 다시 다운받는거면? 용량이 1메가가 되는 처음부터 다시 다운받을 필요가 있을까? 이걸 해결하는게 검증 헤더와 조건부 요청이다. 데이터가 안바뀌었단 사실 검증할 방법 필요 데이터가 마지막에 수정된 최종수정일을 Last-Modified에 넣어둔다. 60초가 지나서 다시 요청 보내기전에 Last-Modified가 있으면 서버에서 수정날짜를 보고 판단한다. 수정이 안됐으면 HTTP 응답을 만들때 304 Not Modified로 응답한다...

캐시가 없으면 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야한다. 인터넷 네트워크는 매우 느리고 비싸다 브라우저 로딩 속도가 느리다 느린 사용자 경험을 하게된다. 서버에서 캐시와 관련된걸 적용 해야한다. cache-control을 서버에서 넣어줄수 있다. (응답이 내려가면 60초동안은 캐시가 유효하단 뜻) 웹브라우저 내부에는 캐시를 저장할수 있는 저장고가 있다. 거기에 캐시를 저장해놓고 2번째 요청할때 캐시를 먼저 찾는다. 거기에 데이터가 있으면 캐시에 있는 데이터를 사용한다. 캐시 덕분에 네트워크를 아에 탈 필요가 없어지는것이다. 캐시 적용 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르..

쿠키 Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답) Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달 쿠키를 사용할때 이 2개의 헤더를 사용함 서버입장에서 로그인한 사용자인지 구별할 방법이 없음. Stateless HTTP는 무상태(Stateless) 프로토콜이다. 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다. 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다. 클라이언트와 서버는 서로 상태를 유지하지 않는다. 사용자정보를 계속 서버에주면 서버는 그걸 받아서 하는방법이 있다. 하지만 이 방법은 심각한 문제가 있다. 모든 요청에 사용자 정보를 넣어야한다는것이다. 개발하기도 힘들고, 보안에도 안좋다. 개발자가 모든 요청에 사용..

인증 Authorization: 클라이언트 인증 정보를 서버에 전달 WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의 Authorization 클라이언트 인증 정보를 서버에 전달 Authorization: Basic xxxxxxxxxxxxxxxx WWW-Authenticate 리소스 접근시 필요한 인증 방법 정의 리소스 접근시 필요한 인증 방법 정의 401 Unauthorized 응답과 함께 사용 (401에러가 날때 아래 Header를 넣어줘야함) WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

특별한 정보 Host: 요청한 호스트 정보(도메인) Location: 페이지 리다이렉션 Allow: 허용 가능한 HTTP 메서드 Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 Host 요청한 호스트 정보(도메인) 요청에서 사용 필수 하나의 서버가 여러 도메인을 처리해야 할 때 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 Location 페이지 리다이렉션 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트) 응답코드 3xx에서 설명 201 (Created): Location 값은 요청에 의해 생성된 리소스 URI 3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대..

일반정보 From: 유저 에이전트의 이메일 정보 Referer: 이전 웹 페이지 주소 User-Agent: 유저 에이전트 애플리케이션 정보 Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보 Date: 메시지가 생성된 날짜 From 유저 에이전트의 이메일 정보 일반적으로 잘 사용되지 않음 검색 엔진 같은곳에서 주로 사용 요청에서 사용 Referer 이전 웹 페이지 주소 현재 요청된 페이지의 이전 웹 페이지 주소 A → B로 이동하는 경우 B를 요청할때 Referer: A를 포함해서 요청 Referer를 사용해서 유입 경로 분석 가능 요청에서 사용 참고: referer는 단어 referrer의 오타 그냥 현재 페이지 오기 전 이전사이트 알려주는것 User-Agent 유저 에이전트 애플리케이션 정보..

전송 방식 설명 단순 전송 압축 전송 분할 전송 범위 전송 컨텐츠에 대한 길이를 알고 있을때 사용 한번에 요청하고 한번에 다 받음 대신 이 경우에는 Content-Encoding을 추가로 넣어줘야함 그래야 클라이언트가 받아서 품 0 \r\n 이 끝이라는 의미, 분할전송 때는 Content-length를 보내면 안됨

협상 (콘텐츠 네고시에이션) 클라이언트가 선호하는 표현 요청 • Accept: 클라이언트가 선호하는 미디어 타입 전달 • Accept-Charset: 클라이언트가 선호하는 문자 인코딩 • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 • Accept-Language: 클라이언트가 선호하는 자연 언어 • 협상 헤더는 요청시에만 사용 협상과 우선순위1 Quality Values(q) • 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생략) • 2. ko;q=0.9 • 3. en-US;q=0.8 • 4. en;q=0.7 ..