HTTP 메시지

dragonappear·2023년 3월 9일
0

HTTP 완벽 가이드

목록 보기
2/3

헷갈리거나 가끔씩 구글링하는 내용들 위주로 정리

방향

  • HTTP 메시지는 응답/요청 상관없이 다운스트림으로 흐른다.
  • 결코 업스트림으로 흐르지 않음.
    • 클라이언트 -> 프록시1 -> 프록시2 -> 프록시3 -> 서버
    • 클라이언트 <- 프록시1 <- 프록시2 <- 프록시3 <- 서버

구조


  • 요청/응답 메시지 모두 시작줄, 헤더 블록, 본문 세 부분으로 구성되어있다.
  • 헤더나 엔티티가 없더라도, HTTP 헤더 부분은 CRLF로 끝나야 한다.

헤더

  • 이름,쉼표,공백(option),필드 값, CRLF가 순서대로 등장

메서드

  • GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려주고, 엔티티 본문은 담아주지 않는다.
  • 주로 아래와 같은 이유로 사용한다.
    • 리소스를 가져오지 않고도 리소스의 타입을 알고 싶을때
    • 응답의 상태 코드를 통해, 리소스가 존재하는지 확인하고 싶을때
    • 헤더를 확인하여 리소스가 변경되었는지 검사하고 싶을때

PUT

  • 리소스가 있으면 새로운 리소스로 대체하고, 리소스가 없으면 생성한다.
  • POST 와 차이점은 PUT은 요청하는 클라이언트가 리소스 위치를 알고 URL을 지정하여 요청해야 한다.
  • 성공적으로 요청을 완료하였을 경우, 응답 메시지의 Location 헤더에 리소스 URL 담아서 응답

PATCH

  • 리소스를 부분 변경한다.
  • PUT과 달리 리소스가 있어도 새로운 리소스로 대체하지 않고, 부분적으로 기존에 있던 리소스를 변경한다.

DELETE

  • HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용한다.

Safe Method

  • 호출해도 리소스가 변경되지 않는다.
  • GET,HEAD 메서드는 응답 메시지를 요청만 할 뿐, 리소스 변경을 요청하는 메서드가 아니다.

멱등 메서드

  • POST: 여러번 호출하면 중복된 데이터가 생성될 수 있으므로 멱등 메서드가 아니다.
  • f(f(x)) = f(x)
  • 한 번 호출하던 두 번 호출하던 결과가 똑같다.
  • 여러번 수행된 동일한 작업이 동일한 결과를 가져오고 의도하지 않은 부작용을 일으키지 않기 때문에, 멱등 메서드는 어떠한 해를 끼치지 않고 재시도하거나 반복할 수 있다.
    • 분산 시스템에서 네트워크 장애가 발생하여 클라이언트가 요청을 재시도를 할 때, 멱등 메서드는 부작용에 대한 두려움 없이 요청을 재시도하거나 병렬로 처리할 수 있어 성능과 확장성을 향상시킬 수 있다.

캐시 가능 메서드

  • 응답 결과 리소스를 캐시해서 사용해도 되는 메서드
  • 실제로는 GET,HEAD 정도만 캐시로 사용

상태코드

2xx: 성공 상태

  • 201 Created
    • 새로운 개체를 생성하라(ex:PUT)에 대한 응답
    • 응답은 생성된 리소스에 대한 Location 헤더와 함께
    • 서버는 상태 코드를 보내기에 앞서 반드시 객체를 생성해야 한다.
  • 202 Accepted
    • 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다.

3xx: 리다이렉션

영구 redirection: 301,308

  • 리소스의 URL이 영구적으로 이동했을때

  • 서버는 응답할 때, 현재 리소스가 존재하고 있는 URL을 포함해야 함.

  • 브라우저는 이후 요청에서 원래 URL 사용하지 않고, 변경된 URL 사용한다.

  • 301 Moved Permanently

    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있다. (될수도있다~)
  • 308 Permanent Redirect

    • 301과 같은 기능
    • 리다이렉트시 처음 요청 메서드와 본문 유지

일시 redirection : 302,303,307

  • 리소스의 URL이 일시적으로 이동했을때

  • 서버는 응답할 때, 현재 리소스가 존재하고 있는 URL을 포함해야 함.

  • 브라우저는 이후의 요청에서는 원래의 URL을 사용해야 함

  • 302 FOUND(HTTP/1.0)

    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있다. (될수도있다~)
  • 307 Temporary Redirect(HTTP/1.1)

    • 302와 같은 기능
    • 리다이렉트시 처음 요청 메서드와 본문 유지(요청 메서드가 변경되면 안됨)
  • 303 See Other(HTTP/1.1)

    • 302와 같은 기능
    • 리다이렉트시 요청 메서드가 GET으로 변경

PRG에서 어떤 것을 사용해야 할까

  • 일단 POST 이후에는 일시 Redirection을 사용한다.

  • 302는 요청 메서드가 GET으로 변경될 수도 있고, 안될수도 있다.

    • 원래 302 스펙의 의도는 HTTP 메서드를 유지하는 것인데, 웹 브라우저들이 대부분 GET으로 바꾸어 버리기 때문에, 애매모호 하다.
    • 모호한 302를 대신하는 HTTP/1.1에서 303,307이 등장하였는데, 이미 많은 어플리케이션 라이브러리에서는 302를 기본값으로 사용하고 있다
      • HTTP 스펙에서는 303,307을 권장한다고 한다.
    • 자동 리다이렉션시에 GET으로 변경되어도 상관이 없으면 그냥 302로 사용해도 큰 문제가 없다.

캐시: 304

  • 304 Not Modified
    • 캐시를 목적으로 사용
    • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라이언트는 로컬에 저장된 캐시를 재사용
    • 304 응답 바디에 데이터를 실어서 주면 안된다.

0개의 댓글