Re: Feedback on Fallback

Thanks, Mike.

Just for reference, the interim discussion is minuted here:
  https://github.com/httpwg/wg-materials/blob/gh-pages/interim-14-06/minutes.md#tls-renegotiation

... and to make sure we track it,I'm reopening the issue:
  https://github.com/http2/http2-spec/issues/496

Regards,

  
On 15 Aug 2014, at 8:56 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

> Going into WGLC, we committed to implementations and taking changes based solely on implementation experience and real-world data.  Based on our experience so far, Microsoft’s first piece of WGLC feedback is to replace Mark’s Over-Version draft with an error code in the spec.  Our reasoning follows.
>  
> As we continue to work on HTTP/2, one item that has come up repeatedly is the need to force clients back to HTTP/1.1 for various reasons.  We’ve all pushed hard against bulk-relegating any class of HTTP usage into the “They should just use 1.1” bucket, but it’s becoming clear that there will occasionally be situations where a server needs a client to fall back.
>  
> Some apps we support depend on the ability to emit raw HTTP protocol text.  Others require client certs as a matter of local law and we don’t have a way to retrieve the client cert without renegotiation.  Others are strictly situational, features that require adaptation work we haven’t gotten to yet.
>  
> These assorted situations motivated the Over-Version draft which Mark published after the NYC Interim.  505 was already defined as meaning the server was unable/unwilling to use the current HTTP version to serve the request the client made; Mark’s draft added semantics to inform a client what version would be acceptable, if any, so that an intelligent client could transparently retry over the correct HTTP version (be it 1.1 or 3.5).
>  
> We’ve found a couple limitations with this approach:
> ·         As Jeff pointed out in NYC, returning a 5XX looks bad in server logs.  This isn’t actually a server “failure” per se, we just used it because the status code already exists in the 5XX range.  Not a technical issue, but definitely an operational one.  (Jeff noted in NYC that there are other 5XX status codes that Twitter non-standardly recasts in other ranges for this reason.  New 4XX and 3XX codes were proposed as part of this discussion, demonstrating that the concept doesn’t bucket well as a status code.)
> ·         Once the HEADERS frame with :status is sent, we’re locked in to that response.  You can’t subsequently change the :status to 505.  Some of these situations can occur when the response is partially-generated, which leaves us stuck unless we buffer all responses until they’re complete (unacceptable for perf).
> ·         Because Over-Version is optional, clients are not guaranteed to support it.  An unsupporting client will just retry the same request over HTTP/2 again and never be able to obtain an actual response from the server.  Including a response body with the 505 telling clients to turn off HTTP/2 in their browser is definitely not a direction we want to go in these situations, and I don’t expect clients to have a “turn off HTTP/2 for this request only” button.
>  
> On the other hand, a new error code doesn’t suffer from these issues.  A RST_STREAM can be sent at any point and doesn’t necessarily confuse existing heuristics.  A GOAWAY with the same error code provides a clean way for the server to transition a client to HTTP/1.1 entirely, if necessary.  If it’s in the base spec, we can be assured that any client will be able to understand it and respond appropriately.
>  
> Thus, we think an “HTTP/1.1 Required” error code will be a better option than proceeding with the Over-Version draft.

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 15 August 2014 02:05:55 UTC