칼의 치치

기본 동작 및 설명 Cookie는 웹 브라우저와 웹 서버 간에 정보를 교환하는 작은 데이터 조각입니다. 이 정보는 클라이언트 측에서 관리되며, 주로 세션 상태를 유지하거나 사용자 개인화에 사용됩니다. 1. 서버는 쿠키가 필요하다고 판단하면 set-Cookie : user ~~ response 헤더를 만들어서 넣어준다. 2. 클라이언트는 쿠키를 쿠키저장소에 저장하고 다음부터 모든 request에 쿠키를 자동으로 보내도록 한다. 3. 언제나 다 보낼 수도 없고 보안도 문제가 있다. 따라서 아래와 같이 제약사항을 설정해야 한다. Set-Cookie: user_id=123; Expires=Sat, 01 Jan 2023 00:00:00 GMT; Max-Age=604800; Path=/; Secure; HttpOn..

암호화 : 중간에서 누군가가 읽을 수 없게 변경 복호화 : 암호화 이전의 데이터로 변환 키 : 암호화,복화화를 위한 키 1. OpenSSL 대칭키 생성 예시 대칭키 : 암호화를 하는 쪽과 복호화를 하는 쪽이 동일한 키를 가지고 있어야함 openssl enc -e -des3 -salt -in hello.txt -out nohello.txt => key 입력 openssl enc -d -des3 -in nohello.txt -out hello2.txt => key 입력 2. openssl 비대칭 키 예시 비대칭키 : 키가 2개 , 키를 배달하는 사고가 일어나지 않음 공개키 , 비밀키 A로 암호화 시 B로 복호화 가능 B로 암호화시 A로 복호화 가능 공개키로 암호화한 내용은 개인키로만, 개인키로 암호화한 내용..

HTTP 캐시 반복된 요청에 대해서 리소스를 다시 다운로드 받지 않도록 브라우저 스토리지에 저장된 데이터를 사용하도록 하는 기법 캐시를 저장하는 시간안에 다시 같은 요청이 올 시 저장된 데이터를 사용함 데이터 사용량을 줄이고 데이터 전송 속도를 높일 수 있음 캐시 시간이 초과되면 다시 데이터를 보내주고 캐시 유효시간이 갱신되고 다시 캐시시간이 조회된다. 캐시를 갱신하는 기준이 필요함 검증 헤더와 조건부 요청 캐시가 시간초과과 되었을 시라도 데이터가 변경되지 않을 수 있음 클라이언트와 서버의 데이터가 일치한다는 사실을 확인 할 수 있는 방법이 필요함 1) Last Modifed 1. 클라이언트의 리소스 요청에 따라 서버측에서 Last Modified : UTC (20201112010101) 이라고 보냄 2..

HTTP Header - 요청 / 응답에 대한 일반적인 정보를 담고 있음 1) General 헤더 : 메서지 전체에 적용 2) Request 헤더 : 요청 헤더 3) Response 헤더 : 응답 헤더 4) Entity 헤더 : 컨텐츠 타입 정의 ( JSON ,XML ...) => RFC 723x 이후 부터 Entity 헤더가 표현 헤더로 변함 표현 1) Content - Type : 데이터 형식(Json , img ...) 2) Content - Encoding : gzip, deflate 3) Content - Language : 한국어 ,영어 4) Content - Length 협상 (Content Negotiation) 클라이언트가 서버에게 리소스를 원하는 형태를 요청함 서버는 클라이언트 협상에 ..

GET 리소스 조회 , Body에 데이터 넣지 않음 POST 요청 데이터 처리 , body 에 데이터 존재 => body에 들어온 데이터 처리 ex) "/members => POST처리 할 것" 과 같이 Cilent 와 Server가 약속이 되어 있어야 함 요청된 표현을 처리 PUT 리소스 대체 1. 리소스가 없으면 생성 2. 기존의 리소스가 있으면 대체 => 완전히 대체해서 새로 넣음 3. POST 와 다르게 Resource의 정확한 위치를 Client가 지정하고 메세지를 보냄 PUT 요청시 주의 할 점 1. PUT /user { age : 20 } 요청 2. 서버에 기존 User가 { name : "hi" , age : 30} 로 저장되어 있음 3. 기존의 user 삭제후 { name : null ,..

HTTP 응답 코드 : 클라이언트의 request에 대한 reponse의 종류 코드 200~ 200 : OK 201 (create) : POST요청을 성공해서 새로운 리소스를 만듦 202 (accept) : 배치 프로그램 등에서 당장 동작하지 않으나 요청은 수락됨 (ex : 1시간 뒤에 동작) 204 (no content) : 요청에 성공했으나 되돌려줄 본문이 없음 300~ 영구,일시,특수 리다이렉션 응답코드 영구 리다이렉트 : 주소가 영구히 바뀜 301 (move permently) : 요청 메서드가 GET으로 변하고 본문이 제거 될 수 있음 ( 반드시는 아님) 308 (permently redirect) : 요청메서드가 변하지 않고 본문이 유지됨 301 동작 방식 1. Client -> POST( b..