In Appium, what happens when a session request sends a vendor capability with no appium: prefix?
answer
- the server checks names first
- no namespace, no session
- invalid argument, not a warning
- prefixed typos fail quietly instead
basics
~20 sThe Appium server refuses the session and answers with an invalid argument error naming the key. A non-standard capability with no colon namespace is illegal under the W3C protocol, so it is rejected rather than quietly ignored.
solid answer
~40 sValidation happens on the server before any device work. Appium checks each key in the posted capabilities object: if it is one of the twelve W3C standard names it is allowed bare, and if it carries a namespace such as `appium:` it is a legal extension capability. A name that is neither is not a capability the protocol admits, so the server raises an invalid argument error, names the offending key, and creates no session — no emulator boots, no on-device agent starts. Note the asymmetry: an unprefixed non-standard key is a hard failure, while a *prefixed* key the driver does not recognise is accepted and simply never read, unless the server was started with `--strict-caps`. Also, `POST /session` accepts a `capabilities` object only; `desiredCapabilities` is not a fallback that relaxes the rule.
go deeper
Be ready to say that a missing appium: prefix on a non-standard capability stops the session from being created at all, and that the error names the key you got wrong.
Explain the check itself: the server validates each capability name against the standard set or a colon namespace, before driver selection, and rejects anything that is neither.
Show that you can separate the loud failure from the quiet one — a missing prefix kills the session, a prefixed name nobody reads costs you a silently unapplied setting until --strict-caps is on.
Decide where this class of mistake is caught for the whole organisation: typed capability builders, a validated schema, or a shared server with strict capability checking so no suite ships a setting that never applied.
## The check that happens before any device work When a client asks Appium for a session, the whole capability set arrives as one JSON object on `POST /session`. Long before a driver is chosen, an emulator is booted or an agent is installed, the server walks that object key by key and asks a single question of each name: is this a capability the W3C WebDriver protocol allows here? There are only two ways to pass: - The name is one of the twelve **standard capabilities** the specification defines — among them `platformName`, `browserName`, `timeouts` and `webSocketUrl` — in which case it is legal bare. - The name carries a **namespace containing a colon**, which marks it as an extension capability owned by a vendor. Appium's namespace is `appium:`. A name that satisfies neither is not merely unknown. It is malformed, because the protocol has no slot for an un-namespaced non-standard capability, and the server treats it that way. ## What the rejection looks like The request fails with an **invalid argument** error that names the offending capability, and no session id comes back. Nothing downstream runs: on Android no helper server is pushed to the device, and on Apple platforms no WebDriverAgent build or launch is attempted. That is a useful property — the failure is cheap, deterministic and identical on every machine, which is why it usually shows up the very first time a hand-written capability set is used rather than intermittently. It is also worth knowing that `POST /session` takes a `capabilities` object only. The old `desiredCapabilities` envelope is not an alternative route that skips this check, so there is no legacy shape to fall back on when a key is refused. ## The opposite failure mode: a prefixed key nobody reads The symmetric mistake behaves in the opposite way, and confusing the two costs a lot of debugging time. If the key **is** namespaced but the chosen driver has no idea what it means — a typo inside the name, a capability that belongs to a different driver, a setting that was renamed — then it is a perfectly legal extension capability. The server accepts it, records that it was not recognised, and the driver never reads it. The session starts and the behaviour you asked for silently does not happen. Appium ships a server flag, `--strict-caps`, that turns that silence into a failure by rejecting capabilities the selected driver does not recognise. Without it, the default is permissive. | What you sent | Result | |---|---| | Bare standard name, e.g. `platformName` | accepted, applied | | Namespaced name the driver knows, e.g. `appium:automationName` | accepted, applied | | Namespaced name the driver does not know | accepted, ignored, session still starts | | Bare non-standard name, e.g. `appPackage` | invalid argument error, no session | ## A worked case on a community-garden plot app A suite for a community-garden plot app runs an **Android** target with `platformName`, `appium:automationName` naming UiAutomator2 and Android's `appium:appPackage` for the plot app. Someone trims the namespace off the last one while tidying a config, leaving a bare `appPackage`. The next run does not install the wrong build or open the wrong screen — it never reaches the device at all. The server answers the session request with an invalid argument error naming `appPackage`, and every case in the run fails at setup with the same message. The same edit on an **Apple** target, leaving a bare `bundleId` instead of `appium:bundleId`, fails identically. The prefix rule is a protocol rule, not a platform rule, so the two platforms behave the same way here even though the key names differ. ## Reading the failure quickly 1. Read the error text for the capability name it quotes; the server tells you which key it objected to. 2. Decide whether that name is one of the twelve W3C standard names. If it is not, it needs `appium:`. 3. If the name is already namespaced and the session still failed, the problem is the value or a driver constraint, not the prefix. 4. If the session *started* but a setting had no effect, look for the opposite failure — a namespaced name that no driver reads. ## Two rules worth memorising - Missing prefix means a loud failure at session creation, with no session id. - Wrong name behind a correct prefix means a quiet no-op, unless `--strict-caps` is on.
- Does the session fail before or after the device is touched?Before. Capability validation is a server-side check on the posted JSON, so it happens ahead of driver selection and ahead of any device work — no emulator boot on Android, no WebDriverAgent build on Apple platforms. The failure is therefore fast, deterministic and identical on every machine that sends the same payload.
- If I add the prefix but misspell the rest of the name, what happens?The opposite failure. A misspelled but namespaced key is still a legal extension capability, so the server accepts it and the driver simply never reads it: the session starts and the setting has no effect. Running the server with `--strict-caps` converts that silent no-op into a failed session.
- Can sending desiredCapabilities instead avoid the rejection?No. `POST /session` takes a `capabilities` object only, so there is no legacy envelope to fall back on. Anything sent under an old-style key is not a route around the prefix rule; the capability set has to be spelled correctly in the modern shape.
A courier delivers to a bare street name only if it is one of a dozen landmarks everyone knows; any other address must name the building's owner, or the parcel is refused at the depot rather than wandering the city.
saying these in an interview costs you the question
- Says an unprefixed capability is accepted and merely logged
- Expects the driver to guess the namespace from the key name
- Thinks the session starts and fails later on the device
- Confuses a missing prefix with a prefixed key the driver ignores
- Claims sending desiredCapabilities bypasses the check