Re: [XHR] Status Update
On Tue, 10 Aug 2010 00:37:58 +0200, Maciej Stachowiak m...@apple.com wrote: On Aug 9, 2010, at 6:05 AM, Anne van Kesteren wrote: As a result of working on the test suite I found a few minor issues that would be nice to resolve (I'm not particularly interested in the solution to each of these problems, but I thought I would propose one in order to move things forward). I filed these bugs on them: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 I agree with this change. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10323 I'll have to think about this one. It does seem like a feature addition, and it's late in the game for that. It's not totally clear to me that responseXML is the best way to expose parsing of HTML documents, since there is no way to feature test for it. CR is probably too late to be adding features, especially when it's not 100% clear it is the right design. Fair enough. I'm generating XMLHttpRequest and XMLHttpRequest Level 2 from the same source document and was trying to get rid of some of the (in my view) unneeded differences with some of these comments. I'll mark this bug as WONTFIX. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10324 Agree, assuming there is no Web compatibility issue. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10325 Agree. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 How do implementations currently behave in this case? It seems most implementations actually allow it (commented in the bug). (I have not written tests for authorization yet.) But I believe Internet Explorer throws and per RFC 2616 it is not even part of http URLs. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10327 I'm not sure what the current proposal is here. I don't think a scheme whitelist is right. The current proposal is described in the last comment. Namely to allow everything (nothing is unsupported as far as open() is concerned) and let it be a network error in the request layer. (They will be cross-origin and not support CORS unless we really want them to work.) http://www.w3.org/Bugs/Public/show_bug.cgi?id=10328 Seems ok to me, if there is no compatibility issue. Not mentioning it at all is probably safest. Which of the changes above would require us to drop back to Working Draft and have another Last Call? Any of them, or just a subset? The one that changes conformance is not throwing for non same-origin URLs. That is also the most important. I do not think we can consider it just a bug fix but we could discuss it with the Director and see if it is ok. Relevant URLs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10322 http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change If we do have another Last Call, I would prefer to go to CR again and not short-circuit the process. I place more value on careful process than on getting to REC quickly. We could only go to PR if we met the CR requirements. Essentially you get a zero-day CR. If we actually have met the requirements (of which two fully compliant implementations will be the most tricky one) there is not much reason to issue a CR. I'm fine with doing it anyway though, but lets table this for then :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)
On 8/10/10 9:03 AM, gaut...@opera.com wrote: Quoting SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com: Marcos, You're saying if I understand you, that if I create an anchor: a href=http://mywidget.com;Click to load the online version/a That when the user clicks this link it will launch the browser, instead of retrieving the online version of my widget (or at least of this page of it)? This would in essence prevent the use of anchors anywhere in widgets, where the developer's intent was to have the web runtime retrieve and present the content directly, within the widget's context. For example, if I want to use an iframe to pull in some external content and then allow the user to navigate the content within the iframe - in your proposal the first link they hit in the iframe would take them out of the widget and into the browser. Not the desired experience IMO. Or do I misunderstand your proposal? Hi Bryan, inline content (iframe, img, etc.) inclusion is not affected by the proposal. It's perfectly fine to have the following... Opens in new window: a href=http://foo.com;foo/a a href=tel:+12312Call foo/a Relative link, open in widget context: a href=bar.htmlbar/a Embeds in page, if allowed by WARP: iframe src=http://foo.com;/iframe I think the proposal is missing explicit meaning for target=_self and _blank (something I'm sure Marcos has considered, maybe just not clarified.) a href=http://www.mywidget.com/;click here/a If the linked location is inside the widget package, or sms:/tel:/similar protocols that don't need a browsing context, I would expect: - it to load in target=_self (ie. the widget) Right. This is/would-be defined in HTML5. If the linked location is outside the widget package, I would expect: - it to load in target=_blank (ie. the browser) As above. If a specific rule must be followed, the developer must add target=_self or _blank depending on where the resource must be opened, for example. Loading a widget link from inside a widget, or for initiating a download - target=_self could be explicitly used. Marcos, please correct me if I'm reading too much into your proposal. You are reading it just fine; But your clarifications are outside the scope of the Widget Interface spec. -- Marcos Caceres Opera Software
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Thanks, Andrei
CfC: to publish new WD of Indexed Database API; deadline August 17
All - the Editors of the Indexed Database API would like to publish a new Working Draft: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If you have any comments or concerns about this proposal, please send them to public-webapps by August 10 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: CfC: to publish new WD of Indexed Database API; deadline August 17
On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.comwrote: All - the Editors of the Indexed Database API would like to publish a new Working Draft: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If you have any comments or concerns about this proposal, please send them to public-webapps by August 10 at the latest. I assume you mean the 17th? As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. We support.
Re: CfC: to publish new WD of Indexed Database API; deadline August 17
Yes, the deadline for comments is August 17! On 8/10/10 7:38 AM, ext Jeremy Orlow wrote: On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.com mailto:art.bars...@nokia.com wrote: All - the Editors of the Indexed Database API would like to publish a new Working Draft: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If you have any comments or concerns about this proposal, please send them to public-webapps by August 10 at the latest. I assume you mean the 17th? As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. We support.
Re: [xhr] RFC2617 Digest authentication
On Tue, 27 Jul 2010 16:32:48 +0200, Yrjänä Rankka gh...@openlinksw.com wrote: Please correct me if I'm wrong, but as I read the XHR level 2 draft, it seems impossible to do Digest auth with custom mechanism for acquiring the authentication credentials. I.e. supplying your own login dialog. To correctly digest authenticate, one needs to be challenged by the server first. To do that one needs to attempt to invoke a method on a resource without, or with invalid credentials. The resulting 401 Unauthorized reply then contains the challenge with nonce, opaque, etc. values required to produce correct reply. In order to inhibit the browser from prompting the credentials from user, one must define user, password in call to open() method. My observations show this will produce a basic Authenticate: header in the request thus leaking the user/password out in the open even though the server might refuse Basic auth. I believe some of the browsers wait to be challenged first, actually. That is what should happen per XMLHttpRequest. Many servers do and should refuse HTTP Basic auth over a non-encrypted connection. This is required by WebDAV [1], for example. Now it may be possible to trick some of the clients into Digest authentication without prompting the user by first calling open() with bogus user/password - then catching the 401 reply and on subsequent try call open() again with correct user/password values, hoping that the client cached the challenge. This would qualify as a hack, though, since AFAIK this behaviour is not prescribed by the Draft. I have no problem with rolling my own Digest authentication routines in the client but this would require a clean flag in the XHR to disable any attempt to do authentication on its behalf. Then again, another flag forcing the XHR to only authenticate when challenged, and then choose the strongest available method, as required by rfc2617 [2] would be preferable and would make it easier for developers to use a standard authentication method, reusing what's already implemented in most (modern) clients. We might add such a flag and a flag to control redirects in the future, but not for now. [1] http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1 [2] http://tools.ietf.org/html/rfc2617#section-4.6 -- Anne van Kesteren http://annevankesteren.nl/
Re: CfC: to publish new WD of Indexed Database API; deadline August 17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any chance #10304 could be resolved prior to the publishing? Seems like it would be nice to get a change to the core store API sooner rather than later. Either way, I am +1 for publishing though. Thanks, Kris On 8/10/2010 5:04 AM, Arthur Barstow wrote: All - the Editors of the Indexed Database API would like to publish a new Working Draft: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If you have any comments or concerns about this proposal, please send them to public-webapps by August 10 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 - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhVu4ACgkQ9VpNnHc4zAyHygCfU1nLMK8WLnG1FETtaOtbpLDn nxgAnAxoTdIwTx22NCJPrE5l9jeC4PJS =8p1i -END PGP SIGNATURE-
Re: [XHR] Status Update
On 09.08.2010 22:25, Anne van Kesteren wrote: On Mon, 09 Aug 2010 20:54:48 +0200, Jonas Sicking jo...@sicking.cc wrote: Some of these bugs are feature enhancements. Such as adding support for sending and receiving text/html documents. In the interest of getting us to rec as quickly as possible I suggest that these features are added to XHR L2 instead. Actually, by virtue of following the Document.innerHTML algorithm from HTML5 sending HTML documents is already covered for in XMLHttpRequest. It is just that the media type (as the bug indicates) is always set to application/xml rather than text/html for HTML documents. Receiving HTML documents would indeed be a newish feature, except that you already need to follow HTML5 rules to discover the character encoding for responseText, etc. so adding this did not seem like a big burden on implementations on top of which it makes sense that if you can send them (which was already possible) you can also receive them. ... I sure hope nobody follows HTML5 for the encoding detection :-). See http://www.w3.org/Bugs/Public/show_bug.cgi?id=9628, raised over three months ago. Best regards, Julian
Re: CfC: to publish new WD of Indexed Database API; deadline August 17
I support this. On Tue, Aug 10, 2010 at 4:38 AM, Jeremy Orlow jor...@google.com wrote: On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.com wrote: All - the Editors of the Indexed Database API would like to publish a new Working Draft: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If you have any comments or concerns about this proposal, please send them to public-webapps by August 10 at the latest. I assume you mean the 17th? As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. We support.
Re: [xhr] RFC2617 Digest authentication
On 8/10/10 15:34 , Anne van Kesteren wrote: On Tue, 27 Jul 2010 16:32:48 +0200, Yrjänä Rankka gh...@openlinksw.com wrote: Please correct me if I'm wrong, but as I read the XHR level 2 draft, it seems impossible to do Digest auth with custom mechanism for acquiring the authentication credentials. I.e. supplying your own login dialog. To correctly digest authenticate, one needs to be challenged by the server first. To do that one needs to attempt to invoke a method on a resource without, or with invalid credentials. The resulting 401 Unauthorized reply then contains the challenge with nonce, opaque, etc. values required to produce correct reply. In order to inhibit the browser from prompting the credentials from user, one must define user, password in call to open() method. My observations show this will produce a basic Authenticate: header in the request thus leaking the user/password out in the open even though the server might refuse Basic auth. I believe some of the browsers wait to be challenged first, actually. That is what should happen per XMLHttpRequest. Yep. Most seem to do this after all. I think what I was seeing was caused by the realm in question having previously presented a basic authenticate challenge only, and the browsers in question caching that info. Many servers do and should refuse HTTP Basic auth over a non-encrypted connection. This is required by WebDAV [1], for example. Now it may be possible to trick some of the clients into Digest authentication without prompting the user by first calling open() with bogus user/password - then catching the 401 reply and on subsequent try call open() again with correct user/password values, hoping that the client cached the challenge. This would qualify as a hack, though, since AFAIK this behaviour is not prescribed by the Draft. I have no problem with rolling my own Digest authentication routines in the client but this would require a clean flag in the XHR to disable any attempt to do authentication on its behalf. Then again, another flag forcing the XHR to only authenticate when challenged, and then choose the strongest available method, as required by rfc2617 [2] would be preferable and would make it easier for developers to use a standard authentication method, reusing what's already implemented in most (modern) clients. We might add such a flag and a flag to control redirects in the future, but not for now. Was worth a try anyway. For sure people shouldn't try and roll their own (often snake-oil -based) auth lightly. Would be great to be able to direct client to refuse BASIC auth over non-TLS wire altogether, though. Yrjänä [1] http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1 [2] http://tools.ietf.org/html/rfc2617#section-4.6 -- Yrjana Rankka| gh...@openlinksw.com Developer, Virtuoso Team | http://www.openlinksw.com | Making Technology Work For You
RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)
If the linked location is outside the widget package, it should not automatically load in the browser. We need the ability of widgets to download and present network-based content through means other than XHR or iframes. If my widget is designed to ingest and present content from external sources (declared as per WARP) within its context (and not just within an iframe), causing such external references to launch in the browser will prevent the intended operation of the widget. Thanks, Bryan Sullivan | ATT -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Tuesday, August 10, 2010 12:30 AM To: gaut...@opera.com; SULLIVAN, BRYAN L (ATTCINW) Cc: Web Applications Working Group WG Subject: Re: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group) On 8/10/10 9:03 AM, gaut...@opera.com wrote: Quoting SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com: Marcos, You're saying if I understand you, that if I create an anchor: a href=http://mywidget.com;Click to load the online version/a That when the user clicks this link it will launch the browser, instead of retrieving the online version of my widget (or at least of this page of it)? This would in essence prevent the use of anchors anywhere in widgets, where the developer's intent was to have the web runtime retrieve and present the content directly, within the widget's context. For example, if I want to use an iframe to pull in some external content and then allow the user to navigate the content within the iframe - in your proposal the first link they hit in the iframe would take them out of the widget and into the browser. Not the desired experience IMO. Or do I misunderstand your proposal? Hi Bryan, inline content (iframe, img, etc.) inclusion is not affected by the proposal. It's perfectly fine to have the following... Opens in new window: a href=http://foo.com;foo/a a href=tel:+12312Call foo/a Relative link, open in widget context: a href=bar.htmlbar/a Embeds in page, if allowed by WARP: iframe src=http://foo.com;/iframe I think the proposal is missing explicit meaning for target=_self and _blank (something I'm sure Marcos has considered, maybe just not clarified.) a href=http://www.mywidget.com/;click here/a If the linked location is inside the widget package, or sms:/tel:/similar protocols that don't need a browsing context, I would expect: - it to load in target=_self (ie. the widget) Right. This is/would-be defined in HTML5. If the linked location is outside the widget package, I would expect: - it to load in target=_blank (ie. the browser) As above. If a specific rule must be followed, the developer must add target=_self or _blank depending on where the resource must be opened, for example. Loading a widget link from inside a widget, or for initiating a download - target=_self could be explicitly used. Marcos, please correct me if I'm reading too much into your proposal. You are reading it just fine; But your clarifications are outside the scope of the Widget Interface spec. -- Marcos Caceres Opera Software
RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)
Quoting SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com: If the linked location is outside the widget package, it should not automatically load in the browser. I don't understand what you mean here? We need the ability of widgets to download and present network-based content through means other than XHR or iframes. What does this have to do with openURL? What do you need openURL to do that window.open can't do? or that a href= can't do? If my widget is designed to ingest and present content from external sources (declared as per WARP) within its context (and not just within an iframe), causing such external references to launch in the browser will prevent the intended operation of the widget. The proposal has no inpact on XHR. What does this have to do with openURL?
[Bug 10211] Remove the no host-specific component requirement for targetOrigin, see implementor discussion in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027136.html and subsequ
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10211 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||FIXED --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-11 01:11:15 --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. -- 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.
