Re: #496: Feedback on Fallback

I’m in favor of fixing this, for whatever that’s worth.

On Oct 7, 2014, at 12:22 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

> Rob pointed out the higher-layer question here, which I didn't address.  It's really a discussion of whether HTTP/2 can be on by default or not, because we have to deal with existing apps.  If it requires explicit opt-in from the server app, which confirm it's using only h2-ready APIs, then we can't turn HTTP/2 on until either all apps are marked as h2-ready (essentially never) or we've shimmed our entire API set to be transparently h2-ready (not quick).  That's going to apply to any general-purpose platform, and it's going to slow adoption.
> 
> Having a fallback mechanism means we can make *most* of the API surface h2-ready and turn it on by default, because there's a graceful way to handle when there's a gap.  What those gaps are will change (shrink) over time, but a graceful fallback means earlier and broader deployment.
> 
> -----Original Message-----
> From: Mike Bishop [mailto:Michael.Bishop@microsoft.com] 
> Sent: Tuesday, October 7, 2014 7:56 AM
> To: Eliot Lear; Mark Nottingham; HTTP Working Group
> Subject: RE: #496: Feedback on Fallback
> 
> That's certainly a possible direction we could take the API, but we'd still need a way to communicate that to the client over the wire.  This proposal would allow us to communicate if the server developer wants to push them down to 1.1.
> 
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Monday, October 6, 2014 11:56 PM
> To: Mark Nottingham; HTTP Working Group
> Cc: Mike Bishop
> Subject: Re: #496: Feedback on Fallback
> 
> Just a question:
> 
> Why not offer the developer the choice to go to 1.1, especially if using raw interfaces?  You could even update your API so that the call requires an HTTP version #.
> 
> Eliot
> 
> 
> On 10/7/14, 8:30 AM, Mark Nottingham wrote:
>> There hasn't been much feedback on this. 
>> 
>> Any more comments on Mike's proposal (specifically, <https://github.com/MikeBishop/http2-spec/commit/cebb0385f188ddcaf75ec3a7811b836c770e7fdb>)?
>> 
>> Regards,
>> 
>> 
>> On 23 Sep 2014, at 5:24 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> 
>>> Just to recap this suggestion, we’re not suggesting that any class of traffic should be bulk-relegated to HTTP/1.1 – we’re suggesting the addition of a widely-recognized error code to smooth transitions.  Burning a round-trip isn’t ideal, but it’s a mitigation strategy for limitations on either the client or the server.  In particular, a later thread (http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1894.html) raised the use of such an error code in a GOAWAY as a good hard-coded response to a client that attempts to connect with prior knowledge and gets it wrong.  A server that’s aware of HTTP/2 but doesn’t support it can generate an appropriate GOAWAY and close the connection.
>>> 
>>> I submitted a pull request adding the error code at https://github.com/http2/http2-spec/pull/599 -- are there any comments on this change or is this editor-ready?
>>> 
>>> From: Mike Bishop
>>> Sent: Thursday, August 14, 2014 3:56 PM
>>> To: HTTP Working Group
>>> Subject: Feedback on Fallback
>>> 
>>> 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/
>> 
>> 
>> 
>> 
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Tuesday, 7 October 2014 17:42:23 UTC