Re: [WARP] error in spec
On Fri, Jun 3, 2011 at 12:39 PM, Arthur Barstow wrote: > Hi Marcos - given this spec is in the Candidate Recommendation state, before > a CfC to publish a new LCWD is started, I think it would be helpful if you > provided a list of the changes you propose and a short summary for each > change. WDYT? > > I don't have a strong opinion on where the list of changes is documented but > I think you previously included change lists in the spec itself and that > would be fine here too. I've asked Philippe to add a couple of widgets components in the Bugzilla as I would like to start tracking the changes requests and other issues there. -- Marcos Caceres http://datadriven.com.au
[widgets] WARP summary of issues, was Re: [WARP] error in spec
On 6/3/11 1:39 PM, Arthur Barstow wrote: Hi Marcos - given this spec is in the Candidate Recommendation state, before a CfC to publish a new LCWD is started, I think it would be helpful if you provided a list of the changes you propose and a short summary for each change. WDYT? I don't have a strong opinion on where the list of changes is documented but I think you previously included change lists in the spec itself and that would be fine here too. ISSUE 1: Blocking is undefined. The spec says: ""At runtime, when a network request is made from within the widget execution scope, the user agent matches it against the rules defined above, accepting it if it matches and blocking it if it doesn't.""" THE PROBLEM: blocking is undefined (which has lead to interop issues). SOLUTION: The user agent MUST behave as if the resource was unreachable (i.e., as if a invalid http address had been given or a 4XX or 5XX had been returned). This should cause, for example, HTML's elements to fire "error" when they try to load. For XHR, I think it's fine for a user agent to throw the SECURITY_ERR. This should be a RECOMMENDATION for user agents that implement XHR. === ISSUE 2: WARP is too strict PROBLEM: WARP rejects URLs too aggressively. It should be more liberal in what it excepts. SOLUTION: Parse URLs and just extract the useful bits (scheme, host, port). Discard the rest (path, iuserinfo, etc). ISSUE 3: subdomains attribute is not parsed consistently PROBLEM: subdomains attribute is not parsed the same way as other Boolean attributes defined in P&C. It should not reject the whole access request when the value is wrong. SOLUTION: If subdomains is in error, then ignore it (and default to false). Don't reject the whole tag because of it.
Re: [WARP] error in spec
Hi Marcos - given this spec is in the Candidate Recommendation state, before a CfC to publish a new LCWD is started, I think it would be helpful if you provided a list of the changes you propose and a short summary for each change. WDYT? I don't have a strong opinion on where the list of changes is documented but I think you previously included change lists in the spec itself and that would be fine here too. -AB On Jun/2/2011 11:24 AM, ext Marcos Caceres wrote: On 6/2/11 5:13 PM, Marcos Caceres wrote: On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres wrote: Quote from WARP: """ Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. """ subdomains has a default value of false so why is ignoring the complete element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. Proposed fix: [[ 5. If the subdomins attribute is absent, then let sub domains be the value false. Otherwise, or let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. 6. If the value of sub domains is not a valid boolean value, then let sub domains be the value false. ]] I've put that into the editor's draft. I call to republish the spec with the correction ASAP. Kind regards, Marcos
Re: [WARP] error in spec
On 6/2/11 5:13 PM, Marcos Caceres wrote: On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres wrote: Quote from WARP: """ Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. """ subdomains has a default value of false so why is ignoring the complete element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. Proposed fix: [[ 5. If the subdomins attribute is absent, then let sub domains be the value false. Otherwise, or let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. 6. If the value of sub domains is not a valid boolean value, then let sub domains be the value false. ]] I've put that into the editor's draft. I call to republish the spec with the correction ASAP. Kind regards, Marcos
Re: [WARP] error in spec
On Thu, Jun 2, 2011 at 9:26 AM, Marcos Caceres wrote: > Quote from WARP: > > """ > Let sub domains be the result of applying the rule for getting a > single attribute value to the value of the subdomains attribute. If > the value of sub domains is not a valid boolean value, then this > element is in error and the user agent MUST ignore this element. > """ > > subdomains has a default value of false so why is ignoring the > complete element needed? If only the subdomains is to be > ignored, then the steps for processing the config.xml need to be > changed to include the default value. > I've removed the following two tests from the test suite until we get this resolved: # ic (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. # id (download, files) Tests that the UA ignores an access element with an invalid subdomains value. To pass, the remote script must NOT load and PASS must remain displayed. -- Marcos Caceres http://datadriven.com.au
[WARP] error in spec
Quote from WARP: """ Let sub domains be the result of applying the rule for getting a single attribute value to the value of the subdomains attribute. If the value of sub domains is not a valid boolean value, then this element is in error and the user agent MUST ignore this element. """ subdomains has a default value of false so why is ignoring the complete element needed? If only the subdomains is to be ignored, then the steps for processing the config.xml need to be changed to include the default value. -- Marcos Caceres http://datadriven.com.au
