This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29157 - Need a /status end point for wire protocol
Summary: Need a /status end point for wire protocol
Status: RESOLVED FIXED
Alias: None
Product: Browser Test/Tools WG
Classification: Unclassified
Component: WebDriver (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Browser Testing and Tools WG
QA Contact: Browser Testing and Tools WG
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 20860
  Show dependency treegraph
 
Reported: 2015-09-28 21:16 UTC by Jim Evans
Modified: 2015-10-23 13:21 UTC (History)
3 users (show)

See Also:


Attachments

Description Jim Evans 2015-09-28 21:16:40 UTC
There is a potential race condition in most shims and local ends, in that there may be some time between when a shim's process is launched, and it's HTTP server is ready to receive requests. Having a /status end point that a local end can poll to determine that not only is the executable started, but the HTTP server is correctly responding to requests.
Comment 1 Andreas Tolfsen 2015-10-04 18:01:06 UTC
When the HTTP client is able to request the endpoint, is this not enough confirmation the remote end is ready to receive commands?
Comment 2 Jim Evans 2015-10-05 15:53:11 UTC
There's a potential use case where the user wants to be able to start the shim, but not immediately start a session. Also, consider the case where the shim can support more than one session during its execution (a scenario not explicitly excluded by the spec). There is no other end point that is valid other than those that (1) create a new session, or (2) require an existing session. The end point does not even need to be "/status"; we could leverage a "GET" verb on the existing "/session" end point. There should simply be an idempotent, no-op end point that a local end can query to validate that, "Yes, the remote end is alive, and responding to requests."
Comment 3 David Burns :automatedtester 2015-10-19 13:55:37 UTC
added this in https://github.com/w3c/webdriver/pull/278

All implementations appear to have added this according to the WebDriver JSON Wire Protocol so we might as well add it here.
Comment 4 David Burns :automatedtester 2015-10-23 13:21:40 UTC
this has landed in 0e48b3321838b35c0ba6ac5ef1c7752a7dc64b0c