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

I actually agree that it would be nice if this mechanism was made for more general usage, and made a request that Section 6.4 be marked as informative or removed (see http://lists.w3.org/Archives/Public/public-sysapps/2013Apr/0226.html).  We decided collectively that the note would be the best way forward.

The use case that the group has considered from the start was the retrieval of resources from a package, which is a carry-over use case from the widget work in the WebApps WG.   I interpreted the note that Marcos added as meaning that if I design a proxy to handle app:URI requests, then I am not bound by the rules/procedures outlined in Section 6.4.  However, the response should still be identical (e.g. headers should not affect the response).

If we are looking at app:URI for not just GET and with header interpretation, then we should probably re-examine the specification for suitability.  

-Giri

-----Original Message-----
From: Rich Tibbett [mailto:richt@opera.com] 
Sent: Wednesday, October 16, 2013 6:03 PM
To: Mandyam, Giridhar
Cc: public-sysapps@w3.org
Subject: 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:23:06 UTC