[THM] Web Application Basics - EP.3 (Task 7~8)

TryHackMe - "Web Application Basics". Task 7~8. Write-up + Extra Study!

출처: https://tryhackme.com/room/webapplicationbasics

Web Application Basics

 

[7]  HTTP Response: Status Line and Status Codes

HTTP Response = 사용자의 Request에 대해 서버가 보내는 응답 메시지

- HTTP Response는 Client (사용자)에게 요청의 성공 여부와 함께 실패 시엔 그 원인을 알려줌

- HTTP Response는 status code(상태 코드)와 reason phrase(이유 문구)를 통해 성공 여부와 실패 원인을 알려줌

- status code와 reason phrase는 HTTP Response의 첫 줄인 Status Line(상태 줄)에 들어있음

HTTP Response 예시

HTTP Response 예시를 봤을 때, 가장 첫 번째 줄인 "HTTP/1.1 404 Not Found"가 Status Line입니다.

 

Status Line

- HTTP Response의 가장 윗줄이자 첫째 줄

- 서버가 요청을 어떻게 처리했는지 알려줌

- "HTTP/1.1 404 Not Found" 부분에 해당함

- HTTP의 버전, Status Code(상태 코드), Reason Phrase(이유 문구). 총 3가지를 내용으로 가짐

- 형식을 정리하면,

[HTTP_버전] [Status_Code] [Reason_Phrase]
예시) HTTP/1.1 200 OK

[보충 설명] HTTP Response = Status Line + Headers + Body 구조로 이루어집니다. HTTP Request와 Response의 가장 큰 차이는 첫 줄인 Status Line입니다. Request의 첫 줄은 Request Line이고, Response의 첫 줄은 Status Line입니다. 예시 "HTTP/1.1 404 Not Found"에서  HTTP_Version = "HTTP/1.1" Status Code = "404" Reason Phrase = "Not Found" 입니다.

 

 

[7-1] Status Line의 3가지 구성 요소

1. HTTP Version

 - 사용된 HTTP의 버전을 알려줌

 - Request Line의 HTTP Version과 동일한 내용

 - HTTP/1.1이 가장 널리 사용되는 버전

 - 예시) HTTP/1.1

 

2. Status Code (상태 코드)

 - 세자리 숫자

 - 서버가 요청을 어떻게 처리했는지를 나타냄

 - 사람보다는 기계 (Client)가 판단하기 위한 값

 - 응답을 받은 Client는 Status Code 값을 기준으로 다음 행동을 결정함

 - 100번대부터 500번대까지 있음

 - 가장 앞자리 숫자에 따라 상태 유형이 분류됨

 - 예시) 404, 200

 

3. Reason Phrase (이유 문구)

 - 사람이 읽기 쉬운 짧은 문자열

 - Status Code를 사람이 이해하기 위해 존재함

 - 보조 설명용으로만 쓰이며 실제 처리에는 사용되지 않음

 - 예시) OK, Not Found

 

 

[7-2] Status Codes (상태 코드)

가장 앞자리 숫자에 따라 상태 유형이 분류됩니다.

 

Informational Responses (100–199)

 + 요청을 계속 진행하라는 의미

 + 서버가 요청의 일부를 수신한 뒤, 나머지 처리를 기다리는 중

 

Successful Responses (200–299)

 + 요청이 정상적으로 처리되었음을 의미

 + 서버가 요청을 수행하고, 요청된 데이터를 성공적으로 반환한 상태

 

Redirection Messages (300–399)

 + 요청한 리소스가 다른 위치로 이동했음을 의미

 + 보통 새로운 URL로 리다이렉트(redirect)하도록 지시함

 

Client Error Responses (400–499)

 + 클라이언트 측 요청에 문제가 있음을 의미

 + 예를 들어, 잘못된 URL 입력이나 인증 정보 누락 등이 원인일 수 있음

 

Server Error Responses (500–599)

 + 서버 내부 문제로 인해 요청을 처리할 수 없음을 의미

 + 클라이언트의 요청은 올바르더라도, 서버 측 오류나 과부하 때문에 응답을 보낼 수 없는 상황

 

 

[7-3] 자주 사용되는 Status Code와 Reason Phrase

100 (Continue)

 + 서버가 요청의 첫 부분을 수신했고, 나머지 데이터를 받을 준비가 된 상태

 

200 (OK)

 + 요청이 성공적으로 처리되어, 서버가 요청된 리소스(자원)를 전송한 상태

 

301 (Moved Permanently)

 + 요청한 리소스가 영구적으로 새 URL로 이동된 상태

 + 따라서 앞으로는 새 URL을 사용해야 함

 

404 (Not Found)

 + 서버가 해당 URL에서 요청한 리소스를 찾지 못한 상태

 + 주소 입력이 올바른지 확인할 필요가 있음

 

500 (Internal Server Error)

 + 서버 내부 문제로 인해 요청을 처리하지 못한 상태

[보충 설명] 몇가지 추가해보면, 201 (Created) = 요청으로 인해 새로운 리소스가 생성됨. 주로 POST 요청에서 사용 302 (Found) = 리소스가 일시적으로 이동함 400 (Bad Request) = 잘못된 Request. 파라미터 누락, 문법 오류 등이 원인 401 (Unauthorized) = 인증되자 않아 로그인이 필요한 상태 403 (Forbidden) = 인증은 되었으나 접근 권한이 없음 502 (Bad Gateway) = 서버가 다른 서버로부터 잘못된 응답을 받음 이 정도까지는 알아두면 좋습니다.

 

 

---

[8]  HTTP Response: Headers and Body

HTTP Request와 동일하게 HTTP Response에도 Header와 Body가 존재합니다.

Body 부분의 경우 HTTP Request와 형식이 동일하기에 Header를 중심으로 알아봅시다!

[보충 설명] HTTP Request와 HTTP Response의 Body 형식은 동일한 구조를 사용합니다. Body는 메시지의 데이터 영역이라 요청과 응답 모두에서 사용됩니다. 그래서 둘 다 Body의 형식은 Content-Type 헤더에 의해 결정됩니다. 하지만, Body의 존재 여부가 동일하지는 않습니다. Request가 GET이면 보통 Body가 없습니다. Response는 상태 코드에 따라 Body가 없을 수도 있습니다. Request와 Response는 각각 독립적인 HTTP 메시지입니다. 즉, 한쪽의 Body 존재 여부가 다른 쪽의 Body 존재 여부에 영향을 미치지 않습니다.

 

Response의 Body는 Request와 마찬가지로 HTML, JSON, 이미지 같은 실제 데이터가 저장된 곳입니다.

 

 

[8-1] Response Headers

Response Header = 응답에 대한 중요한 정보를 제공 + Client (사용자)에게 이 정보들의 처리 방법을 알려줌

 

HTTP Response 예시

필수적인 Headers:

- Date

 + 응답이 서버에서 생성된 날짜와 시간

 + ex) Data: Thu, 6 Mar 2025 11:27:33 GMT

 

- Content-Type

 + Client (사용자)에게 HTML이나 JSON 같이 어떤 타입의 컨텐츠를 가졌는지 알려줌

 + UTF-8 같은 character set (문자 인코딩) 정보도 알려줌

 + 이러한 정보들을 알려줌으로 브라우저가 올바르게 정보를 표시하게끔 도와줌

 + ex) Content-Type: application/json; charset=utf-8

 

- Server

 + Request(요청)을 처리한 서버

 + 디버깅엔 유용하지만, 서버의 정보를 담은 만큼 민감하기에 많은 사람들이 제거하거나 모호하게 적어둠

 + ex) Server: nginx/1.15.8

 

 

자주 쓰이는 추가 Headers:

- Set-Cookie

  + 서버가 Client (사용자)에게 쿠키를 보냄

  + 이 쿠키는 Client가 저장했다가 나중에 Request(요청)할 때, 다시 서버에게 보

  + 쿠키는 JavaScript가 접근하기 못하게, HttpOnly 플래그와 HTTPS로만 보낼 수 있게끔 Secure 플래그가 세팅되어야 함

  + ex) Set-Cookie: userId=12345asdfa2

 

- Cache-Control

  + Client (사용자)에게 응답을 cache할 수 있는 기간을 알려줌.

  + 응답 가능한 cache 시간이 지나면 서버에 다시 확인해야됨.

  + Cache (캐시)는 자주 사용하는 데이터를 임시로 저장해 빠르게 접근 가능한 저장 공간! (빠르게 빼서 쓸수 있는 호주머니 느낌)

  + no-cache를 사용하면 민감한 정보가 캐시되는 것을 막을 수 있음.

  + ex) Cache-Control: max-age=100

 

- Location

  + 리소스가 이동했을 때, 다음 행선지가 어디인지 Client (사용자)에게 알려줌.

  + Status Code 300번대인 Redirection 응답에 사용됨.

  + 300번대는 리소스가 다른 장소로 이동했음을 알려주는 역할.

  + ex) Location: /users/documents/data.html

[보충 설명] 자주 쓰이는 추가 Header들은 Client에게 추가 정보를 제공하여 응답을 처리하는데 도움을 줍니다. 말이 추가 Header들이지 필수 Header들만큼 자주 쓰입니다. Connection 헤더도 굉장히 자주 쓰입니다. - Connection = 연결을 유지할지 종료할지 결정 - ex) Connection: keep-alive

 

 

---

[TryHackMe] Web Application Basics - EP.3 (Task 7~8). END.

 

[TryHackMe] Web Application Basics - EP.4 (Task 9~11) 完. Continue...

https://anbymata.tistory.com/45

[THM] Web Application Basics - EP.4 (Task 9~11). 完