Add description of DTLS transport error handling. #2064
Conversation
webrtc.html
Outdated
| a certificate validation failure, or a fatal alert (see RFC 5246 | ||
| section 7.2), the user agent MUST queue a task that runs the following | ||
| steps: | ||
| </p> |
There was a problem hiding this comment.
nit: Here and elsewhere - There shouldn't be an extra indent here and </p> should be on the line above
webrtc.html
Outdated
| <code><a data-lt="RTCDtlsTransport error">error</a></code> | ||
| using the <a>RTCErrorEvent</a> interface with its errorDetail | ||
| attribute set to either "dtls-failure" or "fingerprint-failure", | ||
| as appropriate, and |
There was a problem hiding this comment.
M-x fill-paragraph
webrtc.html
Outdated
| </p> | ||
| </li> | ||
| <li> | ||
| <p><a>Fire an event</a> named <code><a data-lt="RTCDtlsTransport state change">statechange</a></code> |
There was a problem hiding this comment.
If the state is not already "failed".....
There was a problem hiding this comment.
This is interesting - the most straightforward code path is to check if state is "failed" before setting the state, and aborting these steps if it's already failed - which will mean that you're guaranteed to never get more than one error notification for a DTLSTransport. (the handler for the error event should see state as "failed", not the state as it was prior to the error).
webrtc.html
Outdated
| a certificate validation failure, or a fatal alert (see RFC 5246 | ||
| section 7.2), the user agent MUST queue a task that runs the following | ||
| steps: | ||
| </p> |
webrtc.html
Outdated
| <code><a data-lt="RTCDtlsTransport error">error</a></code> | ||
| using the <a>RTCErrorEvent</a> interface with its errorDetail | ||
| attribute set to either "dtls-failure" or "fingerprint-failure", | ||
| as appropriate, and |
There was a problem hiding this comment.
M-x fill-paragraph
webrtc.html
Outdated
| </p> | ||
| </li> | ||
| <li> | ||
| <p><a>Fire an event</a> named <code><a data-lt="RTCDtlsTransport state change">statechange</a></code> |
There was a problem hiding this comment.
This is interesting - the most straightforward code path is to check if state is "failed" before setting the state, and aborting these steps if it's already failed - which will mean that you're guaranteed to never get more than one error notification for a DTLSTransport. (the handler for the error event should see state as "failed", not the state as it was prior to the error).
alvestrand
force-pushed
the
dtlstransport-failure
branch
from
359845c
to
eb696ab
Compare
Fixes #2044
Preview | Diff