Proxy returns an empty array of tabs for a few seconds after launch

[klepikov]

1. Have Safari running on a tethered iOS device.
2. Launch the proxy with -c :9222 (not sure if -c matters).
3. Quickly (as in -- scripted) make requests to http://localhost:9222/json.

A few first requests will return "[]", then it will begin returning a correct list of tabs.

I suspect it's a race between the HTTP requests and the proxy's handshake with the device.

Could the proxy hold HTTP responses until the handshake is done? The requests would just take a few seconds when made right after launching the proxy.

[zwri]

On Sun, Feb 17, 2013 at 3:21 PM, Michael Klepikov
[email protected]:

1. Have Safari running on a tethered iOS device.
2. Launch the proxy with -c :9222 (not sure if -c matters).
3. Quickly (as in -- scripted) make requests to
   http://localhost:9222/json.

A few first requests will return "[]", then it will begin returning a
correct list of tabs.

I suspect it's a race between the HTTP requests and the proxy's handshake
with the device.

Right. It's actually two steps: proxy sends reportId, device responds
with appId list (usually just "safari"), proxy sends getListing for every
appId, device responds with list of tabs.

Could the proxy hold HTTP responses until the handshake is done? The
requests would just take a few seconds when made right after launching the
proxy.

Yes, but it'd be somewhat awkward to implement.

How about a 503 "Service Unavailable" error with a "Retry-After: 2" --
where 2 seconds is arbitrary?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.37

Will your client automatically retry for you? Or, equivalently, is it easy
to add this timer retry in your client?

Todd

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5.

[zwri]

Hmm, I just thought of a clean way to do this in the proxy. I'll try it out
and let you know.

Todd

[klepikov]

If that's any simpler, it would also be ok to hold off listening on the HTTP port until the handshake is done. The parent process that launches the proxy and makes HTTP requests to it, is either way obligated to deal with the delay until the proxy starts listening. Making the start-to-listen delay a few seconds longer should not break a correctly implemented launch + request logic.

My main complaint is basically the surprise factor -- the proxy is reporting an empty array when a device has been connected with the browser running, before the proxy was launched. If I am plugging in a new device or starting a new browser session while the proxy is running, it is reasonable to expect some delay before the proxy begins reporting the new tabs. OTOH if the proxy could know that a handshake is in progress and holds HTTP responses until it's done (and includes the new results in those responses), that would be ideal -- would minimize or eliminate the reporting delay even for newly plugged devices and newly started browsers.