- From: Mary Ellen Zurko <mzurko@us.ibm.com>
- Date: Fri, 10 Apr 2009 15:01:30 -0400
- To: "Thomas Roessler <tlr" <tlr@w3.org>
- Cc: WSC WG public <public-wsc-wg@w3.org>
- Message-ID: <OF001C7073.9D3B0A33-ON85257594.00687CEB-85257594.0068932E@LocalDomain>
Thanks. Is it possible to construct a quick test case so we as a team could easily check what the various browsers do? Yngve and Jan Vidar, what does Opera do? Ian, Chrome? Johnath, FF? Mez From: Thomas Roessler <tlr@w3.org> To: WSC WG public <public-wsc-wg@w3.org> Date: 04/08/2009 12:24 PM Subject: ACTION-575: behavior of current spec for dependent content Sent by: public-wsc-wg-request@w3.org 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>
Received on Friday, 10 April 2009 19:02:59 UTC