Date: Thu, 10 Aug 2017 01:20:14 +0000 (UTC)
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab3784afdc30fa1e6baa0bfdf56d4a8383344b715a92cf0000000115a376ce92a169ce0eda8cd0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/718/321423883@github.com>
In-Reply-To: <quicwg/base-drafts/issues/718@github.com>
References: <quicwg/base-drafts/issues/718@github.com>
Subject: Re: [quicwg/base-drafts] Retain use of SETTINGS_ENABLE_PUSH (#718)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_598bb4ce48ca_5c173fc1afaf5c341478a3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/yPmgWf6lUqf9iNcXYL-GLh9auxA>

----==_mimepart_598bb4ce48ca_5c173fc1afaf5c341478a3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

It's true, this changes the default stance of a server.  In the event that a MAX_PUSH_ID (#711) isn't received, the server simply can't use server push.  If the client really does support push, this error is going to be rare (the packet containing the MAX_PUSH_ID is lost or delayed and the request is still in a position to be understood and responded to).  The only consequence is lost opportunity, the protocol still functions.

We have a similar problem with SETTINGS.  SETTINGS establishes the header table size, so there is a lost (compression) opportunity if it is lost or reordered.

Either way, I think that we'll find out just how much of a problem this is when we get some experience with this.  It might be premature to decide right now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/718#issuecomment-321423883
----==_mimepart_598bb4ce48ca_5c173fc1afaf5c341478a3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>It's true, this changes the default stance of a server.  In the event th=
at a MAX_PUSH_ID (<a href=3D"https://github.com/quicwg/base-drafts/pull/711=
" class=3D"issue-link js-issue-link" data-url=3D"https://github.com/quicwg/=
base-drafts/issues/711" data-id=3D"248641040" data-error-text=3D"Failed to =
load issue title" data-permission-text=3D"Issue title is private">#711</a>)=
 isn't received, the server simply can't use server push.  If the client re=
ally does support push, this error is going to be rare (the packet containi=
ng the MAX_PUSH_ID is lost or delayed and the request is still in a positio=
n to be understood and responded to).  The only consequence is lost opportu=
nity, the protocol still functions.</p>
<p>We have a similar problem with SETTINGS.  SETTINGS establishes the heade=
r table size, so there is a lost (compression) opportunity if it is lost or=
 reordered.</p>
<p>Either way, I think that we'll find out just how much of a problem this =
is when we get some experience with this.  It might be premature to decide =
right now.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/issues/718#issuecomment-321423883">view it on GitHub</a>, or <a hr=
ef=3D"https://github.com/notifications/unsubscribe-auth/AWbkqyGM3Kwuo9ytU_I=
oTYUSCdjnSEyhks5sWlrOgaJpZM4Oy0ef">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkqwPv5jjZNSPECK_wL=
_V1STYfatOqks5sWlrOgaJpZM4Oy0ef.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/issu=
es/718#issuecomment-321423883"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@martinthomson in #718: It's tru=
e, this changes the default stance of a server.  In the event that a MAX_PU=
SH_ID (#711) isn't received, the server simply can't use server push.  If t=
he client really does support push, this error is going to be rare (the pac=
ket containing the MAX_PUSH_ID is lost or delayed and the request is still =
in a position to be understood and responded to).  The only consequence is =
lost opportunity, the protocol still functions.\r\n\r\nWe have a similar pr=
oblem with SETTINGS.  SETTINGS establishes the header table size, so there =
is a lost (compression) opportunity if it is lost or reordered.\r\n\r\nEith=
er way, I think that we'll find out just how much of a problem this is when=
 we get some experience with this.  It might be premature to decide right n=
ow."}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-=
drafts/issues/718#issuecomment-321423883"}}}</script>=

----==_mimepart_598bb4ce48ca_5c173fc1afaf5c341478a3--