From 806bc62caaee78a696a6c929558a5b801cceeec4 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Wed, 1 Jun 2016 17:55:39 +0200 Subject: [PATCH] Make navigate's resource handling more explicit This in general integrates navigation with Fetch better, reusing Fetch's infrastructure for network errors and for 401 handling. This also removes the speculative 401 features that seem unlikely to ever materialize. This definitely requires more work to actually talk about responses instead of resources, and to more clearly tie it to the "resource" variable from earlier in the navigate algorithm, but since all those interactions are still somewhat unclear this will have to do. See #1352 for plans in that direction. Fixes #511. --- source | 52 ++++++++++++++++------------------------------------ 1 file changed, 16 insertions(+), 36 deletions(-) diff --git a/source b/source index c3714142754..884c7226308 100644 --- a/source +++ b/source @@ -81766,45 +81766,24 @@ State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON O
  • +

    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:

    -
      -
    • HTTP status codes (e.g. 204 No Content or 205 Reset Content)
      • -
    • Network errors (e.g. the network interface being unavailable)
      • -
    • Cryptographic protocol failures (e.g. an incorrect TLS certificate)
      • - - - - -
    -
    - -

    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.

    • @@ -118771,6 +118750,7 @@ INSERT INTERFACES HERE Maik Merten, Majid Valipour, Malcolm Rowe, + Manish Goregaokar, Manish Tripathi, Marc Hoyois, Marco Zehe,