Re: ACTION-575: behavior of current spec for dependent content

Reducing 8.7? There's an 8.7? Where should I be looking? Since you 
reference the editors draft, I thought you were talking about:

http://www.w3.org/2006/WSC/drafts/rec/rewrite.html

I like the text; I would support that change. As I imagine a new 8.7 :-)

          Mez





From:
Thomas Roessler <tlr@w3.org>
To:
Thomas Roessler <tlr@w3.org>
Cc:
WSC WG public <public-wsc-wg@w3.org>
Date:
04/08/2009 12:48 PM
Subject:
Re: ACTION-575: behavior of current spec for dependent content
Sent by:
public-wsc-wg-request@w3.org



Checking the XMLHttpRequest Level 2 spec (editor's draft)...

  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#initiating-a-request

... that specification actually covers the TLS error case in the same way 
as XMLHttpRequest for same-origin requests.  I.e., it's deemed a hard 
error and left for the application to deal with.

That suggests that some of my proposed section 8.7 is getting things 
wrong.  Unfortunately, though, the relevant changes are only in editor's 
drafts and not even in published working drafts, so the relevant behavior 
is a bit uncertain.

I propose reducing 8.7 to the first paragraph, and then noticing that the 
we expect the XHR specs to go for the "it's a hard error, leave it to the 
application" choice.

<p>For HTTPS requests caused using the XMLHttpRequest API <bibref 
ref="ref-XHR"/> <bibref ref="ref-XHRl2"/>, this specification permits 
either handling the error situation as a network error (and leaving 
behavior to the Web application in question) or causing a user 
interaction.  It is expected that upcoming specifications for the 
XMLHttpRequest API will opt for the former choice.</p>
 
Thoughts?

(I'm not quite committing this to CVS yet.)
--
Thomas Roessler, W3C  <tlr@w3.org>







On 8 Apr 2009, at 18:24, Thomas Roessler wrote:

On today's call, we were talking about a Web site (say, 
http://a.example.com/) that includes an image tag pointing elsewhere (say, 
https://b.example.com/).  Assume that b.example.com actually has a problem 
with its certificate.

The action I took was to have a careful look at section 5.4.1 and see what 
happens in this case.  The section is framed in terms of "HTTP 
connections" (not the cleanest wording), and on its face applies to both 
top-level resources and anything dependent.

That suggests that we might fixes along the following lines:

1. Rephrase from "HTTP connection" to "HTTP transaction".

2. At the very least suggest that user agents MAY also choose to not 
interact at all and treat the error condition as if it was a network error 
-- this change is actually needed to accommodate the behavior that we 
negotiated with Webapps concerning same-origin XMLHttpRequests.

I would actually lean toward saying that they SHOULD go down the network 
error path for dependent resources, but would want implementor feed-back 
before taking that change into account.

As a memo to myself, when we come to changes here, it might be worthwhile 
to revisit the newly added security consideration in 8.7.

Cheers,
--
Thomas Roessler, W3C  <tlr@w3.org>