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

Hi Rich,
Can't speak for Marcos, but I did raise with him the possibility of retrieving package resources via a local proxy.  As a result, the following note was added in Section 6:

"Note: A user agent can deference a URI scheme using other means/technologies (e.g., a proxy or local web server), but the end result needs to be indistinguishable from the result that would be obtained by following the specification." 

Does this address your use case of a proxy URI?

-Giri
-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Wednesday, October 16, 2013 5:39 PM
To: public-sysapps@w3.org
Subject: [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:52:58 UTC