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

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>
>
>
>
>
>
>
>