Re: Implementation Notes on Server Push

William Chan (陈智昌) <> Wed, 15 May 2013 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13B9311E80CC for <>; Wed, 15 May 2013 13:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.843
X-Spam-Status: No, score=-8.843 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i4SSlOdYnPQl for <>; Wed, 15 May 2013 13:49:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EB4F21F907E for <>; Wed, 15 May 2013 13:49:19 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1Ucicx-0000IK-2k for; Wed, 15 May 2013 20:48:47 +0000
Resent-Date: Wed, 15 May 2013 20:48:47 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1Ucicl-0000GG-AA for; Wed, 15 May 2013 20:48:35 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1Ucicg-0003vG-60 for; Wed, 15 May 2013 20:48:35 +0000
Received: by with SMTP id ii15so1224163qab.4 for <>; Wed, 15 May 2013 13:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KEUDe9CKd86PL0LkzQ07+OVdHGz9wat0EFpVG2K23Xc=; b=HVjpZi0t0z+gqgzpyJUsY86+gDtFhJJvcPqDs2qBi4lyfxVXsdVL36LkAbmEfsQDYE rC9WCYDCmdtG1T+AT724XZDwoJCyHQocBIYLs0N0Kfbv7vnScTBoFBDeU8YLT7mV2Xur L9zw1WX6NGACb9BUi5SUj/Ef0FKzFknC6RvwJwDtJlxIMFmLlYu6AOIFMc2THG1iOQXu Ys2CgnjzJjQZiSZ6Ow7rVE0dFKRTmkmFsMNIl53st9KKCmBlepZmblEy17EGSIimTWB2 b3PzMBrOKgq1F7vgTrf0CBm60boQkMF6cVOHOSp4GBtLMGOUnApgqcoobLVRias/RBg2 V4gA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KEUDe9CKd86PL0LkzQ07+OVdHGz9wat0EFpVG2K23Xc=; b=kS8QrgJx1QY7ArGc2wv/mQBtHuKO36QOrDVpLw0AuiotDz3ejhx5LobdCAFhgNc5Lo G6aayID/dUXKe1isS5HD8UBQBW/OkRs/5Ye7Ylij9I8oHhTMBY3dU5x8N5z4p9dJEZfv rp3za2v8VclbUEN9Z1cR8gTr7ttzK636d5feQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=KEUDe9CKd86PL0LkzQ07+OVdHGz9wat0EFpVG2K23Xc=; b=XXUtWKQ3V3EW+dyrsooJ0Hfd4PYACw448cFGusxLKqjSeV7dTFv+4saBicJzmyuper PjaYikINWLh1qM2VAHYL+p8PnZFvlfQQrCH73Ap3dIe3EbUhvMqELEBgtZ6lk2Z/+3qv 9+Ut0RSk2rSYW9FVfDyorLGCMynAVeA6l831efXmgs14KxbDlNr296aFn/7FvwXn/+Gw YBovgulqN1DpTJ9kC0fd27WQgTSlq58J3p2BHfDdd3zg3Pfn7IYo6YxC/Y5JUlX8m8fL BVjVFeaK+El2TxzApYaSW2UsxIHHrFrmW2/mS5xz9/7XpOf3ySmCcBHD1S1xcapthz/Y Taxg==
MIME-Version: 1.0
X-Received: by with SMTP id g5mr3101711qcv.131.1368650884380; Wed, 15 May 2013 13:48:04 -0700 (PDT)
Received: by with HTTP; Wed, 15 May 2013 13:48:04 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 15 May 2013 17:48:04 -0300
X-Google-Sender-Auth: ipNAA8FWlbuI8hY0-fZK5SXiks0
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=90e6ba10aeadc94c4704dcc7dd1a
X-Gm-Message-State: ALoCoQlrWUjytjDR/QzdbxRy8XhENXFElj+rmWvn+eL7e6tktsWFaTRxIXMB6jB/1tJaSvUpIreLTAFEqn4IjS5wef3aGYvc40VoKnCpeKhqPewqHvBfY84ZcDGim/iZ5A0WnWDVna6dHgJsOrvMuuYmB9qj6lgF4FNyTv+WTtw375ZKkvnvIzGF6g5ifVGCKiIMTcT2+3p+
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=-2.418, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.629, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1Ucicg-0003vG-60 44b4b48e18ca4fd6aa082131d5fd4702
Subject: Re: Implementation Notes on Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/18007
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, May 14, 2013 at 4:14 PM, Patrick McManus <>wrote;wrote:

> I'm wrapping up a Firefox implementation of spdy/3 server push and wanted
> to provide some ietf level feedback because that mechanism is largely
> intact in the current http2 work in progress draft.
>    - 304's seem to be a common cause of wasted pushed streams. I would
>    see servers respond with a 304 for index.html and still push 200 responses
>    for a.css and b.js when in a non-push world that would have been either 1
>    or 3 304's. Maybe we should have a rule that you can only push to an
>    assoc-stream of 2xx ?
>    - There is language in the spec that if the client resets a stream
>    that it implicitly resets any associated streams too. That was complicated
>    to implement and pretty much broke my stream state model internally - while
>    researching it it appears that mod_spdy and chrome don't implement it at
>    all. The spec has an editorial note about removing that feature and I favor
>    that removal.
>    - I found flow control for pushed streams immensely helpful. It lets
>    the client bound how much data can be pushed before there is a local GET
>    matched up with that. Relatedly, I changed my default SETTINGS window size
>    from a ~infinite value to be a smaller push-apropos value and then
>    pipelined a window update with each odd SYN_STREAM to make pulled streams
>    ~infinite again while preserving the smaller limit for push and this worked
>    fine with all existing servers to my pleasant surprise. That seems to mean
>    at least the spdy/3 windowing mechanism is simple enough for people to get
>    right.
Given the amount of discussion here, I figured I should chime in on this
point and ask a question. Are you doing this for memory bounding purposes?
Or is this for prioritization purposes?

As I've said before, I think we should not attempt to leverage flow control
mechanisms for prioritization. The client should advise the server as best
as possible the appropriate prioritization, and then trust the server to
serve responses (including pushed streams) in the best ordering.

>    - As with other parts of the spec, I was faced in some implementations
>    with some very large data frames (90+KB) from servers when testing. Such
>    frames are impervious to CANCEL or any mechanism we might use to change
>    priorities driven by the client :(..  HTTP2 is doing the right thing by
>    creating a smallish max frame size.
> Obviously this is implementation experience with testing and isn't real
> operational experience yet.. that will come.
> -P