W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > July to September 2014

Re: Status indicating intermediary server problems

From: Simon Stewart <simon.m.stewart@gmail.com>
Date: Fri, 26 Sep 2014 16:16:28 +0100
Message-ID: <CAOrAhYE83FJcOfJQLeV-b+19NE-q2hEHdNWJKEjV_S2XCHVJEw@mail.gmail.com>
To: David Burns <dburns@mozilla.com>
Cc: Andreas Tolfsen <ato@mozilla.com>, public-browser-tools-testing <public-browser-tools-testing@w3.org>
Or 523.

Simon

On Fri, Sep 26, 2014 at 4:16 PM, Simon Stewart <simon.m.stewart@gmail.com>
wrote:

> From the end user's point of view, what's the difference? And how is this
> different from a normal HTTP request where a proxy chokes? As far as each
> step on the path from local to remote end goes, the "next hop" _is_ the
> remote end, so it'd be hard for an intermediary to know whether or not the
> problem was caused by the remote end failing to respond or another node?
>
> Would a 502 or 504 HTTP response be appropriate?
>
> Simon
>
> On Fri, Sep 26, 2014 at 3:18 PM, David Burns <dburns@mozilla.com> wrote:
>
>> Just for clarification, this error would not come from the UA part of the
>> Remote End but from the HTTP Endpoint if something goes wrong.
>>
>> David
>>
>>
>> On 24/09/2014 18:39, Andreas Tolfsen wrote:
>>
>>> There is currently no way to determine where a command fails if you
>>> have one or more intermediary servers sitting in between the local and
>>> remote ends.
>>>
>>> If for example you use a proxy like a Selenium remote server between
>>> your client and your driver, there's no way to find out whether an
>>> unsuccessful response/error was caused by the driver or the proxy.
>>>
>>> I'm currently in a situation where I have multiple proxies sitting
>>> between the local and final remote end where if one of the proxies
>>> have an internal problem or the next remote fails to reply, it would
>>> be useful for it to return a response indicating the problem is caused
>>> by the intermediary rather than the driver.
>>>
>>> For this reason I'm proposing to introduce a new status called “proxy
>>> error” or “intermediate error”.
>>>
>>> This error would not be possible to use for the driver
>>> implementations, but could be used by intermediary remotes, such as
>>> proxies, to say that an error occurred in their domain, and that the
>>> command never made it all the way to the driver.
>>>
>>>
>>
>>
>
Received on Friday, 26 September 2014 15:16:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 February 2015 15:39:03 UTC