Source code of my website
🌐 : translate http request anatomy page
+272
+272
content/posts/2023-05-25-anatomie-requete-http/index.en.md
+272
content/posts/2023-05-25-anatomie-requete-http/index.en.md
···
1
+
---
2
+
created: "2023-05-25"
3
+
date: "2023-05-25T00:00:00Z"
4
+
language: fr
5
+
modified: "2023-07-01"
6
+
tags:
7
+
- Basics
8
+
title: Anatomy of an HTTP request
9
+
slug: anatomie-requete-http
10
+
---
11
+
12
+
HTTP, for _Hypertext Transfer Protocol_, is the main protocol for Internet exchanges. It's used by the browser you're using to read this article, as well as by other applications.
13
+
It's based on an exchange of requests and responses, between a client and a server, in text format. The advantage of text format is that it's easy to implement in any programming language.
14
+
The HTTP protocol is specified in [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616), the very first version of which dates back to 1990.
15
+
16
+
This article deals with version 1.1 of the protocol, which was standardized in 1997. A version 2.0 was standardized in 2015, and extends version 1.1 with additional capabilities. The basics of version 1.1 are therefore not obsolete!
17
+
18
+
19
+
20
+
In this article, we'll look at the structure of an HTTP request and response.
21
+
22
+
## The structure of a request
23
+
24
+
A request is structured in 3 parts:
25
+
26
+
* the mandatory first line of the request
27
+
* the optional headers
28
+
* the request body, also optional
29
+
30
+
```
31
+
REQUEST-LINE
32
+
[HEADERS]
33
+
34
+
[BODY]
35
+
```
36
+
37
+
Example of an HTTP _GET_ request without a request body:
38
+
39
+
```
40
+
GET /articles/http-anatomy?version=1#headers HTTP/1.1
41
+
Host: codeka.io
42
+
Accept: text/plain
43
+
Accept-Charset: utf-8
44
+
Accept-Encoding: gzip
45
+
Accept-Language: fr-fr
46
+
```
47
+
48
+
Example with a request body :
49
+
50
+
```
51
+
POST /articles/ HTTP/1.1
52
+
Host: codeka.io
53
+
Content-Type: application/json
54
+
Content-Length: 31
55
+
Authorization: Basic UmljayBBc3RsZXk6TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXAK
56
+
57
+
{"title":"my beautiful article"}
58
+
```
59
+
60
+
### The _Request Line_
61
+
62
+
The _HEADERS_ and _BODY_ are optional.
63
+
64
+
The _REQUEST-LINE_ is defined in this way:
65
+
66
+
```
67
+
METHOD REQUEST-URI HTTP-VERSION
68
+
```
69
+
70
+
_METHOD_ is the HTTP verb. It can be `GET`, `POST`, `PUT`, `DELETE`, which are the most common HTTP verbs.
71
+
RFC 2616 also defines additional methods, such as `HEAD`, `OPTIONS`, `TRACE`, `CONNECT`.
72
+
73
+
_REQUEST-URI_ is the resource to be called. It can be an absolute URI, like `https://codeka.io/articles/http-anatomy`, or a relative URI, like `/articles/http-anatomy`. In practice, relative URIs are used in combination with a _Header_ `Host`.
74
+
75
+
The `HTTP-VERSION` field is set to `HTTP/1.1`.
76
+
77
+
A minimal HTTP request is :
78
+
79
+
```
80
+
GET /articles/http-anatomy HTTP/1.1
81
+
```
82
+
83
+
### _URL_ and _URI_
84
+
85
+
A _URI_, for _Uniform Resource Identifier_, defines an Internet resource. This resource can be a web page, a document in PDF format, or a video.
86
+
87
+
A _URL_, for _Uniform Resource Locator_, is a particular _URI_, which contains the network information needed to access a resource.
88
+
_URIs_ are defined by a text format made up of _ASCII_ characters.
89
+
90
+
[RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) specifies _URI_ formats.
91
+
92
+
The structure of an absolute _URI_ is as follows:
93
+
94
+
```
95
+
SCHEME://HOST/PATH[?QUERY][#FRAGMENT]
96
+
```
97
+
The _SCHEME_ is often associated with the protocol, _http_, _https_, or _file_ when local files are designated.
98
+
99
+
The _HOST_ is the name of the server hosting the resource.
100
+
101
+
The _PATH_ identifies the path to the resource.
102
+
103
+
The _QUERY_, also often called _Query Strings_, defines additional parameters that the resource can process, in the form `name=value`.
104
+
105
+
The _FRAGMENT_ defines the part of the resource consulted.
106
+
107
+
_QUERY_ and _FRAGMENT_ are optional.
108
+
109
+
A simple _URI_ for our article is :
110
+
111
+
```
112
+
https://codeka.io/articles/http-anatomy
113
+
\___/ \_______/ \___________________/
114
+
| | |
115
+
scheme host path
116
+
```
117
+
118
+
A _URI_ with additional elements :
119
+
120
+
```
121
+
https://codeka.io/articles/http-anatomy?version=1#headers
122
+
\___/ \_______/ \___________________/ \_______/ \_____/
123
+
| | | | |
124
+
scheme host path query fragment
125
+
```
126
+
127
+
A _URI_ can also be relative, and contain only part of the _PATH_.
128
+
For instance :
129
+
130
+
```
131
+
/http-anatomy?version=1#headers
132
+
```
133
+
134
+
### Request _Headers
135
+
136
+
_Headers_ define additional information about the request, such as the data format expected in response, or information about data currently cached on the client side.
137
+
138
+
This simple structure defines the _Headers_:
139
+
140
+
```
141
+
NAME: VALUE
142
+
```
143
+
144
+
[RFC 2616](https://www.rfc-editor.org/rfc/rfc2616#page-38), defines standard _Headers_, but applications can also define their own _Headers_.
145
+
The main standard _Headers_ are `Accept`, `Accept-Charset`, `Accept-Encoding` and `Accept-Language` for content negotiation.
146
+
This RFC also defines the _Header_ `Authorization` for client authentication. The _Header_ `Host` specifies the host to which the request is sent if it is not specified in the request URI.
147
+
148
+
An HTTP request containing _Headers_ is :
149
+
150
+
```
151
+
GET /articles/http-anatomy HTTP/1.1
152
+
Host: codeka.io
153
+
Accept: text/plain
154
+
Accept-Charset: utf-8
155
+
Accept-Encoding: gzip
156
+
Accept-Language: fr-fr
157
+
```
158
+
159
+
### The request _Body_
160
+
161
+
When a request includes a body, the _Headers_ `Content-Type` and `Content-Length` must be specified, defining its type and size in bytes.
162
+
A line break must also separate the _Headers_ from the _Body_.
163
+
164
+
Example of a query with a _Body_ in `JSON` format:
165
+
166
+
```
167
+
POST /articles/ HTTP/1.1
168
+
Host: codeka.io
169
+
Content-Type: application/json
170
+
Content-Length: 31
171
+
172
+
{"title":"my beautiful article"}
173
+
```
174
+
## The structure of a response
175
+
176
+
HTTP responses have a format quite similar to that of requests.
177
+
178
+
```
179
+
STATUS-LINE
180
+
[HEADERS]
181
+
182
+
[BODY]
183
+
```
184
+
185
+
### _Status Line_
186
+
187
+
The _Status Line_ represents the server's coded response to the request.
188
+
189
+
This is how _STATUS-LINE_ is defined:
190
+
191
+
```
192
+
HTTP-VERSION CODE PHRASE
193
+
```
194
+
195
+
The first element of the response is the HTTP version `HTTP/1.1`.
196
+
197
+
The codes used are represented by 3 digits.
198
+
199
+
* `1xx` codes are informational and rarely used in practice.
200
+
* `2xx` codes represent a successful operation.
201
+
* `3xx` codes indicate a redirection.
202
+
* `4xx` codes indicate a client error (malformed request, non-existent resource).
203
+
* `5xx` codes represent a server error in processing the request.
204
+
205
+
Codes are followed by a descriptive _Phrase_.
206
+
207
+
The most common codes and associated phrases are defined in [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616#section-6.1.1).
208
+
209
+
Example of an error response:
210
+
211
+
```
212
+
HTTP/1.1 404 Not Found
213
+
```
214
+
215
+
An example of a successful response:
216
+
217
+
```
218
+
HTTP/1.1 200 OK
219
+
```
220
+
221
+
### Response _Headers
222
+
223
+
Like a request, a response can contain _Headers_. They define the type and size of the response _Body_, or parameters to indicate to the client that the response can be cached. Other _Headers_ define the resource to be called in the event of a redirection (code `3xx`).
224
+
225
+
Response _Headers_ are defined in the same way as requests:
226
+
227
+
```
228
+
NAME: VALUE
229
+
```
230
+
231
+
Example of an HTTP response including a _Header_ `Location` for a redirect to an `index.html` page:
232
+
233
+
```
234
+
HTTP/1.1 301 Moved Permanently
235
+
Location: index.html
236
+
```
237
+
238
+
### The response _Body_
239
+
240
+
The _Body_ is defined in the same way as requests, and also imposes the same _Headers_ `Content-Type` and `Content-Length` rules.
241
+
242
+
Example of a successful response with the content of our article :
243
+
244
+
```
245
+
HTTP/1.1 200 OK
246
+
Content-Type: application/json
247
+
Content-Length: 31
248
+
249
+
{"title":"my beautiful article"}
250
+
```
251
+
252
+
Example of a server error, with an HTML page representing it:
253
+
254
+
```
255
+
HTTP/1.1 500 Internal Server Error
256
+
Content-Type: text/html
257
+
Content-Length: 56
258
+
259
+
<html><body><h1>Server Error</h1></body></html>
260
+
```
261
+
262
+
## Conclusion
263
+
264
+
The HTTP protocol describes a text format, in the form of a request and response, which is easy to implement in any programming language.
265
+
Its simplicity and expressiveness have been the key to its success since the 90s, with new versions continuing to use the same format.
266
+
267
+
## Références
268
+
269
+
* [RFC 2616](https://www.rfc-editor.org/rfc/rfc2616) : Hypertext Transfer Protocol -- HTTP/1.1
270
+
* [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) : Uniform Resource Identifier (URI) : Generic Syntax
271
+
* [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540) : Hypertext Transfer Protocol Version 2 (HTTP/2)
272
+
* Cover photo by [Jordan Harrison](https://unsplash.com/@jouwdan?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash) on [Unsplash](https://unsplash.com/photos/blue-utp-cord-40XgDxBfYXM?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash)
content/posts/2023-05-25-anatomie-requete-http/index.md
content/posts/2023-05-25-anatomie-requete-http/index.fr.md
content/posts/2023-05-25-anatomie-requete-http/index.md
content/posts/2023-05-25-anatomie-requete-http/index.fr.md