chore: Fix redirected MDN URLs for HTTP status docs

Author: bsmth

src/content/docs/cloudflare-one/insights/dex/tests/http.mdx

@@ -51,7 +51,7 @@ An HTTP test measures the following data:
 | Resource fetch time  | Total time of all steps of the request, measured from [`startTime` to `responseEnd`](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API/Resource_timing). |
 | Server response time | Round-trip time for the device to receive a response from the target.                                                                                                   |
 | DNS response time    | Round-trip time for the DNS query to resolve.                                                                                                                           |
-| HTTP status codes    | [Status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) returned by the target.                                                                         |
+| HTTP status codes    | [Status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status) returned by the target.                                                                         |
 
 ## Related resources
 

src/content/docs/r2/api/s3/extensions.mdx

@@ -35,7 +35,7 @@ If using Unicode in object key names, refer to [Unicode Interoperability](/r2/re
 
 ## Auto-creating buckets on upload
 
-If you are creating buckets on demand, you might initiate an upload with the assumption that a target bucket exists. In this situation, if you received a `NoSuchBucket` error, you would probably issue a `CreateBucket` operation. However, following this approach can cause issues: if the body has already been partially consumed, the upload will need to be aborted. A common solution to this issue, followed by other object storage providers, is to use the [HTTP `100`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100) response to detect whether the body should be sent, or if the bucket must be created before retrying the upload. However, Cloudflare does not support the HTTP `100` response. Even if the HTTP `100` response was supported, you would still have additional latency due to the round trips involved.
+If you are creating buckets on demand, you might initiate an upload with the assumption that a target bucket exists. In this situation, if you received a `NoSuchBucket` error, you would probably issue a `CreateBucket` operation. However, following this approach can cause issues: if the body has already been partially consumed, the upload will need to be aborted. A common solution to this issue, followed by other object storage providers, is to use the [HTTP `100`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/100) response to detect whether the body should be sent, or if the bucket must be created before retrying the upload. However, Cloudflare does not support the HTTP `100` response. Even if the HTTP `100` response was supported, you would still have additional latency due to the round trips involved.
 
 To support sending an upload with a streaming body to a bucket that may not exist yet, upload operations such as `PutObject` or `CreateMultipartUpload` allow you to specify a header that will ensure the `NoSuchBucket` error is not returned. If the bucket does not exist at the time of upload, it is implicitly instantiated with the following `CreateBucket` request:
 

src/content/docs/workers/examples/websockets.mdx

@@ -82,7 +82,7 @@ async fn fetch(req: HttpRequest, _env: Env, _ctx: Context) -> Result<worker::Res
 }
 ```
 </TabItem> </Tabs>
-After you have appropriately checked for the `Upgrade` header, you can create a new instance of `WebSocketPair`, which contains server and client WebSockets. One of these WebSockets should be handled by the Workers function and the other should be returned as part of a `Response` with the [`101` status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/101), indicating the request is switching protocols:
+After you have appropriately checked for the `Upgrade` header, you can create a new instance of `WebSocketPair`, which contains server and client WebSockets. One of these WebSockets should be handled by the Workers function and the other should be returned as part of a `Response` with the [`101` status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/101), indicating the request is switching protocols:
 
 
 <Tabs syncKey="workersExamples"> <TabItem label="JavaScript" icon="seti:javascript">

src/content/docs/workers/tutorials/build-a-qr-code-generator/index.mdx

@@ -75,7 +75,7 @@ export default {
 };
 ```
 
-Currently, if an incoming request is not a `POST`, the function will return `undefined`. However, a Worker always needs to return a `Response`. Since the function should only accept incoming `POST` requests, return a new `Response` with a [`405` status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405) if the incoming request is not a `POST`:
+Currently, if an incoming request is not a `POST`, the function will return `undefined`. However, a Worker always needs to return a `Response`. Since the function should only accept incoming `POST` requests, return a new `Response` with a [`405` status code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/405) if the incoming request is not a `POST`:
 
 ```js null {7,8}
 export default {