- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 06 Mar 2012 01:12:02 +1300
- To: ietf-http-wg@w3.org
On 6/03/2012 12:14 a.m., Stefan Eissing wrote: > So the gist of http+aes is to URL-inject a Transfer-Encoding into the > existing http infrastructure? Content-Encoding, not Transfer-Encoding. Otherwise yes. Looks like a nifty way to write page URLs for browser-only interpretation to me. But no reason why the scheme should be permissible or even needed in an HTTP request-URI field. The use-case presented is secure storage on an untrusted host. Which implies that the http+aes:// is mapped to http:// before requesting. The +aes and userinfo portions staying internal to the client agent for determining only handling of the response. Untrusted host and all other infrastructure see just a standard http:// request (no userinfo) with opaque binary entity. Ditto for https+aes with equivalent mapping. AYJ
Received on Monday, 5 March 2012 12:12:34 UTC