Redirections to `Content-Encoding: encrypted` payloads

[[e-mail]]

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 
`Redirect-Headers`).

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.

Cheers!

-AJ