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

8.7 isn't in the HTML version of the editor's draft quite yet, but the  
current text is here:

   http://lists.w3.org/Archives/Public/public-wsc-wg/2009Apr/0000.html

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







On 10 Apr 2009, at 21:05, Mary Ellen Zurko wrote:

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