file sharing services
Hello, I am new here, not sure if it's the good place to talk about my problem. What I understand, CORS is a new specification, and it was introduced in the latest Firefox 8. Many users started to edit their servers properties using Access-Control-Allow-Origin property. What about servers we don't have access to, like the file sharing services (Dropbox, Photobucket). For example, in my project, I hosted many files on Dropbox Public Folder : now it is becoming useless because CORS is not enabled on Dropbox. What should be done ? Can Dropbox change his policy according to CORS ? Does your group can contact file sharing services so they can adapt their services to CORS ? Thank you very much, -- Nicolas Mollet nico.mol...@gmail.com
[File API] Other sources for Blob data.
In several thought experiments using the File API I've wanted to create a
Blob for data that I haven't materialized. It seems that a way to create a
blob backed by an arbitrary data source would be useful. In particular, I
would like to see a blob constructor that takes a URL and size as well as
one that takes a callback.
A URL constructed blob could use a byte range request when a FileReader
requests a slice of the blob. i.e the internal implementation could be
reasonably efficient.
A callback backed blob would be a bit more complicated. Maybe something
like the interface below, though you'd probably need another level of
indirection in order to deal with concurrency.
interface BlobDataProvider : EventTarget {
void getDataSlice(long long start, long long end);
void abort();
readonly attribute any result;
readonly attribute unsigned short readyState;
attribute [TreatNonCallableAsNull] Function? onloadstart;
attribute [TreatNonCallableAsNull] Function? onprogress;
attribute [TreatNonCallableAsNull] Function? onload;
attribute [TreatNonCallableAsNull] Function? onabort;
attribute [TreatNonCallableAsNull] Function? onerror;
attribute [TreatNonCallableAsNull] Function? onloadend;
}
Alternatively, exposing the (internal) interface FileReader uses to
interact with a Blob would remove the magic from a Blob and let a user
synthesize their own blob.
--
Steve
Re: CfC: publish new WD of XHR; deadline December 5
On 11/30/11 8:17 PM, ext Adrian Bateman wrote: On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote: Anne completed his merge XHR and XHR2 merge and the new History section includes information about the merge. As such, this is a Call for Consensus to publish a new WD of XHR using the following ED (not yet pub ready) as the basis: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by December 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I missed much of the discussion on this until now because of the holiday over the weekend in the US. As I said at TPAC, I think continuing only with XHR2 in this exceptional circumstance is the right move provided the group doesn't make a habit of dropping things because there's a newer shiny version. With that in mind, I'd like to see the XHR1 document published as a WG Note. I received a question just this morning asking about the expected behaviour for an XHR implementation in a pre-CORS environment. While not perfect, the XHR1 document is a reasonably good record of the state of implementations prior to CORS and I'm reluctant to lose that information or to have to rely on trying to find a CR publication that doesn't even appear in the history of the new document. Secondly, at least within Microsoft and the web developers that I talk to, the notion of XHR L2 is one that they're familiar with and understood to be distinct from the original. Could we not continue to publish into TR space using the 2 suffix? It appears Adrian is proposing: .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what version of XHR would be used: the 3-Aug-2010 XHR CR, the last ED that was created, some other version? .../TR/XMLHttpRequest2/ be used for Anne's merged version and titled XMLHttpRequest Level 2. Anne, All - WDYT? Adrian - if there is consensus to do something like the above, would you commit to doing the editorial work on the WG Note? (FWIW, I think Adrian's proposal is reasonable and it meets the I Can Live With It Test and if Anne wants the ED to remain version-less, that's OK, provided L2 is added to versions published in /TR/.) -AB
Re: CfC: publish new WD of XHR; deadline December 5
On Thu, 01 Dec 2011 13:29:37 +0100, Arthur Barstow art.bars...@nokia.com wrote: It appears Adrian is proposing: .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what version of XHR would be used: the 3-Aug-2010 XHR CR, the last ED that was created, some other version? .../TR/XMLHttpRequest2/ be used for Anne's merged version and titled XMLHttpRequest Level 2. Anne, All - WDYT? Adrian - if there is consensus to do something like the above, would you commit to doing the editorial work on the WG Note? (FWIW, I think Adrian's proposal is reasonable and it meets the I Can Live With It Test and if Anne wants the ED to remain version-less, that's OK, provided L2 is added to versions published in /TR/.) It seems totally pointless to me, but we can add even more cruft to the TR/ versions, sure. I should probably also add a disclaimer similar to what http://www.w3.org/TR/html5/ has so it is clear TR/ does not represent the latest version. -- Anne van Kesteren http://annevankesteren.nl/
RE: CfC: publish new WD of XHR; deadline December 5
On Thursday, December 01, 2011 5:12 AM, Anne van Kesteren wrote: On Thu, 01 Dec 2011 13:29:37 +0100, Arthur Barstow art.bars...@nokia.com wrote: It appears Adrian is proposing: .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what version of XHR would be used: the 3-Aug-2010 XHR CR, the last ED that was created, some other version? .../TR/XMLHttpRequest2/ be used for Anne's merged version and titled XMLHttpRequest Level 2. Anne, All - WDYT? Adrian - if there is consensus to do something like the above, would you commit to doing the editorial work on the WG Note? (FWIW, I think Adrian's proposal is reasonable and it meets the I Can Live With It Test and if Anne wants the ED to remain version-less, that's OK, provided L2 is added to versions published in /TR/.) It seems totally pointless to me, but we can add even more cruft to the TR/ versions, sure. I should probably also add a disclaimer similar to what http://www.w3.org/TR/html5/ has so it is clear TR/ does not represent the latest version. I don't think it's pointless for the reasons I gave. One of the valuable aspects of the W3C is the traceability that comes from the archive in TR space. We have implementations of XHR L1 that, while not 100%, are mostly conforming deployed with customers. I am happy to help with whatever work is needed to make this happen. I haven't reviewed what errata have been added to the CR document in the editor's draft. If there's nothing significant (and I'd hope there wouldn't be to a CR document) I think we could just publish the CR document with appropriate editing as a Note and be done. It's the CR document I'd like to not leave dangling. Cheers, Adrian.
Re: file sharing services
On Mon, Nov 28, 2011 at 4:05 AM, Nicolas Mollet nico.mol...@gmail.com wrote: Hello, I am new here, not sure if it's the good place to talk about my problem. What I understand, CORS is a new specification, and it was introduced in the latest Firefox 8. Many users started to edit their servers properties using Access-Control-Allow-Origin property. What about servers we don't have access to, like the file sharing services (Dropbox, Photobucket). For example, in my project, I hosted many files on Dropbox Public Folder : now it is becoming useless because CORS is not enabled on Dropbox. What should be done ? Can Dropbox change his policy according to CORS ? Does your group can contact file sharing services so they can adapt their services to CORS ? Thank you very much, Yes, third-party hosting services need to add CORS headers as well if they want their stuff to be accessible from XHR, etc. It's the same process for them as it is for a normal author. It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. ^_^ ~TJ
Re: file sharing services
On Thu, Dec 1, 2011 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. I would expect that contacts from their paying customers would be more effective than contacts from people on this list anyways. - Kyle
RE: Add PointerLock and Gamepad APIs to WebApps' charter; deadline December 1
On Thursday, November 24, 2011 5:16 AM, Arthur Barstow wrote: Below, Darin proposes the Pointer Lock [PL] (formerly known as Mouse Lock) spec and the Gamepad [GP] spec be added to the Web Applications WG's charter and not the Web Events WG's charter. This is a Call for Consensus to accept that proposal. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is December 1 and all comments should be sent to public-webapps at w3.org. -AB [PL] http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html [GP] http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html Reviewing the consequences of adopting a new work item not currently in the charter is a significant piece of work for us and one week is insufficient to reach a conclusion. I expect this proposal will be formally reviewed as part of the overall charter review as with the other proposals we discussed at TPAC and that this call for consensus is for including these specs as deliverables on the proposed charter. At the present time Microsoft doesn't have a position for or against working on these specs in WebApps but it seems reasonable to include them for consideration in the proposed new WebApps charter. Cheers, Adrian.
Re: [File API] Other sources for Blob data.
On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart vand...@google.comwrote:
In several thought experiments using the File API I've wanted to create a
Blob for data that I haven't materialized. It seems that a way to create a
blob backed by an arbitrary data source would be useful. In particular, I
would like to see a blob constructor that takes a URL and size as well as
one that takes a callback.
A URL constructed blob could use a byte range request when a FileReader
requests a slice of the blob. i.e the internal implementation could be
reasonably efficient.
Note that since Blobs need to know their size when constructed,
constructing a blob like this would need to be async.
That would also imply that if you read a whole file this way, you're always
going to make two HTTP requests; a HEAD to determine the size and then a
GET.
A callback backed blob would be a bit more complicated. Maybe something
like the interface below, though you'd probably need another level of
indirection in order to deal with concurrency.
interface BlobDataProvider : EventTarget {
void getDataSlice(long long start, long long end);
void abort();
readonly attribute any result;
readonly attribute unsigned short readyState;
attribute [TreatNonCallableAsNull] Function? onloadstart;
attribute [TreatNonCallableAsNull] Function? onprogress;
attribute [TreatNonCallableAsNull] Function? onload;
attribute [TreatNonCallableAsNull] Function? onabort;
attribute [TreatNonCallableAsNull] Function? onerror;
attribute [TreatNonCallableAsNull] Function? onloadend;
}
FYI:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029998.html
FWIW, I was thinking along these lines:
interface BlobDataProvider : EventTarget {
void getSize(BlobDataProviderResult result);
void getDataSlice(long long start, long long end, BlobDataProviderResult
result);
}
interface BlobDataProviderResult : EventTarget {
void result(any data);
void error();
attribute [TreatNonCallableAsNull] Function? onabort;
}
result can be called multiple times, to provide data incrementally.
Progress events are up to the browser.
That said, the only use case I've seen for it is weak DRM, which isn't very
interesting.
--
Glenn Maynard
RE: IndexedDB: multientry or multiEntry?
On Wednesday, November 30, 2011 6:30 PM, Jonas Sicking wrote: On Wed, Nov 30, 2011 at 6:22 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Nov 30, 2011 at 6:11 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote: On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell jsb...@chromium.org wrote: Should the parameter used in IDBObjectStore.createIndex() and the property on IDBIndex be spelled multientry (as it is in the spec currently), or multiEntry (based on multi-entry as the correct English spelling)? Has any implementation shipped with the new name yet (vs. the old multirow)? Any strong preferences? Much of HTML uses all-lowercase names for similar things, both in markup and in the DOM. I would actually prefer to go the other way and change autoIncrement to autoincrement. / Jonas We currently have implemented the behavior per spec as multientry on our Win8 preview build and in follow on IE preview builds. However, we would prefer for it to be camelCase since it matches the attributes we've already defined in the spec. More important, this seems to match the web platform closer. I believe the difference here is that these names are supposed to represent properties in a JS object which devs would expect to be camelCase like other attributes in the DOM spec. I'm not sure about the markup argument. Also, if we end up making autoincrement all lower case, I would imagine we would want to be consistent and make keyPath all lower case too. This seems different. Agreed. While HTML favors all-lowercase, JS and DOM favor camelCase. While I still prefer multientry (and autoincrement and keypath), I don't care that strongly. So does this mean we should make the name both in the options object and on IDBIndex(Sync) use multiEntry? Also, I noticed that IDBObjectStore(Sync) doesn't expose .autoIncrement. We should expose that right? / Jonas Yes, I believe we should make the entries and the options be camelCase and match. I can work with Eliot to make these changes to the spec. Israel
Re: file sharing services
On 12/1/11 11:10 AM, ext Kyle Huey wrote: On Thu, Dec 1, 2011 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. I would expect that contacts from their paying customers would be more effective than contacts from people on this list anyways. Tab and Kyle make good points, Nicolas. If this group (along with the WebAppSec WG which is a joint owner of CORS) was going to do some education/outreach for CORS, it seems like that work should wait until there is an approved test suite that at least two independent implementations pass. -AB
Re: CfC: publish new WD of Indexed Database API; deadline Oct 21
Hi All - although this CfC passed, for various reasons the WD was not published before TPAC. However, yesterday, Jonas and Eliot prepared a WD that is now queued for publishing on Dec 6: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview-WD-06-December-2011.html On 10/14/11 4:04 PM, ext Arthur Barstow wrote: This is a Call for Consensus to publish a new Working Draft of the Indexed Database API spec (last published 19-Apr-2011): http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
[Bug 15029] New: Change multientry to multiEntry
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15029 Summary: Change multientry to multiEntry Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Both on IDBIndex.multiEntry and in IDBIndexParameters -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15030] New: Add IDBObjectStore.autoIncrement
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15030 Summary: Add IDBObjectStore.autoIncrement Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org -- Configure bugmail: https://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: file sharing services
Guys, thanks for your answers. I already have contacted Google, Firefox, Dropbox via their forums or bugtrackers, not sure it was the best way to get a fix. Here is a list of all the issues regarding CORS - Google Maps - Firefox 8. I started some threads or replied and as you can see, there is no satisfying answers and I am perseverant :) *Google* http://www.google.com/support/forum/p/maps/thread?tid=7eb0f0fc309dfe23hl=en http://www.google.com/support/forum/p/maps/thread?tid=6c4541ac4e256f2ahl=en http://www.google.com/support/forum/p/maps/thread?tid=44ec11321e8edc54hl=en http://www.google.com/support/forum/p/maps/thread?tid=173cb1d9bea41959hl=en http://www.google.com/support/forum/p/maps/thread?tid=346feb37d54bf8e9hl=en http://www.google.com/support/forum/p/maps/thread?tid=76bbefb8768eb061hl=en http://www.google.com/support/forum/p/maps/thread?tid=0a399303297b8012hl=en http://www.google.com/support/forum/p/maps/thread?tid=22728e875335da8ahl=en http://www.google.com/support/forum/p/maps/thread?tid=20cd8d2ef55a96b0hl=en http://code.google.com/p/gmaps-api-issues/issues/detail?id=3776 http://code.google.com/p/google-mapmaker/issues/detail?id=2203 https://groups.google.com/a/googleproductforums.com/forum/#!starred/maps-fr/VW3tBZVwFlE[french] https://groups.google.com/a/googleproductforums.com/forum/#!starred/maps-fr/8My40IE3Q6E[french] https://groups.google.com/a/googleproductforums.com/forum/#!starred/maps-fr/oFLnYDkFjuM[french] *Firefox* https://bugzilla.mozilla.org/show_bug.cgi?id=702578 http://support.mozilla.com/en-US/questions/900139 https://support.mozilla.com/en-US/questions/896295 https://support.mozilla.com/en-US/questions/896282 https://support.mozilla.com/en-US/questions/894493 https://support.mozilla.com/en-US/questions/896496 http://forums.mozillazine.org/viewtopic.php?f=25t=2359775 https://support.mozilla.com/en-US/questions/900503 *Dropbox* https://www.dropbox.com/votebox/7147/enable-cors http://forums.dropbox.com/topic.php?id=48749replies=1 I figured out also, that Google didn't enable CORS on his own servers. For example, I was talking about Dropbox, but the same problem exists with hosting files on Google Sites, or Google Code. Anyway I understand your position, I guess Google/Firefox/Dropbox and whoever didn't enabled CORS, will fix the issue when a certain number of people complain... so I have to whine even more :) I will keep this thread updated in case I get more news. Thanks a lot -- Nicolas Mollet nico.mol...@gmail.com On Thu, Dec 1, 2011 at 6:58 PM, Arthur Barstow art.bars...@nokia.comwrote: On 12/1/11 11:10 AM, ext Kyle Huey wrote: On Thu, Dec 1, 2011 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.commailto: jackalm...@gmail.com wrote: It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. I would expect that contacts from their paying customers would be more effective than contacts from people on this list anyways. Tab and Kyle make good points, Nicolas. If this group (along with the WebAppSec WG which is a joint owner of CORS) was going to do some education/outreach for CORS, it seems like that work should wait until there is an approved test suite that at least two independent implementations pass. -AB
CfC: publish WG Note of the old XHR(1); deadline December 8
Adrian proposed the old XHR(1) spec be published as a WG Note (to clearly state work on that spec has stopped) and this is a Call for Consensus to do so. If you have any comments or concerns about this proposal, please send them to public-webapps by December 8 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -AB Original Message Subject:Re: CfC: publish new WD of XHR; deadline December 5 Resent-Date:Thu, 1 Dec 2011 12:30:54 + Resent-From:public-webapps@w3.org Date: Thu, 1 Dec 2011 07:29:37 -0500 From: ext Arthur Barstow art.bars...@nokia.com To: ext Adrian Bateman adria...@microsoft.com, Anne van Kesteren ann...@opera.com CC: public-webapps@ public-webapps public-webapps@w3.org On 11/30/11 8:17 PM, ext Adrian Bateman wrote: On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote: Anne completed his merge XHR and XHR2 merge and the new History section includes information about the merge. As such, this is a Call for Consensus to publish a new WD of XHR using the following ED (not yet pub ready) as the basis: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by December 5 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. I missed much of the discussion on this until now because of the holiday over the weekend in the US. As I said at TPAC, I think continuing only with XHR2 in this exceptional circumstance is the right move provided the group doesn't make a habit of dropping things because there's a newer shiny version. With that in mind, I'd like to see the XHR1 document published as a WG Note. I received a question just this morning asking about the expected behaviour for an XHR implementation in a pre-CORS environment. While not perfect, the XHR1 document is a reasonably good record of the state of implementations prior to CORS and I'm reluctant to lose that information or to have to rely on trying to find a CR publication that doesn't even appear in the history of the new document. Secondly, at least within Microsoft and the web developers that I talk to, the notion of XHR L2 is one that they're familiar with and understood to be distinct from the original. Could we not continue to publish into TR space using the 2 suffix? It appears Adrian is proposing: .../TR/XMLHttpRequest/ be a WG Note but it's not clear to me what version of XHR would be used: the 3-Aug-2010 XHR CR, the last ED that was created, some other version? .../TR/XMLHttpRequest2/ be used for Anne's merged version and titled XMLHttpRequest Level 2. Anne, All - WDYT? Adrian - if there is consensus to do something like the above, would you commit to doing the editorial work on the WG Note? (FWIW, I think Adrian's proposal is reasonable and it meets the I Can Live With It Test and if Anne wants the ED to remain version-less, that's OK, provided L2 is added to versions published in /TR/.) -AB
[cors] JAX-RS and preflight
There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight?
Re: [cors] JAX-RS and preflight
On 2011-12-01 21:20, Benson Margulies wrote: There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. That seems to be entirely JAX-RS problem. The *resource* is supposed to be identified by the request-URI. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. Even if OPTIONS would be sent with a Content-Type header field, that field, by definition, would identify the internet media type of the request body. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Absolutely. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight? Unless I'm missing something here you are definitively trying to do the wrong thing. Best regards, Julian
Re: file sharing services
I spoke to Jonas and several others at TPAC, and everyone agreed that for web servers that are not behind a firewall, it's safe to *always* Access-Control-Allow-Origin: *. If this is true, as it seems to be, it would be great if the spec would explicitly call out the reason for requiring the header for cookie-less requests, and say that in non-firewall cases, it's always safe to include the header. Yehuda Katz (ph) 718.877.1325 On Thu, Dec 1, 2011 at 7:53 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Nov 28, 2011 at 4:05 AM, Nicolas Mollet nico.mol...@gmail.com wrote: Hello, I am new here, not sure if it's the good place to talk about my problem. What I understand, CORS is a new specification, and it was introduced in the latest Firefox 8. Many users started to edit their servers properties using Access-Control-Allow-Origin property. What about servers we don't have access to, like the file sharing services (Dropbox, Photobucket). For example, in my project, I hosted many files on Dropbox Public Folder : now it is becoming useless because CORS is not enabled on Dropbox. What should be done ? Can Dropbox change his policy according to CORS ? Does your group can contact file sharing services so they can adapt their services to CORS ? Thank you very much, Yes, third-party hosting services need to add CORS headers as well if they want their stuff to be accessible from XHR, etc. It's the same process for them as it is for a normal author. It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. ^_^ ~TJ
Re: file sharing services
There are serious security implications for enabling CORS, even with session-less requests. It's going to be a very long opt-in process for file sharing services. -Charles On 12/1/11 1:12 PM, Yehuda Katz wrote: I spoke to Jonas and several others at TPAC, and everyone agreed that for web servers that are not behind a firewall, it's safe to *always* Access-Control-Allow-Origin: *. If this is true, as it seems to be, it would be great if the spec would explicitly call out the reason for requiring the header for cookie-less requests, and say that in non-firewall cases, it's always safe to include the header. Yehuda Katz (ph) 718.877.1325 On Thu, Dec 1, 2011 at 7:53 AM, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: On Mon, Nov 28, 2011 at 4:05 AM, Nicolas Mollet nico.mol...@gmail.com mailto:nico.mol...@gmail.com wrote: Hello, I am new here, not sure if it's the good place to talk about my problem. What I understand, CORS is a new specification, and it was introduced in the latest Firefox 8. Many users started to edit their servers properties using Access-Control-Allow-Origin property. What about servers we don't have access to, like the file sharing services (Dropbox, Photobucket). For example, in my project, I hosted many files on Dropbox Public Folder : now it is becoming useless because CORS is not enabled on Dropbox. What should be done ? Can Dropbox change his policy according to CORS ? Does your group can contact file sharing services so they can adapt their services to CORS ? Thank you very much, Yes, third-party hosting services need to add CORS headers as well if they want their stuff to be accessible from XHR, etc. It's the same process for them as it is for a normal author. It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. ^_^ ~TJ
Re: file sharing services
Yehuda Katz (ph) 718.877.1325 On Thu, Dec 1, 2011 at 1:51 PM, Charles Pritchard ch...@jumis.com wrote: ** There are serious security implications for enabling CORS, even with session-less requests. It's going to be a very long opt-in process for file sharing services. For sessionless requests, what are those concerns? -Charles On 12/1/11 1:12 PM, Yehuda Katz wrote: I spoke to Jonas and several others at TPAC, and everyone agreed that for web servers that are not behind a firewall, it's safe to *always* Access-Control-Allow-Origin: *. If this is true, as it seems to be, it would be great if the spec would explicitly call out the reason for requiring the header for cookie-less requests, and say that in non-firewall cases, it's always safe to include the header. Yehuda Katz (ph) 718.877.1325 On Thu, Dec 1, 2011 at 7:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Nov 28, 2011 at 4:05 AM, Nicolas Mollet nico.mol...@gmail.com wrote: Hello, I am new here, not sure if it's the good place to talk about my problem. What I understand, CORS is a new specification, and it was introduced in the latest Firefox 8. Many users started to edit their servers properties using Access-Control-Allow-Origin property. What about servers we don't have access to, like the file sharing services (Dropbox, Photobucket). For example, in my project, I hosted many files on Dropbox Public Folder : now it is becoming useless because CORS is not enabled on Dropbox. What should be done ? Can Dropbox change his policy according to CORS ? Does your group can contact file sharing services so they can adapt their services to CORS ? Thank you very much, Yes, third-party hosting services need to add CORS headers as well if they want their stuff to be accessible from XHR, etc. It's the same process for them as it is for a normal author. It's possible that someone from this mailing list could contact those services. It's more likely to happen, though, if you do it yourself. ^_^ ~TJ
Re: CfC: publish new WD of XHR; deadline December 5
On Thu, 01 Dec 2011 16:44:49 +0100, Adrian Bateman adria...@microsoft.com wrote: I don't think it's pointless for the reasons I gave. One of the valuable aspects of the W3C is the traceability that comes from the archive in TR space. We have implementations of XHR L1 that, while not 100%, are mostly conforming deployed with customers. Given the testsuite we have, that seems false, but okay. I am happy to help with whatever work is needed to make this happen. I haven't reviewed what errata have been added to the CR document in the editor's draft. If there's nothing significant (and I'd hope there wouldn't be to a CR document) I think we could just publish the CR document with appropriate editing as a Note and be done. It's the CR document I'd like to not leave dangling. There's been plenty of errata. In fact, the WG determined there was within two weeks after publishing the Candidate Recommendation: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0448.html And that was well over a year ago. I only included drafts under Previous Versions that led up to the current draft. E.g. http://www.w3.org/TR/2010/WD-XMLHttpRequest2-20100907/ was published just after the CR and offers a much better description of the same features. http://www.w3.org/TR/2011/WD-XMLHttpRequest2-20110816/ is even better, and http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html is best. We just reached CR because everyone was either tired of reviewing or could spot no more mistakes at that point. Soon after though when some tests were written, faults were uncovered. And I know we will uncover more in the future. So that is why I think it is pointless to bestow some kind of meaning on a draft published well over a year ago. I also wish we'd have technical discussion, as at that Offline Workshop, rather than a procedural discussion whenever Art issues a CfC on one of the drafts I work on. -- Anne van Kesteren http://annevankesteren.nl/
[indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404
Jonas, Since you believe we should keep the values of version as a non-nullable long long, what should the value of version be during the first run/creation if the transaction is aborted? Should it be 0 (I don't believe we want version to be a negative number)? Israel
Re: [cors] JAX-RS and preflight
Let me try to present this more clearly. First of all, I did not design or implement JAX-RS itself. The committee that designed it might have done something wrong in their dispatching approach. However, *I* am merely working on implementing a facility for the resource side of CORS in a JAX-RS framework. Perhaps it would be less disturbing if I characterized the situation as follows: JAX-RS dispatches the job of serving content at a smaller granularity than an HTTP/CORS 'resource'. It operates on the combination of resource+content-type+accepts+accepts-language. All of those facts are available to a preflight except for the content type when the content-type is non-simple. My humble request is for you to consider defining one more 'request' header for preflight: access-control-request-content-type -- that the client would send to the server on the OPTIONS command. There are many, many, services written with JAX-RS -- representing a classic case of that old standardization chestnut: 'existing practice.' What I'm proposing here would be trivial for client implementations, so I would think that the authors of the CORS proposal would at least grant this idea a full 5 minutes of thought before rejecting it. Obviously, if you do reject this, it will not be the end of the internet as we know it. On Thu, Dec 1, 2011 at 3:57 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-01 21:20, Benson Margulies wrote: There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. That seems to be entirely JAX-RS problem. The *resource* is supposed to be identified by the request-URI. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. Even if OPTIONS would be sent with a Content-Type header field, that field, by definition, would identify the internet media type of the request body. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Absolutely. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight? Unless I'm missing something here you are definitively trying to do the wrong thing. Best regards, Julian
Re: [cors] JAX-RS and preflight
On 2011-12-02 00:11, Benson Margulies wrote: Let me try to present this more clearly. First of all, I did not design or implement JAX-RS itself. The committee that designed it might have done something wrong in their dispatching approach. However, *I* am merely working on implementing a facility for the resource side of CORS in a JAX-RS framework. And I have to admit that I'm a member of that Expert Group. Apparently not paying sufficient attention, though. Perhaps it would be less disturbing if I characterized the situation as follows: JAX-RS dispatches the job of serving content at a smaller granularity than an HTTP/CORS 'resource'. It operates on the combination of resource+content-type+accepts+accepts-language. Varying the *response* based on Accept and Accept-Language is ok. It doesn't change the resource you're talking to, though. Content-Type really doesn't belong into this at all. All of those facts are available to a preflight except for the content type when the content-type is non-simple. That may be true, but doesn't affect what HTTP resource you're talking to. My humble request is for you to consider defining one more 'request' header for preflight: access-control-request-content-type -- that the client would send to the server on the OPTIONS command. There are many, many, services written with JAX-RS -- representing a classic case of that old standardization chestnut: 'existing practice.' What I'm proposing here would be trivial for client implementations, so I would think that the authors of the CORS proposal would at least grant this idea a full 5 minutes of thought before rejecting it. Please don't. It's totally the wrong thing to do here. If JAX-RS takes the position that the Content-Type on a request affects the resource being identified it totally needs to be fixed. ... Best regards, Julian
Re: CfC: publish WG Note of the old XHR(1); deadline December 8
On Thursday, 1 December 2011 at 19:25, Arthur Barstow wrote: Adrian proposed the old XHR(1) spec be published as a WG Note (to clearly state work on that spec has stopped) and this is a Call for Consensus to do so. I object to doing so. It will just cause more confusion. Please lets only have one XHR document (and not an additional Note). If everyone just sticks to the story (which is very logical), then there should be no need for confusion: it's not that hard to explain and it's the merger is in everyone's best interest.
Re: file sharing services
On Thu, Dec 1, 2011 at 1:51 PM, Charles Pritchard ch...@jumis.com wrote: There are serious security implications for enabling CORS, even with session-less requests. It's going to be a very long opt-in process for file sharing services. This is a very strong statement backed up by absolutely no information or data at all. Not very convincing. Please clarify what you are referring to. / Jonas
Re: [cors] JAX-RS and preflight
On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies bimargul...@gmail.com wrote: There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight? You can always allow the OPTIONS request and make the security decision once you get the actual request. The main point of the OPTIONS request is to protect servers that aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into this category. / Jonas
Re: file sharing services
On 12/1/11 3:48 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 1:51 PM, Charles Pritchardch...@jumis.com wrote: There are serious security implications for enabling CORS, even with session-less requests. It's going to be a very long opt-in process for file sharing services. This is a very strong statement backed up by absolutely no information or data at all. Not very convincing. Please clarify what you are referring to. Direct and anonymous read access is a very new thing. At it's most basic: UAs have always required a server, somewhere, to proxy anonymous requests. With direct access, items like IP-based security and auditing are not as reliable. It'd be very easy to do screen scraping on sites that don't particular want scraping to be done. While it's easy now, it has to be done from the server-side. When hosts open up their servers, they're allowing it to be done client-side. For my interests, I very much want img crossorigin=anonymous to work everywhere. Yehuda is simply asking for a change to the text, describing the implications of enabling CORS... That's fine. I'll comment on it when I see the text. -Charles
Re: [cors] JAX-RS and preflight
On Thu, Dec 1, 2011 at 6:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies bimargul...@gmail.com wrote: There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight? You can always allow the OPTIONS request and make the security decision once you get the actual request. Sure, if the server is the concerned party but The main point of the OPTIONS request is to protect servers that aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into this category. As a superannuated security person, I thought that the point of CORS was to protect clients from cross-scripting pranks of web pages, not to protect servers from anything. Nothing in CORS involves returning a 401. Wouldn't the actual access decision be made on the server instead of on the client if we were protecting the server? Why return all this stuff to the client instead of failing requests or censoring headers? Something tells me that there's a theory here that I haven't read yet. / Jonas
Re: file sharing services
On Thu, Dec 1, 2011 at 3:58 PM, Charles Pritchard ch...@jumis.com wrote: On 12/1/11 3:48 PM, Jonas Sicking wrote: On Thu, Dec 1, 2011 at 1:51 PM, Charles Pritchardch...@jumis.com wrote: There are serious security implications for enabling CORS, even with session-less requests. It's going to be a very long opt-in process for file sharing services. This is a very strong statement backed up by absolutely no information or data at all. Not very convincing. Please clarify what you are referring to. Direct and anonymous read access is a very new thing. At it's most basic: UAs have always required a server, somewhere, to proxy anonymous requests. With direct access, items like IP-based security and auditing are not as reliable. It'd be very easy to do screen scraping on sites that don't particular want scraping to be done. Please clarify what you mean by like IP-based security. It seems to me that it's *only* IP-based security that is affected. While it's easy now, it has to be done from the server-side. When hosts open up their servers, they're allowing it to be done client-side. How does it makes a difference that it can be done client-side rather than server-side? Beyond IP-based security that is. In other words, I can see that if you're deploying IP-based filters to attempt to make certain parties unable to scrape your website you'll have a harder time doing this if you're also sending a Access-Control-Allow-Origin: *. However you'd already signed up for a basically impossible task since it's very easy for a screen-scraper to proxy their requests through various parties around the globe in order to avoid IP-based filters. The one threat that I can see is if your website does IP-based authorization. I.e. automatically giving certain people access to private areas of your website if their request come from certain IP-numbers. But even then, I *think* sending Access-Control-Allow-Origin: * only allows for additional *reading* attacks. Requests that have side-effects can still be placed by faking which IP number they originate at. I'm not fully sure about this though. Someone that knows TCP/IP infrastructure better than me should confirm. Are these IP-based filters that you are referring to when you are saying serious security implications? Are they really common? I've never heard of sites doing that but I'm sure they exist. And to be even more on-topic, does Photobucket or Dropbox use IP-based filters to prevent read access? / Jonas
Re: [cors] JAX-RS and preflight
On Thu, Dec 1, 2011 at 4:14 PM, Benson Margulies bimargul...@gmail.com wrote: On Thu, Dec 1, 2011 at 6:53 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Dec 1, 2011 at 12:20 PM, Benson Margulies bimargul...@gmail.com wrote: There's a problem with REST-ful services, as exemplified by the JAX-RS standard, and CORS as drafted. A JAX-RS server names a resource, in part, via the content-type of a request. A POST with content-type of application/json names a different resource (in as much as it selects a different method to call) that a POST with content-type text/plain. The problem here is that a preflight OPTIONS is defined to *not* pass the content type unless it is simple. Thus, the service implementation can't reliably tell what resource is under discussion. As things are, a service would have to take a common posture for all preflights given the URL and Accept(-*) headers, and ignoring the content type. Would you consider defining an Ac-Request-Content-Type header to pass a non-simple content type on a preflight? You can always allow the OPTIONS request and make the security decision once you get the actual request. Sure, if the server is the concerned party but The main point of the OPTIONS request is to protect servers that aren't aware of CORS at all. Clearly a CORS+JAX-RS doesn't fall into this category. As a superannuated security person, I thought that the point of CORS was to protect clients from cross-scripting pranks of web pages, not to protect servers from anything. Nothing in CORS involves returning a 401. Wouldn't the actual access decision be made on the server instead of on the client if we were protecting the server? Why return all this stuff to the client instead of failing requests or censoring headers? Something tells me that there's a theory here that I haven't read yet. CORS isn't intended to fix cross-scripting pranks at all. At least if you are referring to the traditional meaning of XSS attacks. The intent of CORS is to allow websites to communicate with other servers without exposing existing web servers to new attack vectors. Specifically to CSRF-like attacks. So CORS is very much designed to protect (or rather not harm) servers. Not to do anything related to XSS. However, in allowing websites to talk to other servers in a safe manner, it removes the need to use script elements to do so. This use of script elements has traditionally opened up websites to XSS attack vectors. So while CORS isn't designed to protect against XSS attacks, it does obsolete XSS sensitive technology. I hope that makes sense? / Jonas
RE: [indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler
On Tuesday, November 22, 2011 5:30 PM, Israel Hilerio wrote: Subject: [indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler What should be the value of the error attribute on the open request after a VERSION_CHANGE transaction is aborted? We're thinking it should be AbortError independent of whether the transaction is aborted programmatically or due to a system failure. Do you guys agree? Israel Should I take the silence to mean we're in agreement :-) Israel
