W3C home > Mailing lists > Public > public-test-infra@w3.org > October to December 2014

Re: https/wss testing in web-platform-tests

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 13 Oct 2014 10:20:09 -0700
Message-ID: <CAEeYn8gpE8jFUjk3mpsmqZLP8ham5zi3CB170exs36Sv6MkiTA@mail.gmail.com>
To: James Graham <james@hoppipolla.co.uk>
Cc: public-test-infra <public-test-infra@w3.org>
Why would we not just always require an https endpoint to be running
if we're going to automatically generate a test certificate, anyway?
Why put the burden on test authors to mark every test that requires

On Thu, Oct 9, 2014 at 7:16 AM, James Graham <james@hoppipolla.co.uk> wrote:
> On 23/09/14 19:05, James Graham wrote:
>> This is, I think, the next important thing to work on since it is
>> required for testing a large number of things. It's also rather
>> complicated since real CAs can't let us do the things that would be
>> needed to let everyone run their own web-platform.test domain.
> So I have a working version of this locally. The next question is how to
> deal with the fact that in some setups running https tests will not be
> possible, but in other setups it will.
> Practically the main problem is that server ports are usually specified
> like:
> var server_ssl = "https://{{host}}:{{ports[https][0]}}/"
> If there is no https server running this currently throws because the
> https server doesn't have any associated ports. It would obviously be
> possible to make it do something different here, like have the template
> return the empty string, leading to nonsense like
> var ssl_server = "https://web-platform.test:/"
> after substitution. This would work OK in the sense that you could
> design tests around the assumption that this would happen, but it seems
> pretty unfriendly. It would also be possible to significantly increase
> the complexity of the template language and have conditional constructs
> like:
> {{#if len(ports[https])}}
> //ssl is enabled
> var server_ssl = "https://{{host}}:{{ports[https][0]}}/"
> {{#else}}
> var ssl_server = null;
> {{#endif}}
> An alternate strategy would be to require that all https tests and
> associated templating is put in files that aren't used in the non-https
> case. These top-level test files would have some metadata to indicate
> that they require https and wouldn't even be loaded in the non-https
> case e.g. <meta name=https content=true>.
> I'm not sure which option's better for test authors. The first allows
> more centralisation, but requires that you start all ssl-using tests
> with something like
> assert_not_equals(ssl_server, null);
> The second requires that you remember to put ssl metadata into the top
> of every test file and requires a strict separation between things that
> will will ssl and things that will not (such a strict separation doesn't
> currently exist).
> Is the a better option that I'm missing? Do people have a preferred
> solution?
Received on Monday, 13 October 2014 17:20:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:11 UTC