Re: Session ID in responses

Olá Simon and James,

James Graham <james@hoppipolla.co.uk> writes:

> Responding with something that must be known at request time and is
> indeed part of the request URL seems like pointless extra traffic for
> very little advantage. If this means that some intermediaries need to
> store a mapping between request url and some handle to get the
> response, I feel I can live with that.

I feel the same.

The session ID is always present in the URL path, and it doesn’t seem
unreasonable to demand that intermediary nodes preserve a reference to
the session ID like the local ends need to do when they create a new
session.

The design of the response bodies in the protocol also makes it harder
to make this change, because the W3C version does not wrap every value
in a {"value": …} object like the Selenium protocol does: return values
that are naturally JSON Objects, such as web elements and web windows,
are returned as-is.

Anything that isn’t an object is still wrapped in {"value": …} objects
because JSON parsers can’t seem to agree amongst themselves whether
lists, booleans, and strings are allowed types to have at the root
level.

Received on Tuesday, 27 September 2016 13:19:30 UTC