Re: Working Group Last Call for Using Early Data in HTTP

PR here:

https://github.com/httpwg/http-extensions/pull/440

On Wed, Nov 29, 2017 at 6:03 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Benjamin,
>
> On Tue, Nov 28, 2017 at 11:54:26AM -0600, Benjamin Kaduk wrote:
>> In section 3, we may want to note the different buffering requirements
>> between case 2 (just requests) and case 3 (requests and pending
>> responses, for the HTTP/1.1 case ... which can only occur if pipelining
>> is in use?).
>
> In fact I'm wondering if we really need to speak about buffering at all
> there. From this point it becomes very specific to the implementation.
> I'd rather replace "This may require buffering the responses to preserve
> ordering in HTTP/1.1" with something like :
>
>    Note that trying to determine upfront which requests are safe and
>    which ones are not in a set of pipelined HTTP/1.1 requests while
>    waiting for a handshake can be quite challenging and is therefore
>    not recommended, since ordering will need to be preserved in
>    responses anyway. An safer solution consists in only processing the
>    first safe requests and waiting for the handshake before processing
>    unsafe ones.

That seems like too much to me.  How about we remove the offending
sentence.  The need to buffer is implicit.  Also, there is some
question about order preservation with pipelining, so maybe we can
instead agree that pipelining isn't important enough to waste text on.

>> In section 4,
>>
>>    If HTTP/2 is selected after
>>    early data is rejected, a client sends another connection preface
>>
>> Nitpicking, but "another" is only true when HTTP/2 was used
>> optimistically in the early data.
>
> Definitely. Also, I think we're making a special case of the connection
> preface but in fact we could rather indicate "the client must send (or
> resend) all the HTTP/2 traffic starting from the connection preface as
> if the connection was new".

Again, removing the sentence seems to be sufficient.  We already say
"If the server rejects early data at the TLS layer, a client MUST
start sending again as though the connection was new. "

>> In section 5,
>>
>>    o  The "Early-Data" header field is included in requests that might
>>       have been forwarded by an intermediary prior to the TLS handshake
>>       completing.
>>
>> For cases involving an intermediary, there is not necessarily a single unique
>> TLS handshake; we should disambiguate.  (And I think we really need all TLS
>> handshake(s) between client and current intermediary, inclusive, to have
>> completed.)

This was addressed in https://github.com/httpwg/http-extensions/pull/429

The extra detail Ben proposes is not really necessary for what is a
summary and is included elsewhere.

>> In section 6.1, a nit that we have both "isn't certain" and "is uncertain" in
>> different sentences, and probably don't need such a distinction.
[..]
> I don't think so, the former indicates what to do with what was received,
> and the later suggests whether or not to use early data to reach the next
> hop. However I'd suggest "SHOULD not send the request in early data to the
> server".

I've proposed a reword in the PR.  The first sentence now talks about
requests.  The second is now a new paragraph that talks about the
relative merits of enabling early data if origin servers don't support
the header field.

BTW, it's not MUST disable because there are - at least in theory -
minor performance benefits to a gateway supporting 0-RTT even if an
origin server does not understand the feature.

Received on Wednesday, 29 November 2017 09:21:22 UTC