You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the browsing context, then perform that processing and abort these steps.
Note: 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)
and it goes on to explain how downloads should be handled.
I think we should be clearer here with an exhaustive list of what sorts of responses the spec requires the user agent to abort the navigation with.
Additionally, not all of these are handled the same way. 204 and 205 should require the user agent to not navigate (and not unload the current page). Downloads probably should require the same. On the other hand, network or crypto errors can leave navigation up to the user agent (most user agents navigate to an error page).
Currently we don't seem to require anything here. For javascript: links to work, 204 needs to be handled without navigation, which isn't mandated by the spec at all.
The text was updated successfully, but these errors were encountered:
Also remove the speculative 401 features that seem unlikely to ever
materialize. This definitely requires more work to actually talk about
responses instead of resources and 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.
Fixes#511.
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.
https://html.spec.whatwg.org/multipage/#navigating-across-documents
Step 21 mentions
and it goes on to explain how downloads should be handled.
I think we should be clearer here with an exhaustive list of what sorts of responses the spec requires the user agent to abort the navigation with.
Additionally, not all of these are handled the same way. 204 and 205 should require the user agent to not navigate (and not unload the current page). Downloads probably should require the same. On the other hand, network or crypto errors can leave navigation up to the user agent (most user agents navigate to an error page).
Currently we don't seem to require anything here. For
javascript:
links to work,204
needs to be handled without navigation, which isn't mandated by the spec at all.The text was updated successfully, but these errors were encountered: