Re: Do we need to rename the Origin header?
Ian Hickson wrote on 5/24/2010 7:55 PM: > On Mon, 24 May 2010, Bil Corry wrote: >> Adam Barth wrote on 7/16/2009 10:38 AM: >>> On Thu, Jul 16, 2009 at 8:47 AM, Bil Corry wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. >>> >>> I don't think we've quite settled on exactly what will be privacy >>> sensitive. It's most likely that POSTs and XHR will not be and that >>> hyperlinks and image loads will be. The goal is to harmonize with the >>> Mozilla proposal. >> >> I haven't been following the progress of this, has "privacy-sensitive" been >> defined in HTML5 yet? > > Yes. > > >> The only reference I could find was in "2.6 Fetching Resources": >> >> ---8<--- >> For the purposes of the Origin header, if the fetching algorithm was >> explicitly initiated from an origin, then the origin that initiated the HTTP >> request is origin. Otherwise, this is a request from a "privacy-sensitive" >> context. [ORIGIN] >> >> (from: >> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) >> --->8--- > > That is the definition. To clarify, the Origin header is sent for all requests now, except those that don't have an origin? The Origin header is sent for GET, POST, XHR, and CORS? - Bil
Re: [widgets] Zip vs GZip Tar
Hi, Folks- Sorry to jump in on this thread so late; I've been busy and traveling. As W3C Team Contact for this group, I strongly agree with Ian here regarding the tone of some of the responses. Technical comments on this list should be treated with the respect they are due. If you feel something has been adequately covered in the archives, point to an example email. Please keep this list civil, technical, and productive. On a logistical level, I again agree with Ian. I'm rather disappointed that we can't solve this problem more quickly. I think Gregg raised worthwhile use cases and points for consideration [1], and wonder if this might not be dealt with in the Widgets Embedding spec... after all, that is intended for the latter case he mentions. I can think of many worse things than having 2 alternate compression schemes, if the use cases are different. (Yes, I realize I'm speaking loosely and there might be serious technical problems with this approach... I'm just brainstorming here.) Aaron Boodman suggested something [2] on the WHATWG list that sounds suspiciously like Widgets, and it would be a real shame to miss out on this opportunity for increasing the applicability of the Widgets specs in multiple scenarios and platforms. [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0349.html [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026488.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Do we need to rename the Origin header?
On Mon, 24 May 2010, Bil Corry wrote: > Adam Barth wrote on 7/16/2009 10:38 AM: > > On Thu, Jul 16, 2009 at 8:47 AM, Bil Corry wrote: > >> I think you mean everything will NOT be privacy-sensitive except non-XHR > >> GETs. > > > > I don't think we've quite settled on exactly what will be privacy > > sensitive. It's most likely that POSTs and XHR will not be and that > > hyperlinks and image loads will be. The goal is to harmonize with the > > Mozilla proposal. > > I haven't been following the progress of this, has "privacy-sensitive" been > defined in HTML5 yet? Yes. > The only reference I could find was in "2.6 Fetching Resources": > > ---8<--- > For the purposes of the Origin header, if the fetching algorithm was > explicitly initiated from an origin, then the origin that initiated the HTTP > request is origin. Otherwise, this is a request from a "privacy-sensitive" > context. [ORIGIN] > > (from: > http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) > --->8--- That is the definition. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [IndexedDB] [Bug 9562] New: Opening a database with a different description is underspecified
On 4/20/2010 11:46 AM, bugzi...@jessica.w3.org wrote: The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update the description. Does anybody else have thoughts on what the right behavior should be here? Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Mon, May 24, 2010 at 1:21 PM, Jonas Sicking wrote:
> As for the keyPath issue. The way the spec stands now (where I think
> it intends not to allow full expressions), I don't think it really
> depends on Javascript. It does depend on the language having some way
> to represent structured data. I.e. that the language can hold
> something like:
>
> { foo: "bar",
> complex: { p1: "hello", p2: "world"} }
>
> I'm not really sure how you would return a value like that to
> Objective-C. How does WebKit intend to deal with that in APIs where
> this issue already exist, such as postMessage?
Surely any language that has some way of dealing with JSON already has
an answer for this, correct?
~TJ
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Sat, May 22, 2010 at 3:58 AM, Jeremy Orlow wrote:
> On Fri, May 21, 2010 at 11:42 PM, wrote:
>>
>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9793
>>
>> Summary: Allow dates and floating point numbers in keys
>> Product: WebAppsWG
>> Version: unspecified
>> Platform: All
>> OS/Version: All
>> Status: NEW
>> Severity: normal
>> Priority: P2
>> Component: Indexed Database API
>> AssignedTo: nikunj.me...@oracle.com
>> ReportedBy: pablo.cas...@microsoft.com
>> QAContact: member-webapi-...@w3.org
>> CC: m...@w3.org, public-webapps@w3.org
>>
>>
>> Currently the spec requires the values referenced by the key path to be
>> integers or strings. I strongly believe that we should also allow dates
>> and
>> floating point numbers (am I missing any other important types?). While
>> dates
>> and floating point numbers alone are not good for a primary key, they are
>> important for non-unique indexes and as part of a composite key, allowing
>> for
>> things such as scanning in temporal order.
>>
>> This is the change I'd like to propose:
>>
>> Section "3.1.1 Keys" of the currently published draft reads:
>>
>> -
>> In order to efficiently retrieve records stored in an indexed database, a
>> user
>> agent needs to organize each record by its key. Conforming user agents
>> must
>> support the use of values of IDL data types [WEBIDL] DOMString and long as
>> well
>> as the value null as keys.
>>
>> For purposes of comparison, a DOMString key is always evaluated higher
>> than any
>> long key. Moreover, null always evaluates lower than any DOMString or long
>> key.
>> -
>>
>> New proposed text:
>>
>> -
>> In order to efficiently retrieve records stored in an indexed database, a
>> user
>> agent needs to organize each record by its key. Conforming user agents
>> must
>> support the use of values of IDL data types [WEBIDL] DOMString, long,
>> float,
>> and the Date JavaScript object
>
> We really need to decide, once and for all, whether or not IndexedDB is
> going to be tied to JavaScript or not. The two major reasons to do so are
> the lack of date in WebIDL and keyPath.
> KeyPath may be tricky to spec in a way that would work for any language
> without cutting out a lot of flexibility. In order to keep what we're
> speccing sane, it will probably need to be a pretty small subset of what's
> possible in JavaScript and thus even browsers will likely need to roll their
> own parser and such to support it. (If we do decide to depend on
> JavaScript, it should enable some really neat things with the keyPath as
> well.)
> The HTML spec defines its own date type, but does not specify sort order at
> all. I started a thread on this a bit ago (subject: "[IndexedDB/WebIDL]
> Dates + Sorting (WAS: Detailed comments for the current draft)") but it only
> got one response [3].
Note that a Date type for WebIDL doesn't really affect things a whole
lot for the interfaces in IndexedDB though. The relevant functions all
take 'any' as type though, so we'll still have to describe in prose
what types are permitted. I don't think this makes IndexedDB depend on
javascript though.
What WebIDL would need, and what has been discussed in the past, is
some type of "compound types". I.e. that you could specify that an
argument can be "a date, an integer, a float or a string".
As for the keyPath issue. The way the spec stands now (where I think
it intends not to allow full expressions), I don't think it really
depends on Javascript. It does depend on the language having some way
to represent structured data. I.e. that the language can hold
something like:
{ foo: "bar",
complex: { p1: "hello", p2: "world"} }
I'm not really sure how you would return a value like that to
Objective-C. How does WebKit intend to deal with that in APIs where
this issue already exist, such as postMessage?
/ Jonas
Re: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods
On Fri, May 21, 2010 at 6:59 PM, Kris Zyp wrote:
>> or to use something like
>>
>> put(record, {forbidOverwrite: true}); // don't overwrite
>> put(record, {onlyOverwrite: true}); // must overwrite/update
>> put(record, {}); or put(record); // can do either
>>
>> or some such.
>>
>> However ultimately I feel like this directive will be used often
>> enough that it makes sense to create explicit API for it. The
>> implementation overhead of separate functions is really not that
>> big, and I can't see any usage overhead?
>
> I am not too concerned about the implementation. But, as we been using
> this API in SSJS, we have been increasingly using a wrapper pattern,
> wrapping low-level stores with additional functionality that exposes
> the same API. Wrappers add functionality such as caching, data change
> notifications, extra validation, and so. The more methods that are
> exposed the more difficult it is wrap stores.
Couldn't you always simply call addOrModify (or whatever we'll end up
calling it)? Given that neither localStorage or WebSQLDatabase
supports 'forbid overwrite' inserts it seems like this should work?
> Don't assume that the API will only be consumed.
Definitely. The API is definitely intended to be consumable by
libraries. In fact, I suspect that will be the case more often than
not. I'm not really sure that I'm following how the proposed API is
library un-friendly?
/ Jonas
Re: Do we need to rename the Origin header?
Adam Barth wrote on 7/16/2009 10:38 AM: > On Thu, Jul 16, 2009 at 8:47 AM, Bil Corry wrote: >> I think you mean everything will NOT be privacy-sensitive except non-XHR >> GETs. > > I don't think we've quite settled on exactly what will be privacy > sensitive. It's most likely that POSTs and XHR will not be and that > hyperlinks and image loads will be. The goal is to harmonize with the > Mozilla proposal. I haven't been following the progress of this, has "privacy-sensitive" been defined in HTML5 yet? The only reference I could find was in "2.6 Fetching Resources": ---8<--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a "privacy-sensitive" context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) --->8--- - Bil
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On May 24, 2010, at 3:30 AM, Jeremy Orlow wrote: > On Sun, May 23, 2010 at 4:06 AM, Maciej Stachowiak wrote: > > On May 22, 2010, at 3:58 AM, Jeremy Orlow wrote: > > > Even though no one is currently considering implementing this outside of > > JavaScript land and even though it'll limit us some and making speccing > > harder, I think it'd be a mistake to depend on JavaScript. And, as far as > > I can tell, the whole point of WebIDL is to not depend on one single > > language. And I can't think of any others that do. > > WebKit exposes Web APIs as part of the native API for embedders, this > includes Objective-C and GObject bindings. There have also been suggestions > to add bindings for languages such as Python, Java or Ruby. I think > interfaces for Web platform APIs should remain language-agnostic to the > degree possible. > > For the date issue specifically, we should consider adding a Web IDL date > type which could map to JavaScript Date objects and potentially native date > types for other languages, and something language agnostic for ether > languages. > > Cameron/Sam would you be willing to add something like this to WebIDL? I > have no idea what the spec language would look like otherwise I'd draft up > some proposed text. I am happy to add language for a Date type. -Sam
RE: [cors] Simplify CORS Headers (ISSUE-89)
In IE, we only support Access-Control-Allow-Origin and combining with other values (albeit optional ones) that we don't support might be misleading. It also introduces some additional parsing that changes the behaviour from a simple comparison to a more complex parse and then compare. We wouldn't be able to drop support for the current header so we'd need to support both and have a precedence order for which wins if both headers are present with different values. It's unlikely we'd issue a patch for IE8 unless there was strong customer demand and even if we did, there's no guarantee that it would be installed so services would still need to send both headers. I'm not all that keen on changing the names at this point either. Adrian. On Friday, May 14, 2010 10:19 AM, Arthur Barstow wrote: > Simpler and/or shorter would indeed be good, although it may be too > late. > > Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue? > > -Art Barstow > > On May 13, 2010, at 3:39 AM, ext Maciej Stachowiak wrote: > > On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote: > >> I suggest we merge Access-Control-Allow-Origin, Access-Control- > >> Allow-Credentials, and Access-Control-Max-Age into a new header, > >> named CORS. The syntax of this new header would be: > >> > >> "CORS" : "credentials"? origin-value delta-seconds? > > I'm not that keen on changing the names, but if we do, I think > > "CORS" might be a bit mysterious by itself as a header name. Here's > > another set of naming suggestions, if we do go down the renaming > > path (which for the record I'd rather not): > > > > CORS ==> Allow-Access or Expose-Response > > CORS-Methods ==> Allow-Methods > > CORS-Headers ==> Allow-Headers (or Allow-Request-Headers) > > CORS-Preflight ==> can't think of a better name for this > > new header to expose more response headers ==> Expose-Headers (or > > Expose-Response-Headers) > > > > Regards, > > Maciej >
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Sun, May 23, 2010 at 4:06 AM, Maciej Stachowiak wrote: > > On May 22, 2010, at 3:58 AM, Jeremy Orlow wrote: > > > Even though no one is currently considering implementing this outside of > JavaScript land and even though it'll limit us some and making speccing > harder, I think it'd be a mistake to depend on JavaScript. And, as far as I > can tell, the whole point of WebIDL is to not depend on one single language. > And I can't think of any others that do. > > WebKit exposes Web APIs as part of the native API for embedders, this > includes Objective-C and GObject bindings. There have also been suggestions > to add bindings for languages such as Python, Java or Ruby. I think > interfaces for Web platform APIs should remain language-agnostic to the > degree possible. > > For the date issue specifically, we should consider adding a Web IDL date > type which could map to JavaScript Date objects and potentially native date > types for other languages, and something language agnostic for ether > languages. > Cameron/Sam would you be willing to add something like this to WebIDL? I have no idea what the spec language would look like otherwise I'd draft up some proposed text. J
