Re: Session ID in responses

On Tue, Sep 27, 2016 at 2:18 PM, Andreas Tolfsen <ato@mozilla.com> wrote:

> 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.
>

This is workable, but end nodes (and intermediary nodes) should also
probably set the "Referer" header to make this simpler. I'm not sure any do
now.


> 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
>

I've sent a follow up proposal to this.

Simon