Re: Server Push and Content Negotiation

Patrick McManus <> Wed, 24 August 2016 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 640A012DE75 for <>; Wed, 24 Aug 2016 07:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.448
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4SzhYbX4EK2B for <>; Wed, 24 Aug 2016 07:46:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8116D12DE30 for <>; Wed, 24 Aug 2016 07:41:55 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcZIt-0002uH-Fs for; Wed, 24 Aug 2016 14:37:19 +0000
Resent-Date: Wed, 24 Aug 2016 14:37:19 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcZIi-0002UI-Un for; Wed, 24 Aug 2016 14:37:08 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1bcZIg-0006xY-J5 for; Wed, 24 Aug 2016 14:37:08 +0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; 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 with SMTP id filter0601p1mdw1.30702.57BDB0F448 2016-08-24 14:36:36.896177815 +0000 UTC
Received: from ( []) by (SG) with ESMTP id z4MKolGDQImoxUKa6ioW3w for <>; Wed, 24 Aug 2016 14:36:36.805 +0000 (UTC)
Received: by with SMTP id f6so36770417ith.0 for <>; Wed, 24 Aug 2016 07:36:36 -0700 (PDT)
X-Gm-Message-State: AE9vXwObXB8wkSjh4o6c4/gVMpT5s8N7JdKBQIaNdqsui3TsmH5bEjEv+54gZLX4Vvj3oizXIkMiZ71h9f8Xxg==
X-Received: by with SMTP id 123mr4581624ioy.188.1472049396421; Wed, 24 Aug 2016 07:36:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Aug 2016 07:36:35 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Wed, 24 Aug 2016 10:36:35 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Mark Nottingham <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary=94eb2c05fd065da241053ad235e3
X-SG-EID: YLWet4rakcOTMHWvPPwWbcsiUJbN1FCn0PHYd/Uujh41wNqs0ZrOzBw6/7MsGuxODY5ZZNAucjb03T DRSuHldpbaFKrRRQgJLeg6g8jnF+JOPEPOMCAZsJeEkUpxI1tAVst5RjdFKlogn1s9VZl2yfaQ2i2z FbMXExisG8FSiHZ6ZTZmA1Ey0V5pZD1ro30VaS6irT3cOInGdbsRT2nCohlUMPioWSJwO1KXdKWtN0 M=
Received-SPF: pass client-ip=;;
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: 1bcZIg-0006xY-J5 665dca9dd69e447e31a520bcc6763b18
Subject: Re: Server Push and Content Negotiation
Archived-At: <>
X-Mailing-List: <> archive/latest/32350
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

[implementer hat]

On Wed, Aug 24, 2016 at 12:26 AM, Mark Nottingham <> 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

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 :)