HTTP
https://developer.mozilla.org/en-US/docs/Web/HTTP/
HTTP response status codes
- Informational 1xx
- Successful 2xx
- Redirection 3xx
- Client 4xx
- Server 5xx
100 Continue
101 Switching Protocols
102 Processing
103 Early Hints
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 unused
307 Temporary Redirect
308 Permanent Redirect
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden: когда нет доступа на ресурс
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout: время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Range Not Satisfiable
417 Expectation Failed
418 I'm a teapot
421 Misdirected Request
422 Unprocessable Content
423 Locked
424 Failed Dependency
425 Too Early
426 Upgrade Required
428 Precondition Required
429 Too Many Requests: когда на фаерволле установлены рейт лимит правила и мы их нарушаем
431 Request Header Fields Too Large
449 Retry With
451 Unavailable For Legal Reasons
499 Client Closed Request: HTTP 499 in Nginx means that the client closed the connection before the server answered the request. In my experience is usually caused by client side timeout.
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
509 Bandwidth Limit Exceeded
510 Not Extended
511 Network Authentication Required
520 Unknown Error
521 Web Server Is Down
522 Connection Timed Out
523 Origin Is Unreachable
524 A Timeout Occurred
525 SSL Handshake Failed
526 Invalid SSL Certificate
HTTP Methods
GET
Цель: Получить данные с сервера.
Несколько идентичных запросов должны иметь тот же эффект, что и один запрос. Не изменяет состояние сервера (только чтение). Ответы могут кэшироваться браузерами и посредниками.
GET /api/users/123
Этот запрос возвращает пользователя с идентификатором 123.
POST
Цель: Отправить данные для обработки на сервер.
Несколько одинак овых запросов могут иметь разные эффекты (например, создание нескольких ресурсов). Можно изменить состояние сервера (создать, обновить, удалить), что небезопасно. Как правило, ответы не кэшируются.
POST /api/users
Content-Type: application/json
{
"name": "John Doe",
"email": "john.doe@example.com"
}
Этот запрос создает нового пользователя с указанным именем и адресом электронной почты.
PUT
Цель: Обновить или создать ресурс по указанному URI.
Несколько идентичных запросов должны иметь тот же эффект, что и один запрос. Может изменить состояние сервера. Ответы обычно не кэшируются.
PUT /api/users/123
Content-Type: application/json
{
"name": "Jane Doe",
"email": "jane.doe@example.com"
}
Этот запрос сообщает пользователю с идентификатором 123 новое имя и адрес электронной почты. Если пользователь не существует, он может создать нового пользователя с этим идентификатором.
DELETE
Цель: Удалить ресурс с сервера.
Несколько одинаковых запросов должны иметь тот же эффект, что и один запрос. Может изменить состояние сервера. Ответы обычно не кэшируются.
DELETE /api/users/123
Этот запрос удаляет пользователя с идентификатором 123.
HEAD
Цель: Получить заголовки ресурса.
Несколько одинаковых запросов должны иметь тот же эффект, что и один запрос. Не изменяет состояние сервера. Ответы могут кэшироваться браузерами и посредниками.
HEAD /api/users/123
Этот запрос получает заголовки пользовательского ресурса с идентификатором 123 без фактического содержимого тела.
HTTP Headers
Заголовки HTTP — это пары ключ-значение, передаваемые между клиентом и сервером в HTTP-запросах и ответах. Они предоставляют важную информацию о запросе или ответе, клиенте, сервере и передаваемых данных.
Request Headers
Предоставить информацию о запросе клиента.
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Response Headers
Предоставьте информацию об ответе сервера.
HTTP/1.1 200 OK
Date: Wed, 21 Jul 2021 07:28:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Mon, 21 Jul 2021 07:28:00 GMT
Content-Type: text/html
Content-Length: 174
Connection: keep-alive
<!DOCTYPE html>
<html>
<head>
<title>Example Page</title>
</head>
<body>
<h1>Hello, World!</h1>
</body>
</html>
General Headers
Применимо как к запросам, так и к ответам.
HTTP/1.1 200 OK
Date: Wed, 21 Jul 2021 07:28:00 GMT
Connection: keep-alive
Cache-Control: no-cache
Entity Headers
Предоставляет информацию о теле ресурса.
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 348
Content-Encoding: gzip
Content-Language: en-US
Content-Location: /documents/123
CORS
Cross-Origin Resource Sharing — это механизм на основе HTTP Header
, который позволяет серверу указывать любые источники (домен, схему или порт), отличные от его собственного, из которых браузер должен разрешать загрузку ресурсов.
CORS определяет для клиентских веб-приложений, загруженных в одном домене, способ взаимодействия с ресурсами в другом домене. Это полезно, поскольку сложные приложения часто ссылаются на сторонние API и ресурсы в своем клиентском коде. Например, ваше приложение может использовать браузер для извлечения видео из API видеоплатформы, использования шрифтов из общедоступной библиотеки шрифтов или отображения данных о погоде из национальной базы данных погоды - Host: www.other.com
(Cross-Origin), Origin: https://www.example.com
(origin).
CORS позволяет браузеру клиента проверять на сторонних серверах, авторизован ли запрос перед передачей данных. Чтобы не было никаких проблем с загрузкой объектов из сторонних мест - надо прописать разрешающий CORS Header
- Access-Control-Allow-Origin
.
Cookie
Cookie — это небольшие фрагменты данных, которые веб-браузер сохраняет на компьютере пользователя во время просмотра веб-сайта. Они используются для запоминания информации о пользователе и его действиях в разных сеансах.
Types of Cookies
- Session Cookies: временные Cookie, которые удаляются при закрытии браузера.
- Persistent Cookies: Cookie, которые остаются на устройстве пользователя в течение определенного периода или до тех пор, пока не будут удалены.
- Secure Cookies: передаются только через безопасные соединения HTTPS.
- HttpOnly Cookies: недоступны через JavaScript, что снижает риск XSS-атак.
Common Uses
- Управление сеансом: статус входа пользователя, содержимое корзины покупок, результаты игр или любые другие сведения, связанные с сеансом пользователя, которые сервер должен запомнить.
- Персонализация: пользовательские настройки, такие как язык отображения и тема пользовательского интерфейса.
- Отслеживание: запись и анализ поведения пользователей.
Cache
Кэш — это процесс хранения копий файлов или данных во временном хранилище (кеше) для обеспечения более быстрого доступа. Кэширование повышает производительность за счет сокращения времени, необходимого для получения данных и нагрузки на сервер.
Types of Cache
- Memory Cache: Быстрое энергозависимое хранилище, используемое для временного хранения данных.
- Disk Cache: Медленнее, чем кеш-память, но обеспечивает постоянное хранилище.
- Proxy Cache: Промежуточный кеш, который хранит данные для нескольких пользователей и снижает использование полосы пропускания.
Storage Locations
- Browser Cache: Хранит копии веб-страниц, изображений и других ресурсов на устройстве пользователя.
- Server Cache: Кэширует ответы на стороне сервера для быстрого обслуживания п оследующих запросов.
- CDN Cache: CDN кэшируют контент в различных местах по всему миру, чтобы уменьшить задержку и сократить время загрузки для пользователей по всему миру.
HTTP vs. HTTPS
- Security
- Port Number
- Data Integrity
- Authentication
- SEO and Browser Behavior
- Use Cases
HTTP: HTTP небезопасен. Данные, отправляемые по протоколу HTTP, не зашифрованы и могут быть перехвачены злоумышленниками. Данные - это логин, персональная информация, история браузера, сессии. Перехватываются эти данные разными способами, например аттака MITM (Man-in-the-Middle Attack)
HTTPS: HTTPS безопасен. Он использует SSL/TLS для шифрования данных между браузером пользователя и сервер ом, защищая их от перехвата.
HTTP: 80
HTTPS: 443
HTTP: Данные могут быть изменены или повреждены во время передачи без обнаружения.
HTTPS: Обеспечивает целостность данных, проверяя, что данные не были изменены во время передачи.
HTTP: Не обеспечивает никакой проверки личности сервера.
HTTPS: Использует сертификаты SSL/TLS для проверки подлинности сервера, гарантируя, что пользователь взаимодействует с предполагаемым веб-сайтом.
HTTP: Веб-сайты, использующие HTTP, могут быть помечены браузерами как «небезопасные». Они также могут иметь более низкий рейтинг в результатах поисковых систем.
HTTPS: Веб-сайты, использующие HTTPS, помечаются как безопасные и могут повысить рейтинг в результатах поисковых систем. Современные браузеры также предпочитают, а иногда даже требуют HTTPS для определенных функций.
HTTP: Подходит для неконфиденциальной информации, безопасность которой не имеет значения, например общедоступных веб-с айтов и блогов.
HTTPS: Необходим для конфиденциальной информации, такой как страницы входа, платежные транзакции и любой сайт, требующий пользовательских данных.