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

I would like to hear some feedback from implementers on what user interaction could be expected here.
This seems like it could just be a hard failure like the XHR spec says.

On 4/8/09 9:48 AM, "Thomas Roessler" <tlr@w3.org> wrote:

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>