Re: [DOMError]: Subclassing DOMError to increase granularity of error handling?
Jonas Sicking <[email protected]>
| Newsgroups | gmane.comp.web.dom.general |
|---|---|
| Message-ID | <CA+c2ei_D4xwPCgH07SUDO4jHNZPLh_kx6On8VsJgTOYOH6KHjQ@mail.gmail.com> |
On Aug 8, 2013 4:33 AM, "Simon Pieters" <[email protected]> wrote: > > On Thu, 08 Aug 2013 13:05:07 +0200, Nilsson, Claes1 <[email protected]> wrote: > >> This is not just for debugging. Looking at the example I give in the mail, i.e. when the attempt to create a TCP socket fails I expect the web application to handle each error situation ("no network contact","peer does not respond", "local address/port pair is already in use") differently. > > > Usually we don't expose why a network connection fails to scripts in order to not reveal information behind the user's firewall to attackers. The goal of the TCPSocket API is to expose a low-level TCP API. So it already has the ability to read stuff behind firewalls. In fact, one of the goals of the API is to enable connecting to hardware that lives behind the same firewall as where the user is. Which is why the API is restricted to more trusted environments and why it's being developed in the SysApps WG rather than the WebApps WG. / Jonas