Re: Updates to File API

I think encoding the security origin in the URL allows the UAs to do the
security origin check in place, without routing through other authority to
get the origin information that might cause the check taking long time to
finish.

If we worry about showing the double schemes in the URL, we can transform
the origin encoded in the URL by using base64 or other escaping algorithm.

Jian


On Wed, Jun 23, 2010 at 8:24 AM, David Levin <levin@google.com> wrote:

> On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman <adrianba@microsoft.com>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.
>
>>
> 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.
>
>>
> dave
>
>>
>>