네트워크/HTTP (10) 썸네일형 리스트형 [ HTTP 헤더 ] 일반 정보 1. From 유저 에이전트의 이메일 정보 일반적으로 잘 사용되지 않음 검색 엔진 같은 곳에서, 주로 사용 요청에서 사용 2. referer 이전 웹 페이지 주소 현재 요청된 페이지의 이전 웹 페이지 주소 A -> B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청 Referer를 사용해서 유입 경로 분석 가능 요청에서 사용 참고 : referer는 단어 referrer의 오타 3. user - agent 유저 에이전트 애플리케이션 정보 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 클라이언트의.. 협상 및 전송 방식 1. 협상( 콘텐츠 네고시에이션) 클라이언트가 선호하는 표현 요청 Accept : 클라이언트가 선호하는 미디어 타입 전달 Accept-Charset : 클라이언트가 선호하는 문자 인코딩 Accept-Encoding : 클라이언트가 선호하는 압축 인코딩 Accept-Language : 클라이언트가 선호하는 자연 언어 => 협상헤더는 요청시에만 사용 1.1. 협상과 우선순위1 Quality Values(q) 값 사용 Quality Values(q) 값 사용 0~1, 클수록 높은 우선순위 생략하면 1 Accept-Language : ko-KR,ko;q=0.9,en-US;q=0.8,en;1=0.7 1. ko-KR;q=1 (q생략) 2. ko;q=0.9 3. en-US;q=0.8 4. en;1=0.7 1.2 협상.. HTTP 헤더 개요 HTTP 헤더 필드 : field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) field-name은 대소문자 구분 없음 HTTP 헤더의 용도 HTTP 전송에 필요한 모든 부가정보 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...등 표준 헤더가 너무 많음 필요시 임의의 헤더 추가 가능 helloword : hihi HTTP 헤더 과거 표준(RFC2616) 헤더 분류 General 헤더 : 메시지 전체에 적용되는 정보, 예) Connection : close [요청이든 응답이든 다 들어감] Request 헤더 : 요청정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ...) Respon.. HTTP 상태코드 400 VS 500 400대랑 500대의 가장 중요한 차이점은 400대는 클라이언트 요청 오류라 아무리 새로고침해도 에러가 고쳐지지 않지만 500대 에러는 서버문제이기 때문에 서버가 복구되거나 디비가 복구되는 경우 반복 요청시 접근 가능할 수 있다. 서버는 의도적으로 500대 에러를 내면 안된다 만약 20세 미만의 회원가입을 받지 않는다고 했을 때 15세가 회원가입을 신청했을 때 500대 에러를 낸다? 절대 안된다. 400대나 200대로 해결을 해야 한다. 다음은 400번대와 500번에 HTTP 상태코드이다. - 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 요청 구문, 메시지 등등 오류 클라이언트는 요청 내용을 다시 검토하고, 보내야함 예) 요청 파라미터가 잘못되거나, AP.. HTTP 상태코드 : 300번대 오늘은 HTTP 상태코드의 300번대에 대해 알아보겠다. 보통은 리다이렉션을 요청하는 상태코드이다. 300 번대 결과값이 나오는 요청에는 PRG가 있다. ( PRG란 Post/Redirect/Get 의 앞자리만 따온 것) PRG를 사용해야하는 예시를 하나 들어설명해보겠다. 만약 POST로 주문 후에 웹 브라우저를 새로 고침한다고 생각해보자. 새로고침은 다시 요청을 보내고, 중복주문이 될 수 있다. 이 상황을 단계로 나타내보자. 1단계 : 주문을 클라이언트에서 요청한다. (POST) 2단계 : 서버는 주문데이터를 디비에 저장한다. 3단계 : 디비에 저장후 서버는 클라이언트에 성공 메시지를 응답한다. 4단계 : 결과 화면에서 새로고침을 한다.(POST) 5단계 : 또 다시 요청이 클라이언트에서 서버로 들어간.. HTTP API 설계 예시 HTTP API는 예시를 POST기반과 PUT 기반으로 나누어 들수 있다. POST 기반 API 설계 예시 회원 목록 /members -> GET 회원 등록 /members -> POST 회원 조회 /members/{id} -> GET 회원 수정 /members/{id} -> PATCH, PUT, POST 회원 삭제 /members/{id} -> DELETE 여기서 URL(members)은 동사가 아닌 자원 그 자체로 설정해야 한다. 위 예씨를 보면 목록과 등록이 같은 URL인데 이것은 GET과 POST의 차이이다. 단순한 조회의 경우에는 GET을 사용하고 데이터를 등록하거나 수정하는 것 등의 경우에는 PATCH, PUT, POST를 적절히 사용하면 된다. 다음은 PUT 기반의 API 설계 예시이다. 파.. HTTP 상태코드 정리 1xx : 요청이 수신되어 처리중 2xx : 성공 - 200 OK : 요청 성공 - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 - 022 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 3xx : 리다이렉션 - 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) - 301 : Moved Permanently : 리다이렉트 요청시 요청 메서드가 GET으로 변하고, ,본문이 제거 될 수 있음 ( MAY) - 308 Permanent Redirect : 301과 기능은 같음, 리다이렉트 요청 메서드와 본.. HTML Form GET은 조회에만 사용!! > 데이터가 그대로 url에 노출됨 HTML Form 전송은 GET, POST만 지원하기 때문에 이론적인 HTTP API를 설계하기엔 문제가 있다. 같은 URL이라면 GET은 폼 형식 불러올때 사용하고, POST는 폼에 있는 데이터를 서버에 전송할 때 사용하는 것이 좋다. GET은 인수가 쿼리 파라미터로 url에 노출되기 때문에 보안에 취약하다. POST의 경우 HTTP body에 데이터를 넣어서 보내기 때문에 그나마 좀 낫다고 한다.. - HTML Form 데이터 전송 HTML Form submit시 POST 전송 예) 회원 가입, 상품 주문, 데이터 변경 Content-Type: application/x-www-form-urlencoded 사용 form의 내용을 메시지 바디.. 이전 1 2 다음
