- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 18 Jun 2013 15:32:42 -0700
- 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