feat(http): Add SVG diagrams for HTTP pages (#34314)

mdn · Jun 21, 2024 · fa33a91 · fa33a91
1 parent 3b1fef7
commit fa33a91
Show file tree

Hide file tree

Showing 9 changed files with 15 additions and 6 deletions.
diff --git a/files/en-us/web/http/authentication/http-auth-sequence-diagram.png b/files/en-us/web/http/authentication/http-auth-sequence-diagram.png
diff --git a/files/en-us/web/http/authentication/index.md b/files/en-us/web/http/authentication/index.md
@@ -19,7 +19,7 @@ The challenge and response flow works like this:
 2. A client that wants to authenticate itself with the server can then do so by including an {{HTTPHeader("Authorization")}} request header with the credentials.
 3. Usually a client will present a password prompt to the user and will then issue the request including the correct `Authorization` header.
 
-![A sequence diagram illustrating HTTP messages between a client and a server lifeline.](http-auth-sequence-diagram.png)
+![A sequence diagram illustrating HTTP messages between a client and a server lifeline.](https://mdn.github.io/shared-assets/images/diagrams/http/authentication/basic-auth.svg)
 
 The general message flow above is the same for most (if not all) [authentication schemes](#authentication_schemes).
 The actual information in the headers and the way it is encoded does change!

diff --git a/files/en-us/web/http/caching/index.md b/files/en-us/web/http/caching/index.md
@@ -157,7 +157,11 @@ If both `Expires` and `Cache-Control: max-age` are available, `max-age` is defin
 
 The way that responses are distinguished from one another is essentially based on their URLs:
 
-![keyed with url](keyed-with-url.png)
+| URL | Response body |
+| -------------------------------- | ------------------------ |
+| `https://example.com/index.html` | `<!doctype html>...` |
+| `https://example.com/style.css` | `body { ...` |
+| `https://example.com/script.js` | `function main () { ...` |
 
 But the contents of responses are not always the same, even if they have the same URL. Especially when content negotiation is performed, the response from the server can depend on the values of the `Accept`, `Accept-Language`, and `Accept-Encoding` request headers.
 
@@ -169,7 +173,12 @@ Vary: Accept-Language
 
 That causes the cache to be keyed based on a composite of the response URL and the `Accept-Language` request header — rather than being based just on the response URL.
 
-![keyed with url and language](keyed-with-url-and-language.png)
+| URL | `Accept-Language` | Response body |
+| -------------------------------- | ----------------- | ------------------------ |
+| `https://example.com/index.html` | `ja-JP` | `<!doctype html>...` |
+| `https://example.com/index.html` | `en-US` | `<!doctype html>...` |
+| `https://example.com/style.css` | `ja-JP` | `body { ...` |
+| `https://example.com/script.js` | `ja-JP` | `function main () { ...` |
 
 Also, if you are providing content optimization (for example, for responsive design) based on the user agent, you may be tempted to include "`User-Agent`" in the value of the `Vary` header. However, the `User-Agent` request header generally has a very large number of variations, which drastically reduces the chance that the cache will be reused. So if possible, instead consider a way to vary behavior based on feature detection rather than based on the `User-Agent` request header.
 

diff --git a/files/en-us/web/http/caching/keyed-with-url-and-language.png b/files/en-us/web/http/caching/keyed-with-url-and-language.png
diff --git a/files/en-us/web/http/caching/keyed-with-url.png b/files/en-us/web/http/caching/keyed-with-url.png
diff --git a/files/en-us/web/http/cors/cred-req-updated.png b/files/en-us/web/http/cors/cred-req-updated.png
diff --git a/files/en-us/web/http/cors/index.md b/files/en-us/web/http/cors/index.md
@@ -94,7 +94,7 @@ fetchPromise
 
 This operation performs a simple exchange between the client and the server, using CORS headers to handle the privileges:
 
-![Diagram of simple CORS GET request](simple-req.png)
+![Diagram of simple CORS GET request](https://mdn.github.io/shared-assets/images/diagrams/http/cors/simple-request.svg)
 
 Let's look at what the browser will send to the server in this case:
 
@@ -164,7 +164,7 @@ fetchPromise.then((response) => {
 
 The example above creates an XML body to send with the `POST` request. Also, a non-standard HTTP `X-PINGOTHER` request header is set. Such headers are not part of HTTP/1.1, but are generally useful to web applications. Since the request uses a `Content-Type` of `text/xml`, and since a custom header is set, this request is preflighted.
 
-![Diagram of a request that is preflighted](preflight_correct.png)
+![Diagram of a request that is preflighted](https://mdn.github.io/shared-assets/images/diagrams/http/cors/preflight-correct.svg)
 
 > **Note:** As described below, the actual `POST` request does not include the `Access-Control-Request-*` headers; they are needed only for the `OPTIONS` request.
 
@@ -296,7 +296,7 @@ fetchPromise.then((response) => console.log(response));
 
 This code creates a {{domxref("Request")}} object, setting the `credentials` option to `"include"` in the constructor, then passes this request into `fetch()`. Since this is a simple `GET` request, it is not preflighted but the browser will **reject** any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}`: true` header, and **not** make the response available to the invoking web content.
 
-![Diagram of a simple GET request with Access-Control-Allow-Credentials](cred-req-updated.png)
+![Diagram of a simple GET request with Access-Control-Allow-Credentials](https://mdn.github.io/shared-assets/images/diagrams/http/cors/include-credentials.svg)
 
 Here is a sample exchange between client and server:
 

diff --git a/files/en-us/web/http/cors/preflight_correct.png b/files/en-us/web/http/cors/preflight_correct.png
diff --git a/files/en-us/web/http/cors/simple-req.png b/files/en-us/web/http/cors/simple-req.png