Redirections to `Content-Encoding: encrypted` payloads Thu, 01 October 2020 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6ABD63A097F for <>; Thu, 1 Oct 2020 15:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 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.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2XzLmoTEH8HP for <>; Thu, 1 Oct 2020 15:01:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 097863A0982 for <>; Thu, 1 Oct 2020 15:01:17 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kO6b4-00059G-PL for; Thu, 01 Oct 2020 21:58:42 +0000
Resent-Date: Thu, 01 Oct 2020 21:58:42 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kO6b3-00058Y-Re for; Thu, 01 Oct 2020 21:58:41 +0000
Received: from ([] by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kO6b2-00062I-55 for; Thu, 01 Oct 2020 21:58:41 +0000
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 3EFCE1292 for <>; Thu, 1 Oct 2020 14:58:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20200617-steevie-01; t=1601589507; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=z0bIyj1iFD5k3PbT0ldQS59FkF5vmbWKrlHLAd5EMU4=; b=CbtnWbZixSu8FphrjXfLIS822vI6kVNHZreiaODkl9zyLDFKCL+aWzSMch3NzqGeBZ4QOB PIFRjYQbj+CEppcZzJ23vepnkwDNR1twi3tHhY4x1PyqPPkZVnrwYblSGDGFmhwkFjwWWk xIXKKfrA2iIKAb1GoVI1BLZLC9Z5gI4=
Date: Thu, 1 Oct 2020 17:58:24 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Roundcube Webmail/1.3.15
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1kO6b2-00062I-55 eac8f78359a9fea17c7a6a762f0f0b1a
Subject: Redirections to `Content-Encoding: encrypted` payloads
Archived-At: <>
X-Mailing-List: <> archive/latest/38072
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi, all,

I've been thinking about an extension to HTTP for a little while and am 
curious whether you all think it's worth pursuing. Here's the use case: 
say I have some large file, maybe a video or something. Given my server 
and network resources, it's difficult for me to efficiently distribute 
that file. The obvious answer to this is to use e.g. a CDN, but now I've 
leaked the content of the file to the CDN. So I'd like to upload an 
encrypted version of the file to the CDN, and then redirect clients to 
that URL and say "by the way, here's the decryption key". I can think of 
a couple ways to do this:

1. Some kind of 3xx redirect, with an additional response header to 
distribute the key material. The issue with this is how the server can 
tell that the client will be able to follow such a redirect. 
draft-ietf-httpbis-client-hints to the rescue, maybe? (I could be wrong; 
I have literally only read the introduction for that I-D.) Another issue 
is what to do about headers. You don't want to leak e.g. the 
Content-Type, so you can't give the headers to the CDN to serve. But, 
the only other place to put them is in the original response, which is a 
3xx response. So now you're sending e.g. Content-Type headers that are 
basically lies, unless you encode them some other way.

2. Do option #1, but to solve the header problem define a new 3xx status 
code whose semantics say that the 3xx response's headers are 
authoritative, not the new location's headers. This does not seem like 
an important enough use case to allocate a new status code though.

3. Do option #1, but with a header that indicates option #2's semantics. 
E.g. `Redirect-Headers: use-original` or something. This also seems like 
a bad idea because now the same sequence of responses can be interpreted 
in completely disparate ways depending on whether the client supports 
`Redirect-Headers`, which seems like a recipe for disaster (especially 
because the server doesn't know in advance if the client supports 

4. Something like Alt-Svc, but that worked on the resource level instead 
of the origin. As a strawman let's say it's called Alt-Location. One 
awkward problem with this: because the server doesn't know whether the 
client will interpret the Alt-Location header, it needs to send the 
response body as usual, but if the client *does* interpret the header, 
it won't want the response body. Therefore the client will need to e.g. 
terminate the connection. Also, if the client receives e.g. several 
Alt-Svc values with different protocols, it can make an intelligent 
decision about which protocol it prefers, but with Alt-Location it's not 
clear how the client might pick between values.

5. Do option #4, but use Link and then add a header that explicitly 
signals the client to prefer rel=alternate Links. This has the same 
problem with sending the response body, though.

So, given the above, I'm wondering if the WG members have any interest 
in pursuing this usecase, and if so, have any thoughts on any of the 
above proposals. Is there anything I missed? Is there a decent way to do 
this with the correct semantics? All of the above ideas seem wrong in
various ways.