RE: #496: Feedback on Fallback

I'm also in favor of fixing this.

-keith

-----Original Message-----
From: jason.greene@redhat.com [mailto:jason.greene@redhat.com]
Sent: Tuesday,07 October 2014 19:42
To: Mike Bishop
Cc: Eliot Lear; Mark Nottingham; HTTP Working Group
Subject: 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


This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Wednesday, 8 October 2014 08:52:55 UTC