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

On 11/29/2017 03:20 AM, Martin Thomson wrote:
> PR here:
>
> https://github.com/httpwg/http-extensions/pull/440

I read it; thanks.

> 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.

SGTM

>>> 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. "

This one I'm less enthusiastic about reviewing.  In the alternate
universe where I had written "this" document, I planned to explicitly
mention the connection preface for this case.  That said, your proposal
is not wrong, it just seems like a question of emphasis and how much we
want to rely on something being "obvious" for all readers, and whether
basic interop testing at implementation time will force the correct
interpretation.

>>> 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.

Okay.

>>> 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.

I like the reword in the PR.

Thanks!

-Ben

> 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 14:53:36 UTC