Selenium: Cloud providers and Grid could benefit from client bindings sending in version and platform info.

Created on 21 Mar 2018 · 20Comments · Source: SeleniumHQ/selenium

As a cloud provider, we would absolutely love a key in the new session request that says something like “hi I’m version X.Y of the Java bindings running on macOS 10.13” — along the lines of an HTTP User-Agent. This would help with diagnosing bugs and incompatibilities, especially when dealing with a wide variety of versions of both the client bindings and Selenium server and drivers. For similar reasons, I suspect it might also be useful for Grid to log this info.

I'd be happy to contribute code for this across a bunch of the bindings, if people think it's a good idea and we can agree on where to put it and what the format should be.

I-enhancement

Source

sah

👍1

Most helpful comment

So, we'd have things like:

User-Agent: selenium//3.14 (java windows)
User-Agent: selenium//3.14 (python linux)

Other projects can follow the convention, but they are not Selenium and should change the product name accordingly

User-Agent: webdriverio//4.9 (js windows)

jleyba on 26 Mar 2018

👍2

All 20 comments

Is it okay to put that information in an HTTP header? Specifically the User-Agent header?

shs96c on 21 Mar 2018

Sure, that would work. Could even tailor the actual User-Agent...

sah on 21 Mar 2018

We should probably decide on a standard User-Agent format for the project so we're consistent across the different bindings.

jleyba on 21 Mar 2018

Are we planning to overwrite the User-Agent header which is generated by the underlying HTTP library the bindings use?

I recommend using a new non-standard header (something like Selenium-Client-Ver) for sending the binding version, so that it can be succinct (and unambiguous), plus we don't have to worry about adding content to any existing header(s).

pulkitsharma07 on 21 Mar 2018

How about: X-Selenium-Version: ${LANGUAGE}[-${COMPONENT}]@${VERSION}

Possible values:

Use multiple values to capture nodes in a grid. For example:

X-Selenium-Version: [email protected],[email protected],[email protected]

indicates a request came from a grid server (v3.8.1), which is forwarding a request from another grid at v3.7, which received the initial request from a client using 3.8.1.

jleyba on 22 Mar 2018

👍1

@jleyba I like where you're going with that, but it doesn't add in the OS information as was in the original request. Moreover, I'm not entirely sure how we can get a satisfactory OS information string together that would please everyone.

And let's be very clear here, I'm in favor of this if it is _only_ to be applied on new session requests, and is _optional_, meaning that third parties and intermediate nodes can't depend on it, but could make use of it if and only if it's present.

jimevans on 22 Mar 2018

👍1

@jleyba I think putting this in the User-Agent header makes the most sense, and from the local end should be: selenium//${version} (${language} ${platform-family}). That's a little more in line with how the MDN docs suggest a UA string should be formed.

I'm not sure about the concatenation thing, but if we did it, then we'd want to look at the routing headers in emails as an example to follow.

@jimevans UA strings are definitely not things that people should rely on. I'm curious about why you think it should only be for new session requests. Will discuss that with you on IRC.

shs96c on 22 Mar 2018

Would ${platform-family} have any more granularity than what is supported in W3C capabilities? I wouldn't want to send anything more detailed without giving users an easy opt-out.

jleyba on 22 Mar 2018

Platform family ends up matching the suggested default allowed platforms from the spec (macos, windows, linux)

shs96c on 22 Mar 2018

Sounds like User-Agent may be the direction being settled on here, but just in case it's not, FYI X- headers are no longer considered best practice: https://tools.ietf.org/html/rfc6648

${language} doesn't contemplate third-party bindings; there are multiple binding libraries in widespread use for js and PHP, for example. Maybe ${language} ${library}, where official libraries use something like official or selenium as the library name?

sah on 22 Mar 2018

Or maybe third-party libraries would change the selenium//${version} part?

sah on 22 Mar 2018

@cgoldberg Sincewe are talking about the HTTP communication between the language bindings and WebDriver remote ends, not modifying the UA string between the browser/mobile app and the web server, I’m not sure how that affects sniffing that web apps, even mobile ones would do.

jimevans on 23 Mar 2018

@jimevans my bad :)

cgoldberg on 23 Mar 2018

@sah I'd suggest other implementations do something based on what we decide here, but it's entirely up to them.

shs96c on 23 Mar 2018

@shs96c Sure, they'll make their own decisions, but it would be nice if what's decided here leaves an easy & obvious way for them to fit gracefully into the format if they so choose.

sah on 23 Mar 2018

So, we'd have things like: