diff --git a/.vscode/cspell.json b/.vscode/cspell.json index 73ec8cab5be87ac..955ee34bf004676 100644 --- a/.vscode/cspell.json +++ b/.vscode/cspell.json @@ -69,5 +69,6 @@ "path": "./project-words.txt", "addWords": true } - ] + ], + "enableFiletypes": ["xml"] } diff --git a/files/en-us/web/http/compression/httpcomp2.png b/files/en-us/web/http/compression/httpcomp2.png deleted file mode 100644 index 63f467dd2dae869..000000000000000 Binary files a/files/en-us/web/http/compression/httpcomp2.png and /dev/null differ diff --git a/files/en-us/web/http/compression/httpcomp2.svg b/files/en-us/web/http/compression/httpcomp2.svg new file mode 100644 index 000000000000000..9b2f106ae346f9f --- /dev/null +++ b/files/en-us/web/http/compression/httpcomp2.svg @@ -0,0 +1,144 @@ + + + + + Server + + + + Node + + + + Node + + + + Client + + + + + + Server + + + + + + + Node + + + + + + + Node + + + + + + + Client + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Request message + + + + Shows support for + + + compression while + + + forwarding message. + + + + Forwards message + + + + Returns resource in + + + an uncompressed + + + body. + + + + Compresses body + + + and forwards + + + message. + + + + Uncompresses + + + resource and returns + + + message to Client. + + GET /doc HTTP/1.1 + + GET /doc HTTP/1.1 + TE: gzip, br + + GET /doc HTTP/1.1 + + HTTP/1.1 200 OK + + HTTP/1.1 200 OK + Transfer-Encoding: br + + HTTP/1.1 200 OK + + diff --git a/files/en-us/web/http/compression/httpcompression1.png b/files/en-us/web/http/compression/httpcompression1.png deleted file mode 100644 index 534c1e58c6b38fa..000000000000000 Binary files a/files/en-us/web/http/compression/httpcompression1.png and /dev/null differ diff --git a/files/en-us/web/http/compression/httpcompression1.svg b/files/en-us/web/http/compression/httpcompression1.svg new file mode 100644 index 000000000000000..ecef141f5ff0131 --- /dev/null +++ b/files/en-us/web/http/compression/httpcompression1.svg @@ -0,0 +1,84 @@ + + + + + Server + + + + Client + + + + + + Server + + + + + + + Client + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The client indicates support for two + + + compression algorithms. + + + + Resource is returned compressed. The Vary + + + header indicates that content negotiation was + + + used to select the algorithm. + + GET /doc HTTP/1.1 + Accept-Encoding: br, gzip + + HTTP/1.1 200 OK + Content-Encoding: br + Vary: Accept-Encoding + + diff --git a/files/en-us/web/http/compression/httpenco1.png b/files/en-us/web/http/compression/httpenco1.png deleted file mode 100644 index 9e33fdd9bd4deb8..000000000000000 Binary files a/files/en-us/web/http/compression/httpenco1.png and /dev/null differ diff --git a/files/en-us/web/http/compression/httpenco1.svg b/files/en-us/web/http/compression/httpenco1.svg new file mode 100644 index 000000000000000..472c9ee2898cbe0 --- /dev/null +++ b/files/en-us/web/http/compression/httpenco1.svg @@ -0,0 +1,114 @@ + + + + + Server + + + + Proxy + + + + Proxy + + + + Client + + + + + + Server + + + + + + + Proxy + + + + + + + Proxy + + + + + + + Client + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Resource requested. + + + + Resource is + + + compressed and + + + returned. + + + + Intermediate nodes do not + + + uncompress the body. + + + + Client decompresses + + + the body. + + + + + + diff --git a/files/en-us/web/http/compression/httpte1.png b/files/en-us/web/http/compression/httpte1.png deleted file mode 100644 index 481fffa7281d038..000000000000000 Binary files a/files/en-us/web/http/compression/httpte1.png and /dev/null differ diff --git a/files/en-us/web/http/compression/httpte1.svg b/files/en-us/web/http/compression/httpte1.svg new file mode 100644 index 000000000000000..d47a04a997d34de --- /dev/null +++ b/files/en-us/web/http/compression/httpte1.svg @@ -0,0 +1,131 @@ + + + + + Server + + + + Node + + + + Node + + + + Node + + + + Client + + + + + + Server + + + + + + + Node + + + + + + + Node + + + + + + + Node + + + + + + + Client + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Client sends an + + + uncompressed + + + body. + + + + Intermediate nodes send the body with or without + + + compression on a hop-by-hop basis. + + + + The server + + + receives an + + + uncompressed + + + body. + + Uncompressed + + Uncompressed + + Compressed + + Uncompressed + + diff --git a/files/en-us/web/http/compression/index.md b/files/en-us/web/http/compression/index.md index c601a32fb4fe57c..bd336ec09f3339b 100644 --- a/files/en-us/web/http/compression/index.md +++ b/files/en-us/web/http/compression/index.md @@ -33,13 +33,43 @@ Lossy compression algorithms are usually more efficient than loss-less ones. For compression, end-to-end compression is where the largest performance improvements of websites reside. End-to-end compression refers to a compression of the body of a message that is done by the server and will last unchanged until it reaches the client. Whatever the intermediate nodes are, they leave the body untouched. -![A server sending a compressed HTTP body to a client via network nodes. The body is not decompressed at any hop through the network until it reaches the client.](httpenco1.png) + + +![A server sending a compressed HTTP body to a client via network nodes. The body is not decompressed at any hop through the network until it reaches the client.](httpenco1.svg) All modern browsers and servers do support it and the only thing to negotiate is the compression algorithm to use. These algorithms are optimized for text. In the 1990s, compression technology was advancing at a rapid pace and numerous successive algorithms have been added to the set of possible choices. Nowadays, only two are relevant: `gzip`, the most common one, and `br` the new challenger. To select the algorithm to use, browsers and servers use [proactive content negotiation](/en-US/docs/Web/HTTP/Content_negotiation). The browser sends an {{HTTPHeader("Accept-Encoding")}} header with the algorithm it supports and its order of precedence, the server picks one, uses it to compress the body of the response and uses the {{HTTPHeader("Content-Encoding")}} header to tell the browser the algorithm it has chosen. As content negotiation has been used to choose a representation based on its encoding, the server must send a {{HTTPHeader("Vary")}} header containing at least {{HTTPHeader("Accept-Encoding")}} alongside this header in the response; that way, caches will be able to cache the different representations of the resource. -![A client requesting content with an 'Accept-Encoding: br, gzip' header. The server responds with a body compressed using the Brotli algorithm and the required 'Content-Encoding' and 'Vary' headers.](httpcompression1.png) + + +![A client requesting content with an 'Accept-Encoding: br, gzip' header. The server responds with a body compressed using the Brotli algorithm and the required 'Content-Encoding' and 'Vary' headers.](httpcompression1.svg) As compression brings significant performance improvements, it is recommended to activate it for all files, but already compressed ones like images, audio files and videos. @@ -49,11 +79,58 @@ Apache supports compression and uses [mod_deflate](https://httpd.apache.org/docs Hop-by-hop compression, though similar to end-to-end compression, differs by one fundamental element: the compression doesn't happen on the resource in the server, creating a specific representation that is then transmitted, but on the body of the message between any two nodes on the path between the client and the server. Connections between successive intermediate nodes may apply a _different_ compression. -![A server sending an uncompressed HTTP body to a client via network nodes. The body is compressed and decompressed by nodes on the network depending on 'Transfer-Encoding' headers before it reaches the client.](httpte1.png) + + +![A server sending an uncompressed HTTP body to a client via network nodes. The body is compressed and decompressed by nodes on the network depending on 'Transfer-Encoding' headers before it reaches the client.](httpte1.svg) To do this, HTTP uses a mechanism similar to the content negotiation for end-to-end compression: the node transmitting the request advertizes its will using the {{HTTPHeader("TE")}} header and the other node chooses the adequate method, applies it, and indicates its choice with the {{HTTPHeader("Transfer-Encoding")}} header. -![A client requesting content from a server with no compression-related headers. The server responds with an uncompressed body. The body is compressed and decompressed by nodes on the network before it reaches the client.](httpcomp2.png) + + +![A client requesting content from a server with no compression-related headers. The server responds with an uncompressed body. The body is compressed and decompressed by nodes on the network before it reaches the client.](httpcomp2.svg) In practice, hop-by-hop compression is transparent for the server and the client, and is rarely used. {{HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} are mostly used to send a response by chunks, allowing to start transmitting a resource without knowing its length. diff --git a/files/en-us/web/http/redirections/httpredirect.png b/files/en-us/web/http/redirections/httpredirect.png deleted file mode 100644 index cf3e19ea8f16134..000000000000000 Binary files a/files/en-us/web/http/redirections/httpredirect.png and /dev/null differ diff --git a/files/en-us/web/http/redirections/httpredirect.svg b/files/en-us/web/http/redirections/httpredirect.svg new file mode 100644 index 000000000000000..6b087a022b64e3e --- /dev/null +++ b/files/en-us/web/http/redirections/httpredirect.svg @@ -0,0 +1,88 @@ + + + + + Server + + + + Client + + + + + + Server + + + + + + + Client + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Request resource + + + + Resource moved; + + + Respond with new location + + + + Request resource at new location + + + + Return resource + + GET /doc HTTP/1.1 + + HTTP/1.1 301 Moved Permanently + Location: /doc_new + + GET /doc_new HTTP/1.1 + + HTTP/1.1 200 OK + + diff --git a/files/en-us/web/http/redirections/index.md b/files/en-us/web/http/redirections/index.md index 2a37d2fad93fb4f..ebd526c68e3083f 100644 --- a/files/en-us/web/http/redirections/index.md +++ b/files/en-us/web/http/redirections/index.md @@ -19,7 +19,25 @@ In HTTP, redirection is triggered by a server sending a special _redirect_ respo When browsers receive a redirect, they immediately load the new URL provided in the `Location` header. Besides the small performance hit of an additional round-trip, users rarely notice the redirection. -![Initial request goes from client to server. Server responds with a 301:moved permanently, with the URL for the redirect. Client makes an a GET request for the new URL which is returned by the server, with a 200 OK response.](httpredirect.png) + + +![A request made from client to server. The server responds with "301:moved permanently" and the new URL for the resource. The client makes a GET request for the new URL which is returned by the server, with a 200 OK response.](httpredirect.svg) There are several types of redirects, sorted into three categories: @@ -145,7 +163,7 @@ Redirects can be set either in the server config file or in the `.htaccess` of e The [`mod_alias`](https://httpd.apache.org/docs/current/mod/mod_alias.html) module has `Redirect` and `RedirectMatch` directives that set up {{HTTPStatus("302")}} redirects by default: -```xml +```apacheconf ServerName example.com Redirect / https://www.example.com @@ -156,7 +174,7 @@ The URL `https://example.com/` will be redirected to `https://www.example.com/`, `RedirectMatch` does the same, but takes a {{glossary("regular expression")}} to define a collection of affected URLs: -```plain +```apacheconf RedirectMatch ^/images/(.*)$ https://images.example.com/$1 ``` @@ -164,7 +182,7 @@ All documents in the `images/` directory will redirect to a different domain. If you don't want a temporary redirect, an extra parameter (either the HTTP status code to use or the `permanent` keyword) can be used to set up a different redirect: -```plain +```apacheconf Redirect permanent / https://www.example.com # …acts the same as: Redirect 301 / https://www.example.com @@ -176,7 +194,7 @@ The [`mod_rewrite`](https://httpd.apache.org/docs/current/mod/mod_rewrite.html) In Nginx, you create a specific server block for the content you want to redirect: -```plain +```nginx server { listen 80; server_name example.com; @@ -186,7 +204,7 @@ server { To apply a redirect to a directory or only certain pages, use the `rewrite` directive: -```plain +```nginx rewrite ^/images/(.*)$ https://images.example.com/$1 redirect; rewrite ^/images/(.*)$ https://images.example.com/$1 permanent; ```