Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We should be clearer about hard requirements in "processing that will not affect the browsing context" #511

Closed
Manishearth opened this issue Jan 13, 2016 · 3 comments
Assignees
Labels
clarification Standard could be clearer topic: navigation

Comments

@Manishearth
Copy link

https://html.spec.whatwg.org/multipage/#navigating-across-documents

Step 21 mentions

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.

@annevk annevk added the clarification Standard could be clearer label Jan 14, 2016
@annevk annevk self-assigned this May 30, 2016
annevk added a commit that referenced this issue May 30, 2016
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.
@annevk
Copy link
Member

annevk commented May 30, 2016

Wrote something that makes this a little less speculative, but still lots of work to do.

@annevk
Copy link
Member

annevk commented May 30, 2016

Although I think it's sufficient to close this particular issue, by the way. Let me know if you disagree.

domenic pushed a commit that referenced this issue Jun 1, 2016
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.
@annevk
Copy link
Member

annevk commented Jun 3, 2016

Thanks again for raising this, much appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer topic: navigation
Development

No branches or pull requests

3 participants