Resource handling: If the resource is a network error, then display the inline content with an appropriate error shown to the
+ user and with the newly created Document object's origin set to
+ a new opaque origin.
Resource handling: If the resource's out-of-band metadata (e.g. HTTP headers), not - counting any type information (such as the Content-Type HTTP - header), requires some sort of processing that will not affect browsingContext, then - perform that processing and abort these steps.
- -Such processing might be triggered by, amongst other things, the following:
-Responses with HTTP `Content-Disposition`
- headers specifying the attachment disposition type must be handled
- as a download.
HTTP 401 responses that do not include a challenge recognised by the user agent must be - processed as if they had no challenge, e.g. rendering the entity body as if the response had - been 200 OK.
+This is where the network errors defined and propagated by the WHATWG Fetch + standard, such as DNS or TLS errors, end up being displayed to users.
+User agents may show the entity body of an HTTP 401 response even when the response does - include a recognised challenge, with the option to login being included in a non-modal fashion, - to enable the information provided by the server to be used by the user before authenticating. - Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against - authentication challenges included in other responses such as HTTP 200 OK responses, effectively - allowing resources to present HTTP login forms without requiring their use.
+If the resource's status is
+ 204 or 205, then abort these steps.
If the resource has an `Content-Disposition` header specifying the attachment disposition type, then handle it as a download.
Let type be the computed type of the resource.