Re: Implementation Notes on Server Push

Roberto Peon <> Tue, 14 May 2013 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BE5021F8532 for <>; Tue, 14 May 2013 12:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qL0KVy8mvM3d for <>; Tue, 14 May 2013 12:50:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0CC521F845D for <>; Tue, 14 May 2013 12:50:56 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UcLEw-0007ow-RF for; Tue, 14 May 2013 19:50:26 +0000
Resent-Date: Tue, 14 May 2013 19:50:26 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UcLEa-0004g9-9L for; Tue, 14 May 2013 19:50:05 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UcKzc-0006MD-Un for; Tue, 14 May 2013 19:34:42 +0000
Received: by with SMTP id n9so1147980oag.28 for <>; Tue, 14 May 2013 12:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t5zHCI3COMZ5S9uIvKjEAH2J6TrOMEJdSVi4qmAoWIQ=; b=qJpX1N3tn601i3kaJpD7SU4lFVh4GHnNNfNuSUHylcN/8rPoUuXHXwUAXdakBKPH67 ME/4hfniTZAcssg8eeMm95v22M3+1Do17kIPCLKBiogahfs/ymvKYITlCtWlE+hvwDhK BaAV7OSwqmdkX6cQJaoe05uxr4/xGdgxKx6OXwy1wN7EntDnnVQyi9P1XZwgT9qJRWqF lzHdtcPmwVwhnDaWE4QUPnHYSLdw3DACH6ZDUHg6SQuHbYlLv8ptz0pVsmxZobp90e03 uOEnc57Zfj4FLWFac/ySPg3jDyNLw2h2/mxiKRGPL/fAhoxhAqBznBv/cemZM1oWlK1+ GYLQ==
MIME-Version: 1.0
X-Received: by with SMTP id p3mr17100073oeq.23.1368559556904; Tue, 14 May 2013 12:25:56 -0700 (PDT)
Received: by with HTTP; Tue, 14 May 2013 12:25:56 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 14 May 2013 12:25:56 -0700
Message-ID: <>
From: Roberto Peon <>
To: Patrick McManus <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=089e013d07583e64e304dcb29aa6
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.678, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UcKzc-0006MD-Un a5ff13e12d890bda0e8504bcfe27c04b
Subject: Re: Implementation Notes on Server Push
Archived-At: <>
X-Mailing-List: <> archive/latest/17994
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I don't favor any MUST in the spec about requiring 304s in the first
scenario, but informing people that this is silly would be good :)
Stupid servers will be suboptimal, yes, but if a server has a strong reason
to believe that the next thing the client will be requesting is something
which will be stale, pushing the resource is completely reasonable.

On Tue, May 14, 2013 at 12: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.
>    - 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