Hi Dave,
On 6/23/10 8:24 AM, David Levin wrote:
On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman
<[email protected] <mailto:[email protected]>> wrote:
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
> I agree with you Adrian that it makes sense to let the user
agent figure
> out the optimal way of implementing origin and other checks.
>
> A logical step from that premise is that the choice/format of the
> namespace specific string should be left up to the UA as embedding
> information in there may be the optimal way for some UA's of
implementing
> said checks, and it sounds like other UAs may not want to do that.
Robin outlined why that would be a problem [1]. My original
feeling was that this should be left up to UAs, as you say, but
I've been convinced that doing so is a race to the most complex
URL scheme.
Robin discussed something that could possibly in
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At
the same time, there are implementors who gave specific reasons
why encoding certain information (scheme, host, port) in the namespace
specific string (NSS) is useful to various UAs. No other information
has been requested, so theories adding more information seem premature.
If the format must be specified, it seems reasonable to take both the
theoretical and practical issues into account.
I agree that both theoretical and practical issues should be taken into
account. While I was initially in favor of a uniform URL format for
blob: URLs, after following this discussion I came up with:
http://dev.w3.org/2006/webapi/FileAPI/#url
This allows a few things that I think the WG has discussed as desirable:
1. The scheme consists of an opaque string, which I recommend is like
UUID in its canonical form. The scheme does not disallow the inclusion
of origin information in the URL, though I personally think
implementations could use "smart caching" and not necessarily use the
scheme to store this information.
2. The scheme allows for fragment identifiers, which are applicable on a
media-type basis to the Blob being accessed.
It was clear that a "one size fits all" wouldn't be desirable. I think
*generally speaking* the actual blob: URL is hidden from authors, who
won't have cause to interact with format, and this is why I chose to
specify this the way I have.
Encoding that the security origin in the NSS isn't complex. If a
proposal is needed about how that can be done in a simple way, I'm
willing to supply one. Also, UAs that don't care about that
information are free to ignore it and don't need to parse it.
I think it might be useful to supply one, but my instinct is that this
does not need to be part of the specification.
-- A*
