Re: Implementation Notes on Server Push

Roberto Peon <grmocg@gmail.com> Tue, 14 May 2013 19:51 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5021F8532 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 12:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL0KVy8mvM3d for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 May 2013 12:50:57 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC521F845D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 May 2013 12:50:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UcLEw-0007ow-RF for ietf-http-wg-dist@listhub.w3.org; Tue, 14 May 2013 19:50:26 +0000
Resent-Date: Tue, 14 May 2013 19:50:26 +0000
Resent-Message-Id: <E1UcLEw-0007ow-RF@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UcLEa-0004g9-9L for ietf-http-wg@listhub.w3.org; Tue, 14 May 2013 19:50:05 +0000
Received: from mail-oa0-f41.google.com ([209.85.219.41]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UcKzc-0006MD-Un for ietf-http-wg@w3.org; Tue, 14 May 2013 19:34:42 +0000
Received: by mail-oa0-f41.google.com with SMTP id n9so1147980oag.28 for <ietf-http-wg@w3.org>; Tue, 14 May 2013 12:34:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.58.99 with SMTP id p3mr17100073oeq.23.1368559556904; Tue, 14 May 2013 12:25:56 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Tue, 14 May 2013 12:25:56 -0700 (PDT)
In-Reply-To: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
References: <CAOdDvNqXhG7+xbvBwctQCR4tZePKByw75SR5oBamXTymZa7myA@mail.gmail.com>
Date: Tue, 14 May 2013 12:25:56 -0700
Message-ID: <CAP+FsNexObA2ub0gm-dcj8dMR_xF2SASSmJAxrvfNU-mgXLf_w@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e013d07583e64e304dcb29aa6
Received-SPF: pass client-ip=209.85.219.41; envelope-from=grmocg@gmail.com; helo=mail-oa0-f41.google.com
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: maggie.w3.org 1UcKzc-0006MD-Un a5ff13e12d890bda0e8504bcfe27c04b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Implementation Notes on Server Push
Archived-At: <http://www.w3.org/mid/CAP+FsNexObA2ub0gm-dcj8dMR_xF2SASSmJAxrvfNU-mgXLf_w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17994
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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.
-=R


On Tue, May 14, 2013 at 12:14 PM, Patrick McManus <pmcmanus@mozilla.com>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
>