Re: Server Push and Content Negotiation

Mark Nottingham <> Wed, 07 September 2016 03:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D432127078 for <>; Tue, 6 Sep 2016 20:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.429
X-Spam-Status: No, score=-8.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tf4M8HMk0A5M for <>; Tue, 6 Sep 2016 20:51:56 -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 7D59012B08D for <>; Tue, 6 Sep 2016 20:51:56 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bhTpu-0000sW-Q5 for; Wed, 07 Sep 2016 03:47:42 +0000
Resent-Date: Wed, 07 Sep 2016 03:47:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bhTpo-0000r9-5g for; Wed, 07 Sep 2016 03:47:36 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bhTpl-0006wJ-U9 for; Wed, 07 Sep 2016 03:47:35 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id ABD6622E253; Tue, 6 Sep 2016 23:47:09 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 7 Sep 2016 13:47:07 +1000
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Patrick McManus <>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.351, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bhTpl-0006wJ-U9 ee95e6c58ee5c2283f2b2d3d9e445c70
Subject: Re: Server Push and Content Negotiation
Archived-At: <>
X-Mailing-List: <> archive/latest/32379
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 25 Aug 2016, at 12:36 AM, Patrick McManus <> wrote:
> [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 brotli?

The server has to make an informed guess about client support. One way would be to look at the initiating request headers; as I think a few people have said, they're rarely variant. Worst case, try a push and look for an error code saying it wasn't a good encoding (see other thread).

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

Mark Nottingham