-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR Request for Mixed Content #193
Comments
cc @wseltzer |
Transition approved. Please update Section 6 to cite the replacement Fetch spec issue #235 and the WHATWG HTML LS section for Web Sockets. Also in that same section, RFC6455 has been updated; that citation should also be reviewed. I am wondering if some of the open issues (e.g. #18 and #23 are really still open; the threads seems to have been abandoned and the spec seems to have been changed such that those issues may be obsolete. |
This change has actually already been made in HTML. I'll drop the reference entirely.
The citation is still reasonable. RFC8441 updates it with an HTTP/2 variant, but still relies on the same underlying algorithm. RFC8307 defines some
I'll run through them again. |
friendly ping on this front. any help needed to publish? |
This fell off my radar. Will look into it tomorrow. |
Unless I'm mistaken, I believe this transition request has been abandoned. Feel free to re-open if needed. |
Document title, URLs, estimated publication date
Mixed Content Level 1
https://www.w3.org/TR/mixed-content/
Abstract
This specification describes how a user agent should handle fetching of content over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.
Status
"""
This document was published by the Web Application Security Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. This document will remain a Candidate Recommendation at least until 2 September 2016 in order to ensure the opportunity for wide review. Normative changes since the prior CR publication are: 1.
prefetch
was incorrectly listed as optionally-blockable; 2.block-all-mixed-content
reports; 3. There's an IANA registry now for CSP directives; and 4. We use "Is URL trustworthy?" rather than whitelisting "https" and "wss".The (archived) public mailing list [email protected] (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “mixed-content” in the subject, preferably like this: “[mixed-content] …summary of comment…”
Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implement all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. The Working Group will prepare an implementation report to track progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 September 2015 W3C Process Document.
The following features are at-risk, and may be dropped during the CR period:
The passthrough request concept, and the related carveout in the blocking algorithms.
“At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.
"""
Link to group's decision to request transition
w3c/webappsec-mixed-content#15
Changes
Requirements satisfied
No changes.
Dependencies met (or not)
No changes.
Wide Review
We've obtained substantially overlapping implementations in all major user agents, and had substantial engagement from folks across the board.
https://wpt.fyi/results/mixed-content?label=experimental&label=master&aligned
Issues addressed
https://github.com/w3c/webappsec-mixed-content/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+
Formal Objections
None.
Implementation
MIX1 is supported by default in all major user agents.
Patent disclosures
None.
The text was updated successfully, but these errors were encountered: