This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21876 - It would be nice to distinguish error events. For example, specific errors should be generated for access control failures and for different kinds of underlying network failures.
Summary: It would be nice to distinguish error events. For example, specific errors sh...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-30 12:48 UTC by contributor
Modified: 2013-06-18 23:27 UTC (History)
3 users (show)

See Also:


Attachments

Description contributor 2013-04-30 12:48:56 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html
Multipage: http://www.whatwg.org/C#event-source-fail-reasons
Complete: http://www.whatwg.org/c#event-source-fail-reasons
Referrer: 

Comment:
It would be nice to disable error events. For example, specific errors should
be generated for access control failures and for different kinds of underlying
network failures.

Posted from: 85.223.109.191
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130428 Firefox/22.0
Comment 1 Dirkjan Ochtman 2013-04-30 13:20:07 UTC
I ran into this while testing EventSource today (as a somewhat unsuspecting webdev who does some Mozilla things once in a while). I actually ran into two problems that could be much easier to debug (seemingly without incurring a large implementation burden).

- Require implementations to raise errors on connection soon after actually connecting. Gecko apparently doesn't do this: https://bugzilla.mozilla.org/show_bug.cgi?id=780396.

- Require implementations to throw more specific error events. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=867105 about access control / CORS.

Combined, these made for a big WTF on my first try of implementing this. I was suspecting CORS errors to be raised immediately (and clearly). Instead, I got a generic error only after getting the server to send a first event.

The second WTF was generic failure on timeout. My server requires setting a heartbeat explicitly, so making it clear that there was a timeout would have made this much easier. I suspect the usual network error suspects should have somewhat specific errors, at least.
Comment 2 Ian 'Hixie' Hickson 2013-04-30 18:18:45 UTC
We should definitely encourage browsers to report detailed errors to their consoles, but we can't report detailed errors to the script, because that would allow this to be used to do intranet port-scanning and resource discovery, which would be a huge security problem.
Comment 3 Dirkjan Ochtman 2013-05-23 07:17:17 UTC
Is there anything I can do to help move this forward?
Comment 4 Ian 'Hixie' Hickson 2013-06-11 22:15:19 UTC
One thing to do would be to file bugs on the browsers directly, asking for more information, giving specific examples (test cases) where the current debugging information is inadequate.

As far as the spec goes, I can add some suggestions in the EventSource section saying that in case of errors, detailed information should be logged so the developer can see it, would that help?
Comment 5 Dirkjan Ochtman 2013-06-12 07:19:00 UTC
As I mentioned in comment 1, I already filed bugs about this for Gecko. WebKit/Blink already log CORS errors to the console, at least. This bug was filed based on suggestion there, see https://bugzilla.mozilla.org/show_bug.cgi?id=867105#c1.

So yes, it would be helpful if you could add some suggestions to the spec. CORS errors and underlying network errors would seem like no-brainer cases to me.
Comment 6 Ian 'Hixie' Hickson 2013-06-18 23:25:51 UTC
I've added a section (see diff below). Please do file a new bug if you see anything else that we should encourage user agents to report. Thanks!
Comment 7 contributor 2013-06-18 23:27:55 UTC
Checked in as WHATWG revision r7988.
Check-in comment: Encourage more detailed debugging aids for EventSource
http://html5.org/tools/web-apps-tracker?from=7987&to=7988