Re: Server Push and Content Negotiation

Patrick McManus <mcmanus@ducksong.com> Wed, 24 August 2016 14:46 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 640A012DE75 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 07:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level:
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sendgrid.me
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SzhYbX4EK2B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Aug 2016 07:46:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8116D12DE30 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Aug 2016 07:41:55 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bcZIt-0002uH-Fs for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Aug 2016 14:37:19 +0000
Resent-Date: Wed, 24 Aug 2016 14:37:19 +0000
Resent-Message-Id: <E1bcZIt-0002uH-Fs@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bcZIi-0002UI-Un for ietf-http-wg@listhub.w3.org; Wed, 24 Aug 2016 14:37:08 +0000
Received: from o1.30e.fshared.sendgrid.net ([167.89.55.41]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net>) id 1bcZIg-0006xY-J5 for ietf-http-wg@w3.org; Wed, 24 Aug 2016 14:37:08 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=mime-version:in-reply-to:references:from:subject:to:cc:content-type; s=smtpapi; bh=+watmAUIzfV7cs/bRhN551+toGQ=; b=RrBdALQCU1+UPNnjqg 2gDNjtqSQAO5wAmkQBnyUkiF3B2tdk9xCEpzmxQbIke5DzIZ0xiQAp6mJaF7qQam qchdQn6TBmJYaQKfwQRb2/kZBnPcSqulJU+sz+L3G/u0BSifYov5gIfainPXXE3d qx7L3jIMwS+xcWKts2Dn1AcZ4=
Received: by filter0601p1mdw1.sendgrid.net with SMTP id filter0601p1mdw1.30702.57BDB0F448 2016-08-24 14:36:36.896177815 +0000 UTC
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id z4MKolGDQImoxUKa6ioW3w for <ietf-http-wg@w3.org>; Wed, 24 Aug 2016 14:36:36.805 +0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id f6so36770417ith.0 for <ietf-http-wg@w3.org>; Wed, 24 Aug 2016 07:36:36 -0700 (PDT)
X-Gm-Message-State: AE9vXwObXB8wkSjh4o6c4/gVMpT5s8N7JdKBQIaNdqsui3TsmH5bEjEv+54gZLX4Vvj3oizXIkMiZ71h9f8Xxg==
X-Received: by 10.107.24.129 with SMTP id 123mr4581624ioy.188.1472049396421; Wed, 24 Aug 2016 07:36:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.148.50 with HTTP; Wed, 24 Aug 2016 07:36:35 -0700 (PDT)
In-Reply-To: <F638033C-C1E0-447D-915E-A0B947629EA7@mnot.net>
References: <F638033C-C1E0-447D-915E-A0B947629EA7@mnot.net>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 24 Aug 2016 10:36:35 -0400
X-Gmail-Original-Message-ID: <CAOdDvNomUHFGGDXu2HtGaY4iNOBr=oHATnMfcLMtR5jz4CW2RA@mail.gmail.com>
Message-ID: <CAOdDvNomUHFGGDXu2HtGaY4iNOBr=oHATnMfcLMtR5jz4CW2RA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c05fd065da241053ad235e3
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh41wNqs0ZrOzBw6/7MsGuxODY5ZZNAucjb03T DRSuHldpbaFKrRRQgJLeg6g8jnF+JOPEPOMCAZsJeEkUpxI1tAVst5RjdFKlogn1s9VZl2yfaQ2i2z FbMXExisG8FSiHZ6ZTZmA1Ey0V5pZD1ro30VaS6irT3cOInGdbsRT2nCohlUMPioWSJwO1KXdKWtN0 M=
Received-SPF: pass client-ip=167.89.55.41; envelope-from=bounces+1568871-208f-ietf-http-wg=w3.org@sendgrid.net; helo=o1.30e.fshared.sendgrid.net
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.791, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.236, SPF_PASS=-0.001, URIBL_GREY=0.424, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bcZIg-0006xY-J5 665dca9dd69e447e31a520bcc6763b18
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Server Push and Content Negotiation
Archived-At: <http://www.w3.org/mid/CAOdDvNomUHFGGDXu2HtGaY4iNOBr=oHATnMfcLMtR5jz4CW2RA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32350
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>

[implementer hat]

On Wed, Aug 24, 2016 at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:

> What do people think -- is this worth specifying? How are implementations
> currently doing this?


push is one way - negotiation doesn't make any sense and yet the
alternative to negotiation is some kind of sniffing. sniffing is awful and
is even harder here where you don't have a request to sniff - you'd have to
do some whole connection guess.

how would you push some feature that relies on conneg today - like webp or
brotli?

I think as a client realistically you have to wait for the response headers
and check them out to see if its an acceptable push. Whatever is in the
request headers isn't really enough for that - which is a bit of a change
from what I currently do.

fwiw, this was one of the reasons gzip was a mandatory-to-implement CE in
spdy and probably should have stayed. It meant you could reliably push it.
Doing so now is really just an assumption that gzip is a defacto standard.

Or this all might be another argument about the excessive complexity of
push - maybe that should be a document :)