개발자되기 프로젝트

Host: 요청한 호스트 정보(도메인) Location: 페이지 리다이렉션 Allow: 허용 가능한 HTTP 메서드 Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간 1. Host: 요청한 호스트 정보(도메인) 진짜 중요함 GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com 요청에서 사용 필수! 하나의 서버가 여러 도메인을 처리해야 할 때 사용 하나의 ip 주소에 여러 도메인이 적용되었을 때 구분해 줌. 2. Location : 페이지 리다이렉션 웹 브라우저는 3xxx응답 결과에 Location 헤더가 있으면 location 위치로 자동 이동 201(Created)의 Location 값은 요청에 의해 생성된 리로스의 URI 3..

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

단순 전송 압축 전송 분할 전송 범위 전송 1. 단순 전송 Content-Length를 지정 서버에서 message body의 Content-Length를 딱 지정함. content length 알 수 있을 때 사용 가능. 단순하게 한번에 요청하고 한 번에 받음 2. 압축 전송 서버에서 gzip같이 압축해서 전송함 Content-Encoding: 내용 추가해줘야함 3. 분할 전송 Transfer-Encoding: chunked Content-Length 넣으면 안됨. 각 chunked마다 몇 바이트인지 알 수 있음 몇바이트? 내용 몇바이트? 내용 0 \r\n ex 5 hello 5 world 0 \r\n : 엔터 4. 범위 전송 Range, Content-Range 요청을 보낼 때 범위를 지정해서 요청할..

1. 콘텐츠 협상(Content Negotiation)이란? 클라이언트가 선호하는 표현 요청 Accept : 클라이언트가 선호하는 미디어 타입 전달 Accept-Charset: 클라이언트가 선호하는 문자 인코딩 Accept-Encoding: 클라이언트가 선호하는 압축 인코딩 Accpet-Language: 클라이언트가 선호하는 자연 언어 협상 헤더는 요청시에만 사용! 2. 협상과 우선순위1 : Quality Values 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..

왜 전송할 데이터를 표현이라함..? ex) 회원 리소스를 html로 표현! Json으로 표현! 한다는 의미임. Content-Type: 표현 데이터의 형식 Content-Encoding: 표현 데이터의 압축 방식 Content-Language: 표현 데이터의 자연 언어 Content-Length: 표현 데이터의 길이 표현 헤더는 전송, 응답 둘 다 사용. 1.Content-Type : 표현 데이터의 형식 설명 미디어 타입, 문자 인코딩 Content-Type: text/html; charset=utf-8 Content-Type: application/json Content-Type: image/png 2. Content-Encoding : 표현 데이터 인코딩 표현 데이터를 압축하기 위해 사용 데이터를 전..

1. HTTP 헤더 개요 header-field = field-name ":" OWS field-value OWS field-name은 대소문자 구분 없음 HTTP 전송에 필요한 모든 부가정보 메시지 바디 내용, 바디 크기, 압축, 인증 드으ㅡ드으드ㅡ으드으등 표준 헤더 너무 많음... 2. 헤더 분류 - RFC2612(과거) General 헤더: 메시지 전체에 적용되는 정보, Connection: close Request 헤더: 요청 정보, User-Agent: Mozilla/5.0 Response 헤더: 응답 정보, Server: Apache Entity 헤더: 엔티티 바디 정보, Content-Type: text/html, Content-length: 3423 3. HTTP BODY - RFC2612..

1. HTTP 상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1XX(Informational) : 요청이 수신되어 처리 중~ 2XX(Successful) : 요청 정상 처리 3XX(Redirection) : 요청을 완료려면 추가 행동이 필요 4XX(Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 클라이언트가 범인 5XX(Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함. 서버가 범인 2. "만약 모르는 상태 코드가 나타나면..?" 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면...?어떻게 이해함..? 클라이언트는 상위 상태코드로 해석해서 처리 299 뭔데??? --> 2xx 처리 451 뭐고??? ..

HTTP API - 컬렉션 - POST 기반 등록 - 회원 관리 API 제공 HTTP API - 스토어 - PUT 기반 등록 - 정적 컨텐츠 관리, 원격 파일 관리 HTML FORM 사용 - 웹 페이지 회원 관리 - GET, POST만 지원 1. 회원 관리 시스템 API 설계 - POST 기반 등록 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE 2. POST 기반 등록 클라이언트는 등록될 리소스의 URI를 몰라!!!! - 클라이언트는 데이터만 줌 ㅋㅋ - 회원 등록 / members -> POST -..