W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013


From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 18 Jun 2013 15:32:42 -0700
Message-ID: <CABkgnnW0vB29sgTU3DJ3xbcP1r5xo881AgqS6vJQ8Ht=jAbPZQ@mail.gmail.com>
To: Roberto Peon <fenix@google.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 18 June 2013 15:23, Roberto Peon <fenix@google.com> wrote:
> Is this sufficiently different from PROTOCOL_ERROR that it is needed (I view
> that as the why, as opposed to what to do)? If not, should we have
> suggestions about appropriate behavior in response to PROTOCOL_ERROR?

In my view, this is very much in the same bucket as the proposed
COME_BACK code.  The motivation is basically sound.  Both require that
a client observe a particular GOAWAY code and amend their behavior for
a subsequent connection to the server.  Both require that we set
expectations around the scope of the guidance, both in time and the
servers that are affected.

Personally, I don't see a good incentive for a client implementation
to add this feature.  However, I can understand why a client might
choose to implement COME_BACK, even though the incentives aren't
exactly clear there either.  Once you have COME_BACK, this might be a
less onerous addition to a client implementation.  Maybe.  I'd like to
hear from people building clients as to how hard they believe that
this would be to implement.
Received on Tuesday, 18 June 2013 22:33:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC