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

On Fri, Oct 18, 2013 at 4:25 AM, Marcos Caceres <w3c@marcosc.com> wrote:
> On Thursday, October 17, 2013 at 2:22 AM, Mandyam, Giridhar wrote:
>
>> 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.
>>
>
>
> There is no reason we can't build on the spec as we go - but right now it more or less does what we need. So, I'd like to see some kind of implementation first that shows this working with things other than GET. I'm worried of adding more stuff to the spec preemptively when it currently meets a well understood set of use cases across at least two runtimes (Tizen and FxOS).
>

That's a reasonable objective and I do think you have an interesting
proposal here. I wanted to highlight that what you have developed has
a lot of potential use beyond just dereferencing 'packaged' resources.
This could be _the_ opaque client-side URI proxy scheme to use to
dereference different resource 'classes', each with its own
well-defined dereferencing model provided by the spec.

I made a case where we would need something like this in NSD in [1].
It would also make sense for security and privacy reasons in the
ongoing WebRTC effort [2]. app URIs could also provide a dereferencing
model for Blobs, thereby replacing the custom Blob URI scheme [3] that
needed to be created in the absence of such a general purpose URI
scheme. Implementers currently need to maintain different schemes
that, at the URI level, fulfil similar functionality (e.g. Blob URIs,
Stream URIs). There could be cost savings to only requiring
implementation of one scheme that comes with different dereferencing
models depending on the masked resource type.

That wouldn't affect existing use cases or implementations of app://
URI usage toward 'package' type resources. The objective would be on
providing additional dereferencing models to create a common, single
client-side URI scheme that can be used and reused for both existing
and future use cases cropping up elsewhere in the web platform.

br/ Rich

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0152.html

[2] https://2x.io/read/security-by-obscurity

[3] http://www.w3.org/TR/FileAPI/#url

Received on Thursday, 24 October 2013 03:32:04 UTC