undocumented quirks of the Java server implementation

[lukeis]

Originally reported on Google Code with ID 3552

Selenium version: 2.20 (Java server)
OS: Debian Wheezy (testing)
Browser: Firefox
Browser version: default 2.20 version

The following are miscellaneous quirks I discovered in the Java server implementation
while implementing client bindings in Haskell. It's not clear to me whether these should
be part of the specification, or documented as being specific features of the Java
server. Documenting these implementation-specific features would ease the difficulty
of developing future clients, and perhaps lead to a more complete wire specification.

(1) it's undocumented that the Java server uses /wd/hub/ as the root path for all requests.

(2) HTTP status code 204 is used when there is no JSON return value. This behavior
is undocumented (and potentially useful for client developers to know about while designing
their client)

(3) the hCode and className fields on various JSON response objects are undocumented.
A minor issue, but one that could potentially throw off JSON parsers that are strictly
adhering to the specification. I was told this is an artifact of the Java serialization
code.

Reported by adamadamadamamiadam on 2012-03-13 21:05:40

[lukeis]

(1) All command paths are defined relative to an arbitrary root. The java server, which
is just one implementation of the spec, uses /wd/hub.

(2) Yes, we should probably document that 204 can be treated as equivalent to {status:0,
value:null}

(3) Yes, these are purely by-products of the Java serialization code. The spec only
defines what properties are expected in the returned JSON objects. It does not forbid
extra properties.  You may ignore any undocumented field.

Reported by jmleyba on 2012-03-13 22:34:12

• Status changed: Accepted
• Labels added: Component-Docs, Component-WebDriver

[lukeis]

Reported by luke.semerau on 2015-09-17 17:44:48

• Labels added: Restrict-AddIssueComment-Commit