HTTP on Kelly Dev

Network. 쿠키, 세션

Sun, 02 Feb 2025 00:00:00 +0000

개요

웹 애플리케이션에서 사용자 정보를 저장하고 관리하는 방식, HTTP는 statelessness이기 때문에, 이전 요청에 대한 정보를 기억하지 않는다. 따라서 이 문제를 해결하기 위해 쿠키와 세션이 필요하다.

쿠키

클라이언트에 저장되는 작은 데이터 파일, 서버가 클라이언트에게 데이터를 저장하도록 지시하면, 해당 데이터를 전송하게 됨

용도

사용자 인증 정보 저장 (로그인 상태 유지)
웹사이트 설정 저장
사용자 행동 추적

특징

주기적 전송: 사용자가 특정 사이트에 다시 방문하면 브라우저가 자동으로 쿠키를 서버로 전송함
수명: 유효 기간을 설정할 수 있고, 만료되면 삭제됨, 유효기간이 없으면 브라우저 세션이 종료될 때 삭제
용량: 한 도메인당 쿠키는 4KB 정도로 제한

보안

사용자의 브라우저에 저장되기 때문에 클라이언트에서 조작할 수 있다. 따라서 민감한 데이터는 쿠키에 저장하면 안됨

Network. REST(Representational State Transfer)

Sat, 01 Feb 2025 00:00:00 +0000

REST

REST: Representational State Transfer
RESTful API: REST를 기반으로 한 API
REST 아키텍처 스타일의 설계 원칙을 준수하는 API

Note.

REST는 HTTP와 동일한 개념이 아니다. REST는 웹 API를 설계하기 위한 아키텍처 스타일이며, HTTP는 REST를 구현할 때 가장 많이 사용하는 프로토콜이다.

설계 원칙

Uniform interface

동일한 리소스에 대한 모든 API 요청은 동일하게 표시되어야 한다(리소스는 단일 URL을 통해 식별할 수 있도록 고유해야 한다). 서버는 표준 형식으로 정보를 전송하고, 형식이 지정된 리소스를 REST에서는 표현(Represent)라고 한다.

SniffMEET. Supabase 세션 갱신 요청이 실패한 이유

Thu, 21 Nov 2024 00:00:00 +0000

문제

Supabase 세션 갱신 요청이 제대로 동작하지 않았다. 세션 로직이나 네트워크 레이어 문제처럼 보였지만, 실제 원인은 요청 형식이었다. 당시 메모는 이랬다.

수정

"grant_type": "refreshToken"

grant_type 값을 Swift식 camelCase로 보내고 있었다. Supabase가 기대하는 값은 refresh_token이었다.

"grant_type": "refresh_token"

body도 마찬가지였다. Supabase가 기대하는 key는 refreshToken이 아니라 refresh_token이었다. refresh 요청에서는 기존 access token의 Authorization 헤더도 제거했다. (토큰을 갱신받기 위한 요청인데, 만료된 토큰을 보내는거니까 아무 의미 없다!)

body: Data("{ \"refresh_token\": \"\(refreshToken)\" }".utf8)
header["Authorization"] = nil

refresh 요청은 기존 access token으로 리소스에 접근하는 요청이 아니라, refresh token으로 새 세션을 발급받는 요청이기 때문이다.

Network. HTTP(HyperText Transfer Protocol)

Thu, 14 Mar 2024 00:00:00 +0000

HTTP

HTTP: HyperText Transfer Protocol

HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 애플리케이션 계층 프로토콜이다.

클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환하는 Request-Response 방식으로 동작한다.

동작 방식

Client
↓ HTTP Request
Server
↓ HTTP Response
Client

특징

Request-Response 방식으로 동작한다.
Stateless를 기본으로 한다.
HTTP/1.x와 HTTP/2는 TCP를 기반으로 동작한다.

버전별 변화

HTTP/1.0

기본적으로 요청마다 연결을 새로 만드는 방식이 널리 사용됐다. 서버에서 여러 파일을 가져올 때 TCP 연결을 반복해서 설정하면 지연이 커질 수 있다. 다만 HTTP/1.0에서도 Connection: keep-alive를 확장 기능으로 사용할 수 있었다.