Re: Server Push and Content Negotiation

Tom Bergan <> Wed, 24 August 2016 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 899F012D5CA for <>; Wed, 24 Aug 2016 10:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.568
X-Spam-Status: No, score=-7.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JZVfY2imFoZW for <>; Wed, 24 Aug 2016 10:17:45 -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 62FAD12D5B9 for <>; Wed, 24 Aug 2016 10:17:45 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bcbjO-0000pT-RF for; Wed, 24 Aug 2016 17:12:50 +0000
Resent-Date: Wed, 24 Aug 2016 17:12:50 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcbjI-0000od-FP for; Wed, 24 Aug 2016 17:12:44 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bcbjG-0000sJ-RK for; Wed, 24 Aug 2016 17:12:44 +0000
Received: by with SMTP id n128so45691117ith.1 for <>; Wed, 24 Aug 2016 10:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4mgNCCUq+MFTsFFNdsE5XRZynshWg+jNYLsYqIB5fqI=; b=lh9K8cho3m4Ym6lVQU4YTcyK8w6h2oYiTu2T8Y7pL9Tnwhxh08oXzFRcQr1aqhn1vv 2aougYpJsvt1NKgVSekcuVsi5WG1+Z4YyMILOJqPKexBm0MvwpzjjiuOmbP8+yBwp9LX FLKlyGGQWmrBzQxd+Ypwg0qLg6LTCHlOaBc0E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4mgNCCUq+MFTsFFNdsE5XRZynshWg+jNYLsYqIB5fqI=; b=kmWXoFcqquZWS2Vesm0JBvy5G96FXtoZzM98/NEygEFTXFHynUCTG3s2gJvzdvWHOv TddsvwQnXWUgZzWK1pmIsWDEsAb20G/aTfewGBvLU/TX7rzhC6uN7wT9x9oXqGputjVW +XnBz35QCyLpcQfc6r4+SoyKoMooKzfGEhoxynWtigCglr/TNut5M5AxewQRLlmVLEMl qjhSpRut/FcFOyV5rPWf+eNeaCoFKwQQ8r4NQQuS6SGlhryXAnHINZ0J+wHR++34qtx4 zR3J6GZIsqmSfBEpdtykYg7Ya6777cOYZbVjclke6S1KKU5wNEEgyl76+LhZbbUjhXQd PavQ==
X-Gm-Message-State: AEkoouu3IDJGfbnOAWggQiY2rmgmgzInSs2MQBiy0ZrkfFSdH2kLNwnYEzztsWRytCEJPGED
X-Received: by with SMTP id a3mr5993954iog.4.1472058736538; Wed, 24 Aug 2016 10:12:16 -0700 (PDT)
Received: from ( []) by with ESMTPSA id n190sm3744043ion.42.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Aug 2016 10:12:16 -0700 (PDT)
Received: by with SMTP id n128so45689846ith.1 for <>; Wed, 24 Aug 2016 10:12:15 -0700 (PDT)
X-Received: by with SMTP id m5mr90841itd.20.1472058735160; Wed, 24 Aug 2016 10:12:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Aug 2016 10:12:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Tom Bergan <>
Date: Wed, 24 Aug 2016 10:12:14 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Patrick McManus <>
Cc: Mark Nottingham <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary=94eb2c08a4feffc4be053ad46163
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-0.380, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bcbjG-0000sJ-RK 2b3b476f528021e24e3a2c63cbd5b3c7
Subject: Re: Server Push and Content Negotiation
Archived-At: <>
X-Mailing-List: <> archive/latest/32354
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

[sorry for the dup post, used the wrong email]

On Wed, Aug 24, 2016 at 7:36 AM, Patrick McManus <>
> Or this all might be another argument about the excessive complexity of
> push - maybe that should be a document :)


On Tue, Aug 23, 2016 at 9:26 PM, Mark Nottingham <> wrote:

> The interaction of Content Negotiation and Server Push isn't really
> specified. Depending on how it's implemented, it could be quite tricky,
> because it seemingly requires the server to guess what the client would
> have sent, in order to negotiate upon it.

This sounds right to me. Though, if the server and client are well-behaved,
the worst-case is wasted bandwidth, not an incorrect response:
- If the server pushes response with a non-empty Vary (or Key) field, it
should make a guess for all headers mentioned in Vary (or Key) and include
those guesses in the PUSH_PROMISE
- The client should is match pushed (request, response) pairs to client
requests using the Vary (or Key) field in the usual way

Additionally, the server needs to know what the base capabilities and
> preferences of the client are, to allow it to select the appropriate
> responses to push. To aid this, servers SHOULD create a PUSH_PROMISE's
> request by copying the values of the request header fields mentioned in the
> `Vary` response header field from the request that is identified by the
> `PUSH_PROMISE` frame's Stream ID.

For fields like Accept-Encoding and User-Agent, that's probably sufficient.
But in general, it's not quite that simple -- e.g., what if the response
has "Vary: Cookie", which can in theory change between requests? You make a
similar observation when talking about how Client Hints might change
between requests. Also see the discussion for "Rule #4" in this doc:

I'd be tempted to go even further and say that PUSH_PROMISE headers SHOULD
> NOT contain `DNT`, `User-Agent`, `Cookie` or similar headers UNLESS they
> were specified in Vary.

I'd agree with that. I would say that PUSH_PROMISE only needs to contain
header fields that describe the cache key of the response (which includes
:method, :scheme, :path, :authority, and any header field referenced by
Vary or Key).

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

Chrome is not doing anything (yet):

I think most readers come to roughly the same conclusion when reading the
RFC, but there is enough uncertainty that I think this is worth specifying
in more detail.