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

On Thu, Oct 17, 2013 at 11:52 AM, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> 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?

This doesn't address the issue because the specification only attempts
to honour HTTP GET requests, ignores any user-supplied HTTP request
headers and only returns basic HTTP responses (it's unclear whether
additional response headers should be stripped to the basic level
provided by this spec). This note in the spec is a punt on the
specific steps required. Maybe we can clarify that.

It would be interesting to hear about your use cases and/or if you
have a reference to any previous discussion on this subject.

Thanks,

Rich

> -----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 01:03:10 UTC