[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
I'm taking a back-channel discussion on-list per Anne's suggestion. We are trying to clarify some text in section 4.6.1, The open() method which is meant to describe how an XMLHttpRequest instance is associated with a specific document. (This association is important for origin checks, security etc.) The current text says: Let *document* be the document associated with the global object for which the XMLHttpRequest interface object was created from which this XMLHttpRequest object was created. This is quite convoluted, but precise. The last object could perhaps be instance to make it clearer? However, my proposal is to move this text to the constructor section (4.2 Constructors), for example as a new 3rd step in the first numbered list, and simplify it to read: Let document be the document associated with the global object of the XMLHttpRequest interface object. Anne responded: You cannot just move it to the constructor without introducing some other XHR-wide variable. Sorry Anne, you could probably edit the XHR spec asleep but however obvious it may be to you, I need some more details here ;). We're defining an instance variable called *document* and discussing whether we should define it when the instance is constructed or when the open() method is called. I don't understand what state we would need another XHR-wide variable to track if we move it. As far as I can tell, nothing can be done after constructing an instance but before calling open() that would require *document* to be unset, or require knowing if it is set or not. But yes, there's an open issue about whether we should maybe do that. I'd prefer discussion on a public list. Hereby implemented, Sir ;-) I also believe the implementation difference can not be observed from JS. Not if you make the same requirements, no... I believe both the old text and the proposal would end up with *document* referencing the same document, even in corner cases. If I'm missing something please explain, thanks. (Just for the record, the corner cases we need to consider here include stuff like var xhr=new iframe.contentWindow.XMLHttpRequest() XMLHttpRequest.prototype.open.call(xhr, ...) iframe.contentWindow.XMLHttpRequest.prototype.open.call( xhr=new XMLHttpRequest, ... ) and possibly other weirdness. The spec needs to dictate a consistent and compatible way to reference the correct document..) -- Hallvord R. M. Steen Core tester, Opera Software
Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 12:34 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: This is quite convoluted, but precise. The last object could perhaps be instance to make it clearer? However, my proposal is to move this text to the constructor section (4.2 Constructors), for example as a new 3rd step in the first numbered list, and simplify it to read: Let document be the document associated with the global object of the XMLHttpRequest interface object. You'd also need to check the JavaScript global environment. Anne responded: You cannot just move it to the constructor without introducing some other XHR-wide variable. Sorry Anne, you could probably edit the XHR spec asleep... What I mean is that var-variables are scoped to the algorithm they are used in. So you need to re-introduce dfn title=concept-XMLHttpRequest-documentdocument/dfn or some such. I also believe the implementation difference can not be observed from JS. Not if you make the same requirements, no... I believe both the old text and the proposal would end up with *document* referencing the same document, even in corner cases. If I'm missing something please explain, thanks. My comment meant to indicate that if you move requirements around you will not have a difference. However, if you remove requirements as done in http://dvcs.w3.org/hg/xhr/rev/fe301b5c5917 (later reverted) you will. (Just for the record, the corner cases we need to consider here include stuff like var xhr=new iframe.contentWindow.XMLHttpRequest() This is not a corner case in actual content. If it was we would made it work the same way it does in Workers. -- http://annevankesteren.nl/
CfC: publish WD of XHR; deadline November 29
TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) 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 reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB
Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
Let document be the document associated with the global object of the XMLHttpRequest interface object. You'd also need to check the JavaScript global environment. Thanks for responding. How? What I mean is that var-variables are scoped to the algorithm they are used in. So you need to re-introduce dfn title=concept-XMLHttpRequest-documentdocument/dfn or some such. Ah, OK. We already have an instance property named referrer source, which is a somewhat obscure name but does reference the document. Can we just re-name referrer source = associated document or something, and set it in constructor, then use it for the not fully active check etc in open() ? (Naming it referrer source re-uses terminology from CORS or Workers? I believe it will always refer to a document - in web worker mode the document associated with the script - and we can say use associated document as *override referrer source* when referencing CORS algorithm. IMO this is easier to understand in the context of this spec.) (Just for the record, the corner cases we need to consider here include stuff like var xhr=new iframe.contentWindow.XMLHttpRequest() This is not a corner case in actual content. If it was we would made it work the same way it does in Workers. The precise definition of corner case is a hair I have no intention of helping you split :-) -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 2:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: You'd also need to check the JavaScript global environment. Thanks for responding. How? Just like the spec does now? What I mean is that var-variables are scoped to the algorithm they are used in. So you need to re-introduce dfn title=concept-XMLHttpRequest-documentdocument/dfn or some such. Ah, OK. We already have an instance property named referrer source, which is a somewhat obscure name but does reference the document. Can we just re-name referrer source = associated document or something, and set it in constructor, then use it for the not fully active check etc in open() ? No, see below. (Naming it referrer source re-uses terminology from CORS or Workers? I believe it will always refer to a document - in web worker mode the document associated with the script - and we can say use associated document as *override referrer source* when referencing CORS algorithm. IMO this is easier to understand in the context of this spec.) Referrer source is from HTML and can be a URL. I prefer to keep that name consistent throughout all specifications. -- http://annevankesteren.nl/
Re: CfC: publish WD of XHR; deadline November 29
If you have any comments or concerns about this proposal, please reply to this e-mail by December 29 at the latest. Putting my name as former editor while all the text is either written by me or copied from me seems disingenuous. -- http://annevankesteren.nl/
Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1
On Thu, Nov 22, 2012 at 2:25 PM, Anne van Kesteren ann...@annevk.nl wrote: [...] It seemed easier to just make the change: https://github.com/whatwg/xhr/commit/67244d007243de427ffe8367ed0a7c49d40be199 -- http://annevankesteren.nl/
Re: CfC: publish WD of XHR; deadline November 29
On Thu, 22 Nov 2012 14:04:54 +0100, Tobie Langel to...@fb.com wrote: On 11/22/12 2:01 PM, Arthur Barstow art.bars...@nokia.com wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so ... Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. +1 Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
[Bug 20045] New: data: URLs, HTTP, and parsing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20045 Bug ID: 20045 Summary: data: URLs, HTTP, and parsing Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: ann...@annevk.nl QA Contact: public-webapps-bugzi...@w3.org CC: julian.resc...@gmx.de, m...@w3.org, public-webapps@w3.org data: URLs almost always successfully parse per the URL parser, but the URL processing step can go wrong. Maybe if that goes wrong it should be a 400 Bad Request? Or maybe 500 Internal Server Error? So e.g. data:test parses fine as a URL, but does not parse fine as a data: URL. -- You are receiving this mail because: You are on the CC list for the bug.
Re: CfC: publish WD of XHR; deadline November 29
On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) 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 reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. Ms2ger
Re: CfC: publish WD of XHR; deadline November 29
On Thu, Nov 22, 2012 at 9:16 AM, Ms2ger ms2...@gmail.com wrote: On 11/22/2012 02:01 PM, Arthur Barstow wrote: TheXHR Editors would like to publish a new WD of XHR and this is a Call for Consensus to do so using the following ED (not yet using the WD template) 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 reply to this e-mail by December 29 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. I agree. The W3C should not be in the business of plagiarizing the work of others. plagiarism. n. The practice of taking someone else's work or ideas and passing them off as one's own. The Status of this Document section should state clearly that this document is not an original work of authorship of the W3C. Instead, the document should clearly state that it is based in part (or in whole) on the WHATWG version. I don't have a problem with the W3C attaching its copyright and license to the document. I do have a problem with plagiarism. Adam
