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

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
https?

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