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

Keep track of errors so they can be exposed (if desired) in UX (and maybe API at some point) #352

Open
jakearchibald opened this Issue Aug 3, 2016 · 3 comments

Comments

2 participants
@jakearchibald
Copy link
Collaborator

jakearchibald commented Aug 3, 2016

https://fetch.spec.whatwg.org/#http-fetch 3.3 currently creates a generic network error. This means browsers display a generic error message if a navigation fails.

Ideally the browser should be able to display more relevant information like "bad certificate", "DNS failure", "You are offline", which I guess involves passing the error response back to the caller (navigation in this case).

@annevk suggests there are cases where this is a security issue, so a TODO is to find out what these are & when we can safely pass the error on.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 4, 2016

Are we talking about user-facing errors? Those are not typically exposed as they live in cross-origin documents.

If we're talking about exceptions coming from Fetch that'd be something else.

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Aug 4, 2016

I'm talking about user-facing errors. If the browser is deciding which error to show as part of navigation, by returning a generic error in 3.3 we're reducing its usefulness.

Or does this stuff live outside of spec land?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 4, 2016

We do handle it as part of navigation in HTML. And I think you're correct that the flow in the standard should make sure that if the user agent wants to expose more detail there, that it's actually available. But in large part this is UX so user agents are already free to do what they want (as long as the document they create meets certain invariants which are probably not interoperable at the moment).

@annevk annevk changed the title Passthrough original error response unless there's a security issue in doing so Keep track of errors so they can be exposed (if desired) in UX (and maybe API at some point) Aug 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment