Re: http+aes

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