Skip to content

Allow intercepts to provide a list of known network error types #508

Open

Description

@jgraham

The main work here is to work out what the specific types of error we can talk about in a cross-browser way. Once we have that, most of the actual behaviour is defined by the implementation's network stack.

Activity

  1. thiagowfx commented on Sep 19, 2023

    @thiagowfx
    Member

    CDP reference (could be used as a starting point for a subset of errors): https://chromedevtools.github.io/devtools-protocol/tot/Network/#type-ErrorReason

    Allowed Values: Failed, Aborted, TimedOut, AccessDenied, ConnectionClosed, ConnectionReset, ConnectionRefused, ConnectionAborted, ConnectionFailed, NameNotResolved, InternetDisconnected, AddressUnreachable, BlockedByClient, BlockedByResponse
    
  2. Lightning00Blade commented on May 29, 2024

    @Lightning00Blade
    Contributor

    @jgraham I looked a little bit in this.
    A good starting point can be Aborted one as that has reference in the Fetch spec.
    And it translates to user has aborted the request (via AbortController).

    All the other CDP accepted strings look like TCP errors.
    There seems to be no list of them on the TCP spec itself.

    The CDP map is defined here and all network errors here

    Another spec that uses TCP errors - https://www.w3.org/TR/network-error-logging/#secure-connection-establishment-errors also does not link back to the spec.

    With this in mind I think we should agree on a sub-set that of them or define them as string with a optional if implementation does not support it throw "unsupported operation" error.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions