WebDriver

Various parts of this specification are written in terms of step-by-step algorithms. The details of these algorithms do not have any normative significance; implementations are free to adopt any implementation strategy that produces equivalent output to the specification. In particular, algorithms in this document are optimized for readability rather than performance.

Where algorithms that return values are fallible, they are written in terms of returning either success or error. A success value has an associated data field which encapsulates the value returned, whereas an error value has an associated error code.

When calling a fallible algorithm, the construct “Let result be the result of trying to call algorithm” is equivalent to

1. Let temp be the result of calling algorithm.

2. If temp is an error return temp, otherwise let result be temp's data field.

The result of getting a property with name from object is defined as being the same as the result of calling Object.[[GetOwnProperty]](name) on object.

The result of getting a property with default with arguments name and default from object is defined as being the same as the result of calling Object.[[GetOwnProperty]](name) on object if that results in a value other than undefined and default otherwise.

Setting a property with arguments name and value on object is defined as being the same as calling Object.[[Put]](name, value) on object.

The result of JSON serialization with object of type JSON Object is defined as the result of calling stringify(object).

The result of JSON deserialization with text is defined as the result of calling parse(text).

The WebDriver protocol is organized into commands. Each HTTP request with a method and template defined in this specification represents a single command, and therefore each command produces a single HTTP response.

In response to a command, a remote end will run a series of actions known as remote end steps. These provide the sequences of actions that a remote end takes when it receives a particular command.

The remote end is an HTTP server reading requests from the client and writing responses, typically over a TCP socket. For the purposes of this specification we model the data transmission between a particular local end and remote end with a connection to which the remote end may write bytes and read bytes. However the exact details of how this connection works and how it is established are out of scope.

After a connection is established, the remote end must run the following steps:

1. While the connection is not closed:

   1. Read bytes from the connection until a complete HTTP request can be constructed from the data. Let request be a request constructed from the received data, according to the requirements of [RFC7230]. If it is not possible to construct a complete HTTP request, the remote end must either close the connection, return an HTTP response with status code 500, or return an error with error code unknown error.

   2. Let request match be the result of the algorithm to match a request with request's method and URL as arguments.

   3. If request match is of type error, send an error with request match's error code and continue.

      Otherwise, let command and URL variables be request match's data.

   4. Let session be null.

   5. If URL variables contains "session id":

      Note

      This condition is intended to exclude the New Session and Status commands and any extension commands which do not operate on a particular session.

      1. Let session id be URL variables["session id"].

      2. For each active session in the list of active sessions:

         1. If active session's session ID is equal to session id, then let session be active session, and break.

      3. If the session is null send an error with error code invalid session id, then continue.

   6. Enqueue a task on remote end's request queue to run the following steps:

      1. If session is no longer in the list of active sessions, then send an error with error code invalid session id and return.

      2. Let parameters be null.

      3. If request's method is POST:

         1. Let parse result be the result of parsing as JSON with request's body as the argument. If this process throws an exception, return an error with error code invalid argument and jump back to step 1 in this overall algorithm.

         2. If parse result is not an Object, send an error with error code invalid argument and jump back to step 1 in this overall algorithm.

            Otherwise, let parameters be parse result.

      4. Let navigate result be the result of wait for navigation to complete with session.

      5. If navigate result is an error, send an error with error code equal to navigate result's error code and return.

      6. Let response result be the return value obtained by running the remote end steps for command with session, URL variables, and parameters.

      7. If response result is an error, send an error with error code equal to response result's error code and return.

      8. Assert: response result is a success.

      9. Let response data be response result's data.

      10. Send a response with status 200 and response data.

When required to send an error, with error code and an optional error data dictionary, a remote end must run the following steps:

1. Let status and name be the error response data for error code.

2. Let message be an implementation-defined string containing a human-readable description of the reason for the error.

3. Let stacktrace be an implementation-defined string containing a stack trace report of the active stack frames at the time when the error occurred.

   Let body be a new JSON Object initialized with the following properties:

   "error"

   name

   "message"

   message

   "stacktrace"

   stacktrace

4. If the error data dictionary contains any entries, set the "data" field on body to a new JSON Object populated with the dictionary.

5. Send a response with status and body as arguments.

When required to send a response, with arguments status and data, a remote end must run the following steps:

1. Let response be a new response.

2. Set response's HTTP status to status, and status message to the string corresponding to the description of status in the status code registry.

3. Set the response's header with name and value with the following values:

   Content-Type

   "application/json; charset=utf-8"

   Cache-Control

   "no-cache"

4. Let response's body be the UTF-8 encoded JSON serialization of a JSON Object with a key "value" set to data.

5. Let response bytes be the byte sequence resulting from serializing response according to the rules in [RFC7230].

6. Write response bytes to the connection.

Request routing is the process of going from an HTTP request to the series of steps needed to implement the command represented by that request.

A remote end has an associated URL prefix, which is used as a prefix on all WebDriver-defined URLs on that remote end. This must either be undefined or a path-absolute URL.

In order to match a request given a method and URL, the following steps must be taken:

1. Let endpoints be a list containing each row in the table of endpoints.

2. Remove each entry from endpoints for which the concatenation of the URL prefix and the entry's URI template does not have a valid expansion equal to URL's path.

3. If there are no entries in endpoints, return error with error code unknown command.

4. Remove each entry in endpoints for which the method column is not equal to method.

5. If there are no entries in endpoints, return error with error code unknown method.

6. There is now exactly one entry in endpoints; let entry be this entry.

7. Let URI template be the concatenation of URL prefix with entry's URI template.

8. Let command be entry's command.

9. Let URL variables be a map with one entry for each variable defined in URI template, with the entry name equal to the template variable name, and the entry value being the variable value required to expand the URI template to match URL's path.

10. Return success with data command and URL variables.

The following table of endpoints lists the method and URI template for each endpoint node command. Extension commands are implicitly appended to this table.

Errors are represented in the WebDriver protocol by an HTTP response with an HTTP status in the 4xx or 5xx range, and a JSON body containing details of the error. The body is a JSON Object and has a field named "value" whose value is an object bearing three, and sometimes four, fields:

• "error", containing a string indicating the error code.
• "message", containing an implementation-defined string with a human readable description of the kind of error that occurred.
• "stacktrace", containing an implementation-defined string with a stack trace report of the active stack frames at the time when the error occurred.
• Optionally "data", which is a JSON Object with additional error data helpful in diagnosing the error.

The following table lists each error code, its associated HTTP status, JSON error code, and a non-normative description of the error. The error response data for a particular error code is the values of the HTTP Status and JSON Error Code columns for the row corresponding to that error code.

An error data dictionary is a mapping of string keys to JSON serializable values that can optionally be included with error objects.

Using the terminology defined in this section, others may define additional commands that seamlessly integrate with the standard protocol. This allows vendors to expose functionality that is specific to their user agent, and it also allows other web standards to define commands for automating new platform features.

Commands defined in this way are called extension commands and behave no differently than other commands; each has a dedicated HTTP endpoint and a set of remote end steps.

Each extension command has an associated extension command URI Template that is a URI Template string, and which should bear some resemblance to what the command performs. This value, along with the HTTP method and extension command, is added to the table of endpoints and thus follows the same rules for request routing as that of other built-in commands.

In order to avoid potential resource conflicts with other implementations, vendor-specific extension command URI Templates must begin with one or more path segments which uniquely identifies the vendor and UA. It is suggested that vendors use their vendor prefixes without additional characters as outlined in [CSS21], notably in section 4.1.2.2 on vendor keywords, as the name for this path element, and include a vendor-chosen UA identifier.

Other specifications may define additional WebDriver capabilities. Each defined capability must have a capability name which is a string not containing a ":" (colon) character, an additional capability deserialization algorithm which is a set of steps taking a single argument value which has a JSON type, returning either success wrapping the deserialized capability value or error.

An additional WebDriver capability may also define a matched capability serialization algorithm, which is a set of steps used to determine if a capability is matched by the current implementation and provide any computed value to return to the user. This set of steps takes a single argument value, which is the output of the corresponding