Re: Lifetime of Blob URL
On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher da...@chromium.org wrote: Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. Note that unless we make changes (separate thread please) to XMLHttpRequest this will not work. It is a cross-origin URL which cannot work with CORS. -- Anne van Kesteren http://annevankesteren.nl/
[cors] Unrestricted access
Our API host is meant to be accessed only via XMLHttpRequest. No cookies are
involved, no classic web assumptions made. Every request must be
separately authenticated. Any request can be sent. The entire response can
be read. For native clients, this presents no problem. To allow this to
happen from browsers, our responses are becoming increasingly complex and
large:
public function handleRequest(Request $request)
{
$response = parent::handleRequest($request);
$response-setHeader('Access-Control-Allow-Origin', '*');
return $response;
}
public function handleOptions(Request $request)
{
$response = parent::handleOptions($request);
$response-setHeader('Access-Control-Allow-Methods',
$response-getHeader('Allow'));
$response-setHeader('Access-Control-Allow-Headers',
$request-getHeader('Access-Control-Request-Headers'));
$response-setHeader('Access-Control-Max-Age', '60');
return $response;
}
To this I should now add an Access-Control-Expose-Headers header with the
names of all of the headers in the response, minus those in the whitelist.
Perhaps there are other things that I forgot.
What I'd like is a global (per-host) way to disable these limitations all at
once, giving XHR unrestricted access to the host, just like native apps have
it.
[Bug 10143] New: how long is the comment going to be?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10143 Summary: how long is the comment going to be? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#int roduction-6 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#introduction-6 Comment: how long is the comment going to be? Posted from: 122.169.72.128 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [cors] Unrestricted access
On Tue, 13 Jul 2010 12:35:02 +0200, Jaka Jančar j...@kubje.org wrote: What I'd like is a global (per-host) way to disable these limitations all at once, giving XHR unrestricted access to the host, just like native apps have it. It used to be a mostly global per-resource switch, but the security folks at Mozilla thought that was too dangerous and we decided to go with the granular approach they proposed. This happened during a meeting in the summer of 2008 at Microsoft. I do not believe anything has changed meanwhile so this will probably not happen. -- Anne van Kesteren http://annevankesteren.nl/
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 12:48 AM, Anne van Kesteren ann...@opera.comwrote: On Mon, 12 Jul 2010 23:30:54 +0200, Darin Fisher da...@chromium.org wrote: Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. Note that unless we make changes (separate thread please) to XMLHttpRequest this will not work. It is a cross-origin URL which cannot work with CORS. It seems the origin for blob.url is defined to make it not cross-origin: http://dev.w3.org/2006/webapi/FileAPI/#originOfBlob and here http://dev.w3.org/2006/webapi/FileAPI/#url it mentions using the url for xhr again. dave -- Anne van Kesteren http://annevankesteren.nl/
CfC: to publish new WD of CORS; deadline July 20
All, Anne proposed WebApps publish a new WD of the CORS spec (last published in March 2009): http://dev.w3.org/2006/waf/access-control/ If you have any comments or concerns about this proposal, please send them to public-webapps by July 20 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow
RE: Lifetime of Blob URL
On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote: On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.com wrote: I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an img? Isn't this similarly indeterminate. As soon as img.src is set. the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. Should apply to xhr (after send is called), img, and navigation. Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. -Darin It sounds like you are saying the following is guaranteed to work: img.src = blob.url; window.revokeBlobUrl(blob); return; If that is the case then the user agent is already making the guarantees I was talking about and so I still think having the lifetime mapped to the blob not the document is better. This means that in the general case I don't have to worry about lifetime management. Adrian.
Re: XHR HTTP method support, Re: XHR LC comments
On 10.02.2010 16:54, Anne van Kesteren wrote: On Wed, 10 Feb 2010 16:49:18 +0100, Julian Reschke julian.resc...@gmx.de wrote: Remind me: what's the purpose of the W3C working on an XHR spec if even well-documented bugs like this do not get fixed by implementers? That it is clear this is in fact a bug and needs to be fixed. (I believe we fixed it actually, no idea when it will turn up in public builds.) Turns out is is fixed in Opera 10.60 -- great. So the last browser that needs to be fixed is IE... (just checked with the IE9 preview; no progress there). Best regards, Julian
Re: Lifetime of Blob URL
On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman adria...@microsoft.comwrote: On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote: On Mon, Jul 12, 2010 at 9:59 AM, David Levin le...@google.com wrote: On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman adria...@microsoft.com wrote: I read point #5 to be only about surviving the start of a navigation. As a web developer, how can I tell when a load has started for an img? Isn't this similarly indeterminate. As soon as img.src is set. the spec could mention that the resource pointed by blob URL should be loaded successfully as long as the blob URL is valid at the time when the resource is starting to load. Should apply to xhr (after send is called), img, and navigation. Right, it seems reasonable to say that ownership of the resource referenced by a Blob can be shared by a XHR, Image, or navigation once it is told to start loading the resource. -Darin It sounds like you are saying the following is guaranteed to work: img.src = blob.url; window.revokeBlobUrl(blob); return; If that is the case then the user agent is already making the guarantees I was talking about and so I still think having the lifetime mapped to the blob not the document is better. This means that in the general case I don't have to worry about lifetime management. Mapping lifetime to the blob exposes when the blob gets garbage collected which is a very indeterminate point in time (and is very browser version dependent -- it will set you up for compatibility issues when you update your javascript engine -- and there are also the cross browser issues of course). Specifically, a blob could go out of scope (to use your earlier phrase) and then one could do img.src = blobUrl (the url that was exposed from the blob but not using the blob object). This will work sometimes but not others (depending on whether garbage collection collected the blob). This is much more indeterminate than the current spec which maps the blob.url lifetime to the lifetime of the document where the blob was created. When thinking about blob.url lifetime, there are several problems to solve: 1. An AJAX style web application may never navigate the document and this means that every blob for which a URL is created must be kept around in some form for the lifetime of the application. 2. A blob passed to between documents would have its blob.url stop working as soon as the original document got closed. 3. Having a model that makes the url have a determinate lifetime which doesn't expose the web developer to indeterminate behaviors issues like we have discussed above. The current spec has issues #1 and #2. Binding the lifetime of blob.url to blob has issue #3. dave
Re: [cors] Unrestricted access
On Tue, Jul 13, 2010 at 3:47 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 13 Jul 2010 12:35:02 +0200, Jaka Jančar j...@kubje.org wrote: What I'd like is a global (per-host) way to disable these limitations all at once, giving XHR unrestricted access to the host, just like native apps have it. It used to be a mostly global per-resource switch, but the security folks at Mozilla thought that was too dangerous and we decided to go with the granular approach they proposed. This happened during a meeting in the summer of 2008 at Microsoft. I do not believe anything has changed meanwhile so this will probably not happen. This does not match my recollection of our requirements. The most important requirements that we had was that it was possible to opt in on a very granular basis, and that it was possible to opt in without getting cookies. Also note that the latter wasn't possible before we requested it and so this users requirements would not have been fulfilled if it wasn't for the changes we requested. Anyhow if we want to reopen discussions about syntax for the various headers that cors uses, for example to allow '*' as value, then I'm ok with that. Though personally I'd prefer to just ship this thing as it's a long time coming. / Jonas
Re: CfC: to publish new WD of CORS; deadline July 20
On Tue, Jul 13, 2010 at 6:50 AM, Arthur Barstow art.bars...@nokia.comwrote: All, Anne proposed WebApps publish a new WD of the CORS spec (last published in March 2009): http://dev.w3.org/2006/waf/access-control/ If you have any comments or concerns about this proposal, please send them to public-webapps by July 20 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow Hi Art, Just a reminder that the Security Consider sections http://dev.w3.org/2006/waf/access-control/#security needs to say more. Our last discussion of it at http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0709.html left the issue with: For example, will the Security Considerations section of CORS have to say: It is not safe in CORS to make a GET request for public data using a URL obtained from a possibly malicious party. Validating the URL requires global knowledge of all origins that might grant special access to the requestor's origin, and so return private user data. Yes, one would imagine saying something quite similar to that. [...] I am attempting to highlight that neither solution is a panacea, and that you need to be aware of the limitations of either approach. The UMP Security Considerations section has a long list of SHOULDs that need to be followed in order for the approach to be secure, just as the HTTP-State draft does, and just as the CORS spec should. Has anyone been working towards a revised Security Considerations section? -- Cheers, --MarkM
[IndexedDB] IDBRequest.abort on writing requests
Hi All,
Sorry if this is something that I've brought up before. I know I meant
to bring this up in the past, but I couldn't find any actual emails.
One thing that we discussed while implementing IndexedDB was what to
do for IDBRequest.abort() or writing requests. For example on the
request object returned from IDBObjectStore.remove() or
IDBCursor.update().
Ideal would of course be if it would cancel the write operation,
however this isn't always possible. If the call to .abort() comes
after the write operation has already executed in the database, but
before the 'success' event has had a chance to fire. What's worse is
that other write operations might already have been performed on top
of the aborted request. Consider for example the following code:
req1 = myObjectStore.remove(12);
req2 = myObjectStore.add({ id: 12, name: Benny Andersson });
do other stuff
req1.abort();
In this case, even if the database supported aborting a specific
operation, it's very hard to say what the correct thing to do with
operations performed after it. As far as I know, databases generally
don't support rolling back a given operation, only rolling back to a
specific point, i.e. rolling back a given operation and all operations
performed after it.
We could say that abort() signals some sort of error if the operation
has already been performed in the database, however that makes abort()
very racy.
Instead we concluded that the best thing to do was to specify that
IDBRequest.abort() should throw if called on a modifying request. If
this sounds good I'll make this change to the spec.
/ Jonas
Re: [IndexedDB] IDBRequest.abort on writing requests
On Tue, Jul 13, 2010 at 8:25 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Sorry if this is something that I've brought up before. I know I meant
to bring this up in the past, but I couldn't find any actual emails.
One thing that we discussed while implementing IndexedDB was what to
do for IDBRequest.abort() or writing requests. For example on the
request object returned from IDBObjectStore.remove() or
IDBCursor.update().
Ideal would of course be if it would cancel the write operation,
however this isn't always possible. If the call to .abort() comes
after the write operation has already executed in the database, but
before the 'success' event has had a chance to fire. What's worse is
that other write operations might already have been performed on top
of the aborted request. Consider for example the following code:
req1 = myObjectStore.remove(12);
req2 = myObjectStore.add({ id: 12, name: Benny Andersson });
do other stuff
req1.abort();
In this case, even if the database supported aborting a specific
operation, it's very hard to say what the correct thing to do with
operations performed after it. As far as I know, databases generally
don't support rolling back a given operation, only rolling back to a
specific point, i.e. rolling back a given operation and all operations
performed after it.
We could say that abort() signals some sort of error if the operation
has already been performed in the database, however that makes abort()
very racy.
Instead we concluded that the best thing to do was to specify that
IDBRequest.abort() should throw if called on a modifying request. If
this sounds good I'll make this change to the spec.
I'd be fine with that.
Or we could remove abort all together. I can't really think of what types
of operations you'd really want to abort until (at least) we have some sort
of join language or other mechanism to do really expensive read-only calls.
Or we could take abort off IDBRequest and instead put a rollback on
transactions (and not do the modify limitation). That way if something's
taking too long, you can say rollback. We'd be assured of getting back to
a consistent point in time and it'd of course stop execution.
J
Re: [IndexedDB] IDBRequest.abort on writing requests
On Tue, Jul 13, 2010 at 1:17 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Jul 13, 2010 at 8:25 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Sorry if this is something that I've brought up before. I know I meant
to bring this up in the past, but I couldn't find any actual emails.
One thing that we discussed while implementing IndexedDB was what to
do for IDBRequest.abort() or writing requests. For example on the
request object returned from IDBObjectStore.remove() or
IDBCursor.update().
Ideal would of course be if it would cancel the write operation,
however this isn't always possible. If the call to .abort() comes
after the write operation has already executed in the database, but
before the 'success' event has had a chance to fire. What's worse is
that other write operations might already have been performed on top
of the aborted request. Consider for example the following code:
req1 = myObjectStore.remove(12);
req2 = myObjectStore.add({ id: 12, name: Benny Andersson });
do other stuff
req1.abort();
In this case, even if the database supported aborting a specific
operation, it's very hard to say what the correct thing to do with
operations performed after it. As far as I know, databases generally
don't support rolling back a given operation, only rolling back to a
specific point, i.e. rolling back a given operation and all operations
performed after it.
We could say that abort() signals some sort of error if the operation
has already been performed in the database, however that makes abort()
very racy.
Instead we concluded that the best thing to do was to specify that
IDBRequest.abort() should throw if called on a modifying request. If
this sounds good I'll make this change to the spec.
I'd be fine with that.
Or we could remove abort all together. I can't really think of what types
of operations you'd really want to abort until (at least) we have some sort
of join language or other mechanism to do really expensive read-only calls.
I think there are expensive-ish read-only calls. Indexes are
effectively a join mechanism since you'll hit one b-tree to do the
index lookup, and then a second b-tree to look up the full object in
the objectStore.
I don't really feel strongly either way. I think abort() isn't too
hard to implement, but also doesn't provide a ton of value. At least
not, like you say, until we add expensive calls like getAll or
multi-step joins.
Or we could take abort off IDBRequest and instead put a rollback on
transactions (and not do the modify limitation).
I definitely think we should have IDBTransaction.abort() no matter
what. And that should allow rolling back write operations.
/ Jonas
RE: [IndexedDB] Current editor's draft
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Andrei Popescu Sent: Monday, July 12, 2010 5:23 AM Sorry I disappeared for a while. Catching up with this discussion was an interesting exercise...there is no particular message in this thread I can respond to, so I thought I'd just reply to the last one. Overall I think the new proposal is shaping up well and is being effective in simplifying scenarios. I do have a few suggestions and questions for things I'm not sure I see all the way. READ_ONLY vs READ_WRITE as defaults for transactions: To be perfectly honest, I think this discussion went really deep over an issue that won't be a huge deal for most people. My perspective, trying to avoid performance or usage frequency speculation, is around what's easier to detect. Concurrency issues are hard to see. On the other hand, whenever we can throw an exception and give explicit guidance that unblocks people right away. For this case I suspect it's best to default to READ_ONLY, because if someone doesn't read or think about it and just uses the stuff and tries to change something they'll get a clear error message saying if you want to change stuff, use READ_WRITE please. The error is not data- or context-dependent, so it'll fail on first try at most once per developer and once they fix it they'll know for all future cases. Dynamic transactions: I see that most folks would like to see these going away. While I like the predictability and simplifications that we're able to make by using static scopes for transactions, I worry that we'll close the door for two scenarios: background tasks and query processors. Background tasks such as synchronization and post-processing of content would seem to be almost impossible with the static scope approach, mostly due to the granularity of the scope specification (whole stores). Are we okay with saying that you can't for example sync something in the background (e.g. in a worker) while your app is still working? Am I missing something that would enable this class of scenarios? Query processors are also tricky because you usually take the query specification in some form after the transaction started (especially if you want to execute multiple queries with later queries depending on the outcome of the previous ones). The background tasks issue in particular looks pretty painful to me if we don't have a way to achieve it without freezing the application while it happens. Implicit commit: Does this really work? I need to play with sample app code more, it may just be that I'm old-fashioned. For example, if I'm downloading a bunch of data form somewhere and pushing rows into the store within a transaction, wouldn't it be reasonable to do the whole thing in a transaction? In that case I'm likely to have to unwind while I wait for the next callback from XmlHttpRequest with the next chunk of data. I understand that avoiding it results in nicer patterns (e.g. db.objectStores(foo).get(123).onsuccess = ...), but in practice I'm not sure if that will hold given that you still need error callbacks and such. Nested transactions: Not sure why we're considering this an advanced scenario. To be clear about what the feature means to me: make it legal to start a transaction when one is already in progress, and the nested one is effectively a no-op, just refcounts the transaction, so you need equal amounts of commit()'s, implicit or explicit, and an abort() cancels all nested transactions. The purpose of this is to allow composition, where a piece of code that needs a transaction can start one locally, independently of whether the caller had already one going. Schema versioning: It's unfortunate that we need to have explicit elements in the page for the versioning protocol to work, but the fact that we can have a reliable mechanism for pages to coordinate a version bump is really nice. For folks that don't know about this the first time they build it, an explicit error message on the schema change timeout can explain where to start. I do think that there may be a need for non-breaking changes to the schema to happen without a version dance. For example, query processors regularly create temporary tables during sorts and such. Those shouldn't require any coordination (maybe we allow non-versioned additions, or we just introduce temporary, unnamed tables that evaporate on commit() or database close()...). Thanks -pablo
Re: CfC: to publish new WD of CORS; deadline July 20
On Tue, 13 Jul 2010 15:50:46 +0200, Arthur Barstow art.bars...@nokia.com wrote: All, Anne proposed WebApps publish a new WD of the CORS spec (last published in March 2009): Yes please... cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
