1368459 - Point Telemetry tests to a valid/working HTTPS dummy server

Status: NEW

(Toolkit :: Telemetry, enhancement, P3)

Description

[Alessio Placitelli [:Dexter]]

In bug 1364068 we found that making Telemetry send pings to "https://%(server)s/dummy/telemetry/" is not a good idea.

That address translates to "https://127.0.0.1:8888/dummy/telemetry/" in mochitests. Trying to open it during the tests (either with a POST or a GET), results in a never-ending TLS handshake which eventually makes the pingsender timeout after a while.

This slows down the tests, making them fail if the pingsender is enabled in mochitests: for this reason, the pingsender is not being enabled in that test suite.

We can fix this by properly configuring an HTTPS end-point in the server locations permitted and setup by test harness:

- We should add a new server location at the end of [1], e.g. "https://telemetry-dummy-ingestion.com:443"
- Regenerate the certificates as explained in [2]
- Change all test prefs pointing at the failing https server to the newly configured one
- Make sure that nothing blows up on try :-D

[1] - http://searchfox.org/mozilla-central/source/build/pgo/server-locations.txt
[2] - http://searchfox.org/mozilla-central/source/build/pgo/certs/README
[3] - https://dxr.mozilla.org/mozilla-central/search?q=toolkit.telemetry.server&redirect=false

Comment 1

[Alessio Placitelli [:Dexter]]

(In reply to Alessio Placitelli [:Dexter] from bug 1364068 comment #36)
> After investigating the new backout, we found that the problem is the
> pingsender timing out due to trying to connect to a misconfigured SSL server
> in the test harness:
> 
> - the pingsender waits 5 minutes before timing out;
> - the test framework waits for all the processes to complete before shutting
> down (including the pingsender);
> - if the test framework gets stuck, it kills the processes and triggers an
> error (the ones we're seeing in comment 32).

Ted, is the procedure from comment 0 the right way to have a properly-behaving dummy HTTPS server in our test harness?
We only care about it returning 200 to all our requests, to fix the problem quoted above.

Are you the right person to answer this question? Anyway, thanks for your help :-)

Comment 2

[(not currently active) Ted Mielczarek]

Yes, that's correct. However, if you don't care what the exact hostname is you can save yourself the trouble of regenerating the certs if you just use one of the existing hostnames in server-locations.txt. Any https server listed there that doesn't also have an annotation containing 'cert' should be safe to use. (Those are used for testing specific SSL configurations.)

Comment 3

[Alessio Placitelli [:Dexter]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2)
> Yes, that's correct. However, if you don't care what the exact hostname is
> you can save yourself the trouble of regenerating the certs if you just use
> one of the existing hostnames in server-locations.txt. Any https server
> listed there that doesn't also have an annotation containing 'cert' should
> be safe to use. (Those are used for testing specific SSL configurations.)

Great! I don't think I need to pick a new name, so even better.

There's one last tweak I'd need to take care of though: is there any way to always return 200 from one of these hosts regardless of the resource we try to access?

For example, accessing https://www.example.com/ correctly returns 200 but https://www.example.com/test/some/things returns 404 (and I'd love this to return 200).

Comment 4

[(not currently active) Ted Mielczarek]

Not currently, but I think that should be easy to add to server.js using registerPrefixHandler:
https://dxr.mozilla.org/mozilla-central/rev/5801aa478de12a62b2b2982659e787fcc4268d67/netwerk/test/httpserver/nsIHttpServer.idl#89

It looks like we actually use that in some telemetry xpcshell tests:
https://dxr.mozilla.org/mozilla-central/rev/5801aa478de12a62b2b2982659e787fcc4268d67/toolkit/components/telemetry/tests/unit/head.js#54

You'd want to add the handler here:
https://dxr.mozilla.org/mozilla-central/rev/5801aa478de12a62b2b2982659e787fcc4268d67/testing/mochitest/server.js#211

Comment 5

[Georg Fritzsche [:gfritzsche]]

Lets circle back to this after SF.