- 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