[app-uri] Potential for proxying HTTP-based resources

Hi folks,

I've been reviewing the app URI spec [1] and I'm wondering whether the
algorithms included in this specification could be re-written in a way
that allow for broader re-use of this URI scheme in other scenarios.

The current design is that app:// URIs must synthesize both HTTP GET
requests and responses towards non-HTTP resources residing within a
file package (e.g. ZIP).

There could be more use for this URI scheme if could also act as a
proxy-like scheme (which is roughly what it is already doing but only
on top of non-HTTP file packages only). In such a case an app:// URI
would resolve to real HTTP resources (using any HTTP method) and also
to non-HTTP resources also (as per the current spec).

In the case a user agent has mapped a particular app:// URI to a
non-HTTP resource the current algorithms would still apply. In other
cases, the app:// URI could honour input HTTP headers (provided via
XHR for example). allow other HTTP methods to be used for those
requests (POST, PUT, DELETE, OPTIONS, etc) and be able to proxy back
any resulting HTTP responses to callers.

One particular use case we are considering is being able to (re-)use
app:// URIs as proxy URLs for local-IP URLs returned in the Network
Service Discovery API [2] (e.g. 'app://<uuid>/' would be a proxy URI
for 'http://192.168.1.12:6000/foo'). Exposing local-network URLs is a
privacy and security issue and the problem we are trying to resolve
segues nicely with the app:// URI scheme work.

Of course, we could invent yet another URI scheme for proxying
HTTP-based resources but having to continually mint new URI schemes is
an anti-pattern for the web we really want to avoid :)

I would be happy to help with any spec effort required here.

Best regards,

Rich

[1] http://www.w3.org/2012/sysapps/app-uri/

[2] https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html

Received on Thursday, 17 October 2013 00:39:29 UTC