Ping. :) With Mixed Content now at CR, it would be nice to have a clear path forward for a test suite. Is something like `.https.html` a reasonable solution, or is there another method you folks would prefer to persue? -mike -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Tue, Feb 24, 2015 at 12:14 PM, Mike West <mkwst@google.com> wrote: > In > https://lists.w3.org/Archives/Public/public-test-infra/2015JanMar/0000.html, > James noted that it is now possible to load subresources over HTTPS, which > is ever so excellent. That said, a number of features (Service Workers, > Mixed Content, etc) require the test itself to be run under HTTPS. I'd like > to start putting together test suites for some WebAppSec specs, but that's > proving to be a difficult task. > > In Blink, we've settled on a "*.https.html" naming convention for such > tests which ensures that our test runner opens the test over HTTPS. That > is, any test with `.https.` in the filename will point to an HTTPS URL, and > not to an HTTP URL. Would such a system work for web-platform-tests? > > Note that we don't have a ton of such tests in Blink, so I'm happy to > change our behavior to align with whatever works for WPT and other user > agents. The filename-based solution is pretty simple and straightforward, > but we're flexible. :) > > -- > Mike West <mkwst@google.com>, @mikewest > > Google Germany GmbH, Dienerstrasse 12, 80331 München, > Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der > Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth > Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) >Received on Thursday, 26 March 2015 12:49:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:11 UTC