Fix scrapper

content/100.md

@@ -1,17 +1,46 @@
 ## Description
 
-The HTTP `100 Continue` informational status response code
-indicates that everything so far is OK and that the client should continue with the
-request or ignore it if it is already finished.
+The HTTP **`100 Continue`** [informational response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#informational_responses) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The client should continue with a request or discard the 100 response if the request is already finished.
 
+When a request has an [`Expect: 100-continue`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Expect) header, the 100 Continue response indicates that the server is ready or capable of receiving the request content. Waiting for a 100 Continue response can be helpful if a client anticipates that an error is likely, for example, when sending state-changing operations without previously verified authentication credentials.
 
-To have a server check the request's headers, a client must send
-`Expect: 100-continue` as a header in its initial request
-and receive a `100 Continue` status code in response before sending the body.
+### Examples
 
-### See Also
+The following [`PUT`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/PUT) request sends information to a server about a file upload. The client is indicating that it will proceed with the content if it receives a 100 response to avoid sending data over the network that could result in an error like [`405`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/405), [`401`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401), or [`403`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403). At first, the client sends headers only, including an [`Expect: 100-continue`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Expect) header:
 
-- [Spec](https://www.rfc-editor.org/rfc/rfc9110#status.100)
-- [Expect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect), the header that triggers the `100 Continue` expectation 
+http
 
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100)
+    PUT /videos HTTP/1.1
+    Host: uploads.example.com
+    Content-Type: video/h264
+    Content-Length: 123456789
+    Expect: 100-continue
+
+
+The server indicates that the request can proceed:
+
+http
+
+    HTTP/1.1 100 Continue
+
+
+The client completes the request by sending the actual data:
+
+http
+
+    [Video data as content for PUT request]
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics  
+\# status.100](https://www.rfc-editor.org/rfc/rfc9110#status.100)
+
+### See also
+
+* [`Expect`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Expect)
+* [`417`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/417)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/100](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/100)

content/101.md

@@ -1,20 +1,40 @@
 ## Description
 
-The HTTP `101 Switching Protocols` response code indicates
-a protocol to which the server switches.
-The protocol is specified in the [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade) request header received from a client.
+The HTTP **`101 Switching Protocols`** [informational response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#informational_responses) status code indicates the protocol that a server has switched to. The protocol is specified in the [`Upgrade`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Upgrade) request header received from a client.
 
-The server includes in this response an [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade) response header to
-indicate the protocol it switched to.
+The server includes an [`Upgrade`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Upgrade) header in this response to indicate the protocol it has agreed to switch to. The process is described in detail in the [Protocol upgrade mechanism](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism) guide.
 
-The process is described in the following article:
-[Protocol upgrade mechanism](https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism)
+### Examples
 
-### See Also
+The following example shows how switching protocols might be used with [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API). A client sends a [`GET`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET) HTTP request with an [`Upgrade`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Upgrade) header which must also be listed in the [`Connection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Connection) header. The server agrees to switch protocols, returning a 101 response meaning the connection has switched from HTTP to WebSocket. At this point, the client and server can now start exchanging WebSocket data. Information about how to set `Sec-WebSocket-*` headers for handshake negotiation can be found in [WebSocket-specific headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism#websocket-specific_headers).
 
-- [Spec](https://httpwg.org/specs/rfc9110.html#status.101)
-- [Upgrade](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade), the header that triggers the protocol switch
-- [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API), a protocol which can be used with this status code
-- [426 Upgrade Required](https://http.cat/status/426), a status code that can be used to notify the client to switch to a different protocol
+http
 
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101)
+    GET /notifications HTTP/1.1
+    Host: example.com
+    Upgrade: websocket
+    Connection: Upgrade
+
+
+http
+
+    HTTP/1.1 101 Switching Protocols
+    Upgrade: websocket
+    Connection: Upgrade
+
+
+### Specifications
+
+Specification
+
+[HTTP Semantics  
+\# status.101](https://httpwg.org/specs/rfc9110.html#status.101)
+
+### See also
+
+* [Protocol upgrade mechanism](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Protocol_upgrade_mechanism)
+* [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API)
+* [`Upgrade`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Upgrade)
+* [`426 Upgrade Required`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/426)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/101](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/101)

content/102.md

@@ -1,15 +1,26 @@
 ## Description
 
-<aside class="alert"><strong>Deprecated:</strong>This status code is deprecated. When used, clients may still accept it, but simply ignore them.</aside>
+**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the [compatibility table](#browser_compatibility) at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
 
-The HTTP `102 Processing` informational status response code indicates to client that a full request has been received and the server is working on it.
+The HTTP **`102 Processing`** [informational response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#informational_responses) status code indicates to client that a full request has been received and the server is working on it. This status code is only sent if the server expects the request to take significant time.
 
-This status code is only sent if the server expects the request to take significant time. It tells the client that your request is not dead yet.
+**Note:** Regular web servers do not return this response. This status code was first introduced in Web Distributed Authoring and Versioning ([WebDAV](https://developer.mozilla.org/en-US/docs/Glossary/WebDAV)) [RFC 2518](https://datatracker.ietf.org/doc/html/rfc2518), but it was removed from WebDAV in [RFC 4918](https://datatracker.ietf.org/doc/html/rfc4918).
 
-### See Also
+### Specifications
 
-- [Spec](https://tools.ietf.org/html/rfc2518#section-10.1)
-- [Expect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect)
-- [100 Continue](https://http.cat/status/100)
+Specification
 
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/102](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/102)
+[Unknown specification  
+\# section-10.1](https://www.rfc-editor.org/rfc/rfc2518.html#section-10.1)
+
+### Browser compatibility
+
+This feature is deprecated and browsers will ignore this response status code.
+
+### See also
+
+* [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
+* [`100`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/100)
+* [rfc4918 '102 Processing' removal notes](https://www.rfc-editor.org/rfc/rfc4918#section-21.4)
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/102](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/102)

content/103.md

@@ -1,23 +1,120 @@
 ## Description
 
-<aside class="warning"><strong>Experimental:</strong> This is an experimental technology. Check the Browser compatibility table carefully before using this in production.</aside>
+The HTTP **`103 Early Hints`** [informational response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status#informational_responses) may be sent by a server while it is still preparing a response, with hints about the sites and resources that the server expects the final response will link to. This allows a browser to [preconnect](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect) to sites or start [preloading](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload) resources even before the server has prepared and sent a final response. Preloaded resources indicated by early hints are fetched by the client as soon as the hints are received.
 
-The HTTP `103 Early Hints` [information response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#information_responses) may be sent by a server while it is still preparing a response, with hints about the resources that the server is expecting the final response will link.
+The early hint response is primarily intended for use with the [`Link`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Link) header, which indicates the resources to be loaded. It may also contain a [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) header that is enforced while processing the early hint.
 
-This allows a browser to start [preloading](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload) resources even before the server has prepared and sent that final response.
+A server might send multiple `103` responses, for example, following a redirect. Browsers only process the first early hints response, and this response must be discarded if the request results in a cross-origin redirect.
 
-The early hint response is primarily intended for use with the [Link](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link) header, which indicates the resources to be loaded.
+**Note:** For compatibility and security reasons, it is recommended to [only send HTTP `103 Early Hints` responses over HTTP/2 or later](https://www.rfc-editor.org/rfc/rfc8297#section-3) unless the client is known to handle informational responses correctly.
 
-It may also contain a [Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) header that is enforced while processing the early hint.
+Most browsers limit support to HTTP/2 or later for this reason. See [browser compatibility](#browser_compatibility) below. Despite this, the examples below use HTTP/1.1-style notation as per usual convention.
 
+### Syntax
 
-A server might send multiple `103` responses, for example, following a redirect.
-Browsers only process the first early hint response, and this response must be discarded if the request results in a cross-origin redirect.
-Preloaded resources from the early hint are effectively pre-pended to the `Document`'s head element, and then followed by the resources loaded in the final response.
+http
 
-### See Also
+    103 Early Hints
+
 
-- [Spec](https://html.spec.whatwg.org/multipage/semantics.html#early-hints)
-- [Link Header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link)
+### Examples
 
-**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103)
+The following `103` early hint response shows an early hint response where the server indicates that the client might want to preconnect to a particular origin (`https://cdn.example.com`). Just like the HTML [`rel=preconnect`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect) attribute, this is a hint that the page is likely to need resources from the target resource's origin, and that the browser may improve the user experience by preemptively initiating a connection to that origin.
+
+http
+
+    103 Early Hint
+    Link: <https://cdn.example.com>; rel=preconnect, <https://cdn.example.com>; rel=preconnect; crossorigin
+
+
+This example preconnects to `https://cdn.example.com` twice:
+
+* The first connection would be used for loading resources that can be fetched without CORS, such as images.
+* The second connection includes the [`crossorigin`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/crossorigin) attribute and would be used for loading [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)\-protected resources, such as fonts.
+
+CORS-protected resources must be fetched over a completely separate connection. If you only need one type of resource from an origin then you only need to preconnect once.
+
+Subsequently the server sends the final response. This includes a crossorigin font preload and an `<img>` loaded from the additional origin.
+
+http
+
+    200 OK
+    Content-Type: text/html
+
+    <!doctype html>
+    ...
+    <link rel="preload" href="https://cdn.example.com/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>
+    ...
+    <img src="https://cdn.example.com/images/image.jpg" alt="">
+    ...
+
+
+The following `103` early hint response indicates a stylesheet `style.css` might be needed by the final response.
+
+http
+
+    103 Early Hint
+    Link: </style.css>; rel=preload; as=style
+
+
+Subsequently the server sends the final response. This includes a link to the stylesheet, which may already have been preloaded from the early hint.
+
+http
+
+    200 OK
+    Content-Type: text/html
+
+    <!doctype html>
+    ...
+    <link rel="stylesheet" rel="preload" href="style.css" />
+    ...
+
+
+The following example shows the same early hint response but with a `Content-Security-Policy` header included.
+
+http
+
+    103 Early Hint
+    Content-Security-Policy: style-src: self;
+    Link: </style.css>; rel=preload; as=style
+
+
+The early response restricts preloading to the same origin as the request. The stylesheet will be preloaded if the origin matches.
+
+The final response might set the CSP to `none`, as shown below. The stylesheet has already been preloaded, but will not be used when rendering the page.
+
+http
+
+    200 OK
+    Content-Security-Policy: style-src: none;
+    Content-Type: text/html
+
+    <!doctype html>
+    ...
+    <link rel="stylesheet" rel="preload" href="style.css" />
+    ...
+
+
+### Specifications
+
+Specification
+
+[An HTTP Status Code for Indicating Hints  
+\# early-hints](https://httpwg.org/specs/rfc8297.html#early-hints)
+
+[HTML  
+\# early-hints](https://html.spec.whatwg.org/multipage/semantics.html#early-hints)
+
+### Browser compatibility
+
+### See also
+
+* [`Link`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Link)
+* [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
+* [Content Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
+* [`rel="preconnect"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect) ([`<link>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [`rel="preload"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload) ([`<link>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [`fetchpriority`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link#fetchpriority) ([`<link>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link) attribute)
+* [Early Hints update: How Cloudflare, Google, and Shopify are working together to build a faster Internet for everyone](https://blog.cloudflare.com/early-hints-performance/) from the Cloudflare blog
+
+**Source:** [https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/103](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/103)