Skip to content

Latest commit

 

History

History
474 lines (304 loc) · 24.6 KB

03_HTTP_Messages.md

File metadata and controls

474 lines (304 loc) · 24.6 KB
Raw

03장 🐙 HTTP 메시지

📄 퀴즈해설 바로가기

3.1　메시지의 흐름
3.2　메시지의 각 구분
3.3　메서드
3.4　상태 코드
3.5　헤더

3.1 　 메시지의 흐름　 mihykim

  1. 다음 보기 중 알맞은 항목을 바르게 기입하세요 (중복 허용)
    • 보기: 인바운드, 아웃바운드, 업스트림, 다운스트림
    1. 메세지가 원 서버로 향하는 것은 _______(서버 방향)로 이동하는 것이다.
    2. 모든 처리가 끝난 뒤에 메세지가 사용자 에이전트로 돌아오는 것은 _______(사용자 에이전트 방향)로 이동하는 것이다.
    3. 요청 메세지인가 응답 메세지인가에 관계 없이 HTTP메세지는 모두 _______으로 흐른다.
    4. 메세지의 수신자는 발신자의 _______이다.
  2. 메세지는 결코 업스트림으로 흐르지 않는다 (O/X)

📄 답지


3.2 　 메시지의 각 부분　 mihykim

  1. HTTP 메세지의 본문은 비워둘 수도 있다 (O/X)
  2. HTTP 메세지의 헤더는 비워둘 수도 있다 (O/X)
  3. HTTP 메세지는 요청 메세지나 응답 메세지로 분류되며 이 둘의 용도가 다른만큼 기본구조도 상이하다 (O/X)
  4. 다음 보기 중 알맞은 메서드를 골라 기입하고 요청메세지의 본문이 있는지 표시하세요
    • 보기: GET HEAD POST PUT TRACE OPTIONS DELETE
    1. 문서를 제거한다 _____ => 본문 (있음/없음)
    2. 서버에서 어떤 문서에 대해 헤더만 가져온다 _____ => 본문 (있음/없음)
    3. 메세지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다 _____ => 본문 (있음/없음)
    4. 서버가 처리해야 할 데이터를 보낸다 _____ => 본문 (있음/없음)
    5. 서버에 요청메세지의 본문을 저장한다 _____ => 본문 (있음/없음)
    6. 서버에서 어떤 문서를 가져온다 _____ => 본문 (있음/없음)
    7. 서버가 어떤 메서드를 수행할 수 있는지 확인한다 _____ => 본문 (있음/없음)
  5. 다음 보기 중 알맞은 상태코드 분류를 골라 기입하세요
    • 보기: 리다이렉션 클라이언트 에러 서버 에러 정보 성공
    1. 상태코드(100-101) : ________
    2. 상태코드(200-206) : ________
    3. 상태코드(300-305) : ________
    4. 상태코드(400-415) : ________
    5. 상태코드(500-505) : ________
  6. 상태코드 1개당 사유구절 1개가 붙고, 상태코드 404, 사유구절 Unauthorized 는 사용자 이름과 비밀번호를 입력해야한다는 의미이다 (O/X)
  7. HTTP/1.0 애플리케이션이더라도 버전번호가 HTTP/1.1로 된 응답을 받았다면 HTTP/1.1 메세지로 해석해야 한다 (O/X)
  8. 다음 중 더 높은(최신) 버전을 고르시오 (HTTP/2.3, HTTP/2.22)
  9. 최초의 HTTP버전은 HTTP/0.9 이고 그 시절엔 버전정보를 표기하지 않았다. (O/X)

📄 답지


3.3 　 메서드　 daelee

  1. HTTP 버전 1.1과 호환되고자 한다면 서버는 자신의 리소스에 GET 과 POST 메서드만을 구현하는 것만으로도 충분하다. (O / X)
  2. PUT,POST,DELETE 메소드는 서버 리소스를 생성 또는 변경하므로 안전하지 않다. (O / X)
  3. GET, HEAD, OPTION와 같은 안전한 메소드는 캐시가 가능하다. (O / X)
  4. 멱등한 메서드(Idempotent methods)란 몇 번을 호출되더라도 동일한 결과를 리턴하는 메서드를 말한다. 다음 중 멱등한 메서드는?
    • (1) GET
    • (2) POST
    • (3) DELETE
  5. PUT은 리소스를 변경하기 위해 사용되며, 멱등하지 않고, 안전하지 않은 메소드이다. (O / X)
  6. PUT, POST 둘다 데이터를 생성하고 업데이트하는 메소드이지만, (1)________________________과 (2)_____________________에 따라 사용법이 다르다. (두 가지 차이점)
  7. PUT으로 수정할 JSON의 일부분을 보낼 때, 해당 필드만 수정된다. (O / X)

📄 답지


3.4 　 상태 코드　 secho

  1. 성공상태코드인 202는 서버가 요청을 받아들이고 이에 대한 동작을 수행함을 의미한다 ( O / X )
  2. '200' 성공상태코드는 아무런 에러없이 성공적으로 페이지를 불러오거나 데이터를 요청했다는 의미이다. ( O / X )
  3. 리다이렉션 상태코드 중 301 302의 차이는 거의 없다. ( O / X )
  4. 클라이언트 에러 상태코드 중 하나인 403에러는 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다. ( O / X )
  5. 서버에러 상태 코드는 무조건 클라이언트가 잘못된 요청을 보냈기 때문에 발생한다. ( O / X )
  6. 서버에러 상태 코드는 서버측에서만 문제가 있기에 발생하는 에러 코드다. ( O / X )

📄 답지


3.5 　 헤더　 jehong

  1. 일반 헤더 (General header)는 메시지의 종류에 상관없어 클라이언트와 서버 모두가 사용한다. ( O / X )

  2. 다음 중 일반 헤더에 해당되지 않는 것을 하나 고르세요.

    a. Date: 메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다.

    b. MIME-Version: 발송자가 사용한 MIME의 버전을 알려준다.

    c. Expires: 이 엔터티가 더 이상 유효하지 않아 원본을 다시 받아와야 하는 일시

    d. Transfer-Encoding: 수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해준다.

    e. Via: 이 메시지가 어떤 중개자(프락시, 게이트웨이)를 거쳐 왔는지 보여준다.

  3. 요청 메시지에서만 의미를 갖는 _______ 헤더는 누가 요청을 보냈는지에 대한 정보나 클라이언트의 선호 또는 능력에 대한 정보를 주어 서버가 클라이언트에게 더 나은 응답을 주기 위해 활용된다.

  4. 다음 헤더는 무엇을 의미할까요?

    Accept: */*

  5. 클라이언트가 이미 어떤 문서의 사본을 갖고 있으면서 서버에게 그 문서를 요청할 경우, 조건부 요청 헤더 (Conditional request header)를 통해 자신이 갖고 있는 사본과 다를 때만 전송해 달라고 요청할 수 있다. ( O / X )

  6. ( 요청 보안 헤더 / 응답 보안 헤더 )를 사용하면 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 할 수 있다.

  7. _______ 헤더는 응답 메시지에 적용되는 것으로 클라이언트에게 부가정보를 제공해 나중에 더 나은 요청을 할 수 있도록 도와준다.

  8. 서버에 있는 HTML 문서가 한국어, 영어, 중국어로 번역되어 있어 여러 가지 표현이 가능한 상황이라면 HTTP/1.1은 _______ 헤더를 통해 서버와 클라이언트가 어떤 표현을 택할 것인가 고를 수 있도록 지원한다.

  9. 요청 메시지에는 일반 헤더, 요청 헤더, 엔터티 헤더를 함께 사용할 수 있으며 응답 헤더는 사용하면 안된다. ( O / X )

  10. 아래는 실제 응답/요청 메시지에서 헤더들의 일부만 가져온 것입니다. 어느 것이 요청메시지/응답메시지인지 기입하고 무엇때문인지 생각해보세요

    a. _______ 메시지

    Referer: https://www.yebalja.com/

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

    b. _______ 메시지

    Server: nginx/1.10.3 (Ubuntu)

    Date: Sun, 26 Jul 2020 12:25:54 GMT

    X-Powered-By: Next.js

    Content-Type: text/html; charset=utf-8

    ETag: "5d43f-DCYkjUo0QVf5cdUuMYIw1ISaUaM"

    Vary: Accept-Encoding

    Content-Encoding: gzip

    c. _______ 메시지

    Connection: keep-alive

    Upgrade-Insecure-Requests: 1

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

    Accept-Encoding: gzip, deflate

    Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

    Cookie: day1host=h

    d. _______ 메시지

    Date: Sun, 26 Jul 2020 16:23:01 GMT

    Server: Apache

    Last-Modified: Thu, 03 May 2018 02:14:10 GMT

    ETag: "981030-208f-56b43c247cc52"

    Accept-Ranges: bytes

    Content-Length: 8335

    Content-Type: image/png

​

📄 답지



📄 정답 및 해설


3.1 　 메시지의 흐름　 mihykim

  1. 다음 보기 중 알맞은 항목을 바르게 기입하세요 (중복 허용) p50
    • 보기: 인바운드, 아웃바운드, 업스트림, 다운스트림
    1. 메세지가 원 서버로 향하는 것은 인바운드(서버 방향)로 이동하는 것이다.
    2. 모든 처리가 끝난 뒤에 메세지가 사용자 에이전트로 돌아오는 것은 아웃바운드(사용자 에이전트 방향)로 이동하는 것이다.
    3. 요청 메세지인가 응답 메세지인가에 관계 없이 HTTP메세지는 모두 다운스트림으로 흐른다.
    4. 메세지의 수신자는 발신자의 다운스트림이다.
  2. 메세지는 결코 업스트림으로 흐르지 않는다 (O) p51 그림 중

📝 문제


3.2 　 메시지의 각 부분　 mihykim

  1. HTTP 메세지의 본문은 비워둘 수도 있다 (O) p51
    • 시작줄이나 헤더와 달리, 본문은 텍스트나 이진 데이터를 포함할 수도 있고 그냥 비어있을 수도 있다.
  2. HTTP 메세지의 헤더는 비워둘 수도 있다 (X) p54
    • 헤더나 엔터티 본문이 없더라도 HTTP 헤더의 집합은 항상 빈 줄(CRLF)로 끝나야함에 주의한다.
  3. HTTP 메세지는 요청 메세지나 응답 메세지로 분류되며 이 둘의 용도가 다른만큼 기본구조도 상이하다 (X) p52
    • 기본구조는 동일하다.
  4. 다음 보기 중 알맞은 메서드를 골라 기입하고 메세지의 본문이 있는지 표시하세요 p55
    • 보기: GET HEAD POST PUT TRACE OPTIONS DELETE
    1. 문서를 제거한다 DELETE => 본문 (없음)
    2. 서버에서 어떤 문서에 대해 헤더만 가져온다 HEAD => 본문 (없음)
    3. 메세지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다 TRACE => 본문 (없음)
    4. 서버가 처리해야 할 데이터를 보낸다 POST => 본문 (있음)
    5. 서버에 요청메세지의 본문을 저장한다 PUT => 본문 (있음)
    6. 서버에서 어떤 문서를 가져온다 GET => 본문 (없음)
    7. 서버가 어떤 메서드를 수행할 수 있는지 확인한다 OPTIONS => 본문 (없음)
  5. 다음 보기 중 알맞은 상태코드 분류를 골라 기입하세요 p56
    • 보기: 리다이렉션 클라이언트 에러 서버 에러 정보 성공
    1. 상태코드(100-101) : 정보
    2. 상태코드(200-206) : 성공
    3. 상태코드(300-305) : 리다이렉션 - 리소스가 옮겨졌음
    4. 상태코드(400-415) : 클라이언트 에러 - 클라이언트에서 뭔가 잘못된 요청을 했음
    5. 상태코드(500-505) : 서버 에러 - 서버에서 뭔가 실패했음
  6. 상태코드 1개당 사유구절 1개가 붙고, 상태코드 404, 사유구절 Unauthorized 는 사용자 이름과 비밀번호를 입력해야한다는 의미이다 (X) p57
    • 401 Unauthorized / 404 Not Found
  7. HTTP/1.0 애플리케이션이더라도 버전번호가 HTTP/1.1로 된 응답을 받았다면 HTTP/1.1 메세지로 해석해야 한다 (X) p58
    • 버전번호는 어떤 애플리케이션이 지원하는 가장 높은 HTTP버전을 가리킨다.
    • 예를 들어 HTTP/1.1이라는 것은 응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있다는 의미이다.
  8. 다음 중 더 높은(최신) 버전을 고르시오 (HTTP/2.22) p58
  9. 최초의 HTTP버전은 HTTP/0.9 이고 그 시절엔 버전정보를 표기하지 않았다. (O) p60

📝 문제


3.3 　 메서드　 daelee

  1. HTTP 버전 1.1과 호환되고자 한다면 서버는 자신의 리소스에 GET 과 POST 메서드만을 구현하는 것만으로도 충분하다. (X)

  2. PUT,POST,DELETE 메소드는 서버 리소스를 생성 또는 변경하므로 안전하지 않다. (O)

    안전한 메서드(Safe Method)

    안전한 메소드란 서비 측의 상태 정보를 변경하지 않는 메소드를 가리킨다.

    GET v1/coffees/orders/1234
    • 다만, 안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다. 원 목적이 그럴뿐이고 웹 개발자에게 달린 부분.

  3. GET, HEAD, OPTION와 같은 안전한 메소드는 캐시가 가능하다. (O)

    캐시 가능성(Cachable)

    • 향후 재사용을 위해 이에 대한 응답을 저장할 수 있음을 나타낼 수 있다.
    • 일반적으로 현재 시점의 응답이나 권한 있는 응답에 의존하지 않는 안전한 메서드는 캐시 가능한 것으로 정의한다.

  4. **멱등한 메서드(Idempotent methods)**란 몇 번을 호출되더라도 동일한 결과를 리턴하는 메서드를 말한다. 다음 중 멱등한 메서드는?

    • (1) GET

      GET 메소드는 여러 번 호출해도 타킷 리소스는 동일한 응답을 하므로, PUT 메소드는 동일한 리소슷 업데이트하고 이후에도 그 결과가 달라지지 않으므로 멱등하다.

    • (2) POST

      POST는 복수 호출 시 각기 다른 결과가 리턴되거나 새로운 리소스가 계속 만들어질 수 있으므로 멱등하지 않다.

    • (3) DELETE

      DELETE는 처음에 리소스가 삭제되면 더 이상 존재하지 않고 여러 번 호출해도 결과가 달라지지 않기에 멱등하다.

    출처 : RESTful API

  5. PUT은 리소스를 변경하기 위해 사용되며, 멱등하지 않고, 안전하지 않은 메소드이다. (X)

    멱등함. PUT 메소드는 여러 차례 호출해도 동일한 리소스를 변경하므로 결과는 동일한다.

  6. PUT, POST 둘다 데이터를 생성하고 업데이트하는 메소드이지만, (1)________________________과 (2)_____________________에 따라 사용법이 다르다. (두 가지 차이점)

    • Request-URI
    • 멱등성

    PUT, POST 둘다 데이터를 생성하고 업데이트하는 메소드이지만, 메소드의 멱등성과 리소스의 경로에 따라 사용법이 다르다.

    이를테면, POST /v1/coffees/orders는 주문 데이터를 생성한 뒤 생성된 리소스를 가리키는 식별자를 리턴한다.

    반면 PUT /v1/coffees/orders/1234는 주문번호 1234의 리소스가 존재하면 업데이트하고, 존재하지 않을 경우 주문번호가 1234인 데이터를 생성한 뒤 orders.1234를 식별자로 사용한다.

    -> 식별자까지 경로에 지정해줘야함

  7. PUT으로 수정할 JSON의 일부분을 보낼 때, 해당 필드만 수정된다. (X)

PUT과 PETCH의 차이점

  • PUT은 문서 자체의 교체만을 허용한다.
  • PUT으로 수정할 JSON 일부분을 보낼 때, 보낸 필드 이외의 필드는 null 혹은 초기화 처리가 된다.
  • PATCH로 수정할 JSON 일부분을 보낼 때, 해당 필드만 수정된다.

PETCH

  • 리소스의 부분 수정 시 사용된다.
  • PUT과 달리 비멱등성을 가진다.
  • PATCH의 사용 여부는 Accept-Patch로도 가능하다.

📝 문제


3.4 　 상태 코드　 secho

  1. 성공상태코드인 202는 서버가 요청을 받아들이고 이에 대한 동작을 수행함을 의미한다 ( O / X ) - X

    • 요청은 받았으나, 서버는 어떤 동작도 수행하지 않음, 요청이 적법해보일뿐이라는 의미.

  2. '200' 성공상태코드는 아무런 에러없이 성공적으로 페이지를 불러오거나 데이터를 요청했다는 의미이다. ( O / X ) - O

    • 가장 일반적으로 볼 수 있는 HTTP상태

  3. 리다이렉션 상태코드 중 301 302의 차이는 거의 없다. ( O / X )

    • 도메인을 변경하거나 새로운 URL구조로 개편했을 때 사용하는 것. 검색엔진은 301요청을 만나면 컨텐츠가 새로운 URL로 영원히 이동했다고 판단한다. 만약 전자상거래 사이트가 있을 때 물품이 품절되었다고하자, 해당 제품은 인기가 있어서 사이트랭크가 높았는데 301을 사용하거나 페이지의 컨텐츠를 변경하면, 사이트랭크점수가 변경될 것이다. 이럴때 302를 사용하여, 일시적으로 검색엔진은 해당 URL의 사이트랭크는 보존하고, 사용자는 새로운 URL의 컨텐츠를 보게되는 것.

  4. 클라이언트 에러 상태코드 중 하나인 403에러는 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다. ( O / X ) - O

    • 403 Forbidden은 서버가 허용하지 않는 웹 페이지나 미디어를 사용자가 요청할 때 웹 서버가 반환 하는 HTTP 상태 코드이다. 클라이언트가 서버에 도달할 수 있어도 서버가 페이지 접근 허용을 거부했다는 것을 뜻한다.

  5. 서버에러 상태 코드는 무조건 클라이언트가 잘못된 요청을 보냈기 때문에 발생한다. ( O / X ) - X

    • 클라이언트가 올바른 요청을 보냈어도 서버 자체에서 에러가 발생하는 경우가 있다.

  6. 서버에러 상태 코드는 서버측에서만 문제가 있기에 발생하는 에러 코드다. ( O / X ) - X

    • 클라이언트가 서버의 제한에 걸리거나, 게이트웨이 리소스 등 보조 구성요소에서 발생한 에러일 수 있다. 에러의 원인을 클라이언트에게 고스란히 알려주는 것은 보안 사고가 발생할 가능성이 너무 크므로, 500 상태 코드로 에러의 발생 자체만을 알려주는 경우가 대부분이다. 500번대의 코드들은 클라이언트가 아닌 서버에서 뭔가 말썽이 일어난 경우이다. 만약 이 상태 코드를 발견했다면 서버에서 뭔가 박살났다는 의미이므로 다소곳이 백엔드 개발자의 멱살을 잡아보도록 하자. 서버에러

📝 문제


3.5 　 헤더　 jehong

  1. 일반 헤더 (General header)는 메시지의 종류에 상관없어 클라이언트와 서버 모두가 사용한다. ( O / X ) p.76,77

  2. 다음 중 일반 헤더에 해당되지 않는 것을 하나 고르세요. p.77,78

    a. Date: 메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다.

    b. MIME-Version: 발송자가 사용한 MIME의 버전을 알려준다.

    c. Expires: 이 엔터티가 더 이상 유효하지 않아 원본을 다시 받아와야 하는 일시

    엔터티 캐싱 헤더로 엔티티에 대해 설명하는 엔터티 헤더의 한 종류이다.

    d. Transfer-Encoding: 수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 말해준다.

    e. Via: 이 메시지가 어떤 중개자(프락시, 게이트웨이)를 거쳐 왔는지 보여준다.

  3. 요청 메시지에서만 의미를 갖는 요청 헤더는 누가 요청을 보냈는지에 대한 정보나 클라이언트의 선호 또는 능력에 대한 정보를 주어 서버가 클라이언트에게 더 나은 응답을 주기 위해 활용된다. p.78

  4. 다음 헤더는 무엇을 의미할까요? p.77

    Accept: */*

    클라이언트가 자신의 요청에 대응하는 어떤 미디어 타입도 받아들일 것임을 의미한다

  5. 클라이언트가 이미 어떤 문서의 사본을 갖고 있으면서 서버에게 그 문서를 요청할 경우, 조건부 요청 헤더 (Conditional request header)를 통해 자신이 갖고 있는 사본과 다를 때만 전송해 달라고 요청할 수 있다. ( O / X ) p.80

  6. ( 요청 보안 헤더 / 응답 보안 헤더 )를 사용하면 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 할 수 있다. p.80,82

  7. 응답 헤더는 응답 메시지에 적용되는 것으로 클라이언트에게 부가정보를 제공해 나중에 더 나은 요청을 할 수 있도록 도와준다. p.81

  8. 서버에 있는 HTML 문서가 한국어, 영어, 중국어로 번역되어 있어 여러 가지 표현이 가능한 상황이라면 HTTP/1.1은 협상 헤더를 통해 서버와 클라이언트가 어떤 표현을 택할 것인가 고를 수 있도록 지원한다. p.81,82

  9. 요청 메시지에는 일반 헤더, 요청 헤더, 엔터티 헤더를 함께 사용할 수 있으며 응답 헤더는 사용하면 안된다. ( O / X ) p.77,82

  10. 아래는 실제 응답/요청 메시지에서 헤더들의 일부만 가져온 것입니다. 어느 것이 요청메시지/응답메시지인지 기입하고 무엇때문인지 생각해보세요

    a. 요청 메시지

    Referer: https://www.yebalja.com/

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

    • Referer 현재의 요청 URI가 들어있었던 문서의 URL을 제공하는 요청 헤더
    • User-Agent 요청을 보낸 애플리케이션의 이름을 서버에게 말해주는 요청 헤더

    b. 응답 메시지

    Server: nginx/1.10.3 (Ubuntu)

    Date: Sun, 26 Jul 2020 12:25:54 GMT

    Content-Type: text/html; charset=utf-8

    ETag: "5d43f-DCYkjUo0QVf5cdUuMYIw1ISaUaM"

    Vary: Accept-Encoding

    Content-Encoding: gzip

    • Server 서버 어플리케이션의 이름과 버전을 알려주는 응답 헤더
    • Vary 서버가 확인해 보아야 하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더의 목록을 알려주는 협상 헤더: 서버에게 서버가 보내도 되는 인코딩을 말해주는 Accept 헤더

    c. 요청 메시지

    Connection: keep-alive

    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9

    Accept-Encoding: gzip, deflate

    Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

    • User-Agent 요청을 보낸 애플리케이션의 이름을 서버에게 말해주는 요청 헤더
    • Accept 서버에게 서버가 보내도 되는 미디어 종류를 말해주는 Accept 헤더
    • Accept-Endocing 서버에게 서버가 보내도 되는 인코딩을 말해주는 Accept 관련 헤더
    • Accept-Language 서버에게 서버가 보내도 되는 언어를 말해주는 Accept 관련 헤더

    d. 응답 메시지

    Date: Sun, 26 Jul 2020 16:23:01 GMT

    Server: Apache

    Last-Modified: Thu, 03 May 2018 02:14:10 GMT

    ETag: "981030-208f-56b43c247cc52"

    Accept-Ranges: bytes

    Content-Length: 8335

    Content-Type: image/png

    • Server 서버 어플리케이션의 이름과 버전을 알려주는 응답 헤더
    • Accept-Ranges 서버가 자원에 대해 받아들일 수 있는 범위의 형태를 알려주는 협상 헤더

📝 문제


맨위로　📄 퀴즈해설 바로가기