Bugzilla

Currently, during connection establishment, we wait for HTTPS RR in two places:

nsHttpChannel: This code path is triggered only for plain HTTP loads and is used for HTTPS upgrades.
nsHttpTransaction: This is used for ECH.
Unfortunately, this implementation causes some performance regression when HTTPS RR queries are made via the native resolver.

To mitigate this regression, we have a few options:

1. Not waiting if DoH is disabled.
2. As suggested in spec 5.1, we could check if we already have A/AAAA responses. If yes, we don't wait for HTTPS RR.
3. Implement an HTTPS RR cache similar to the Alt-Svc cache.
I believe option 2 is a MUST to do. If we choose option 1, we can avoid implementing option 3. Otherwise, we might need to implement option 3, but it is a bit more complicated.

Valentin, what do you think?
Thanks.

Currently, during connection establishment, we wait for HTTPS RR in two places:

[nsHttpChannel](https://searchfox.org/mozilla-central/rev/55944eaee1e358b5443eaedc8adcd37e3fd23fd3/netwerk/protocol/http/nsHttpChannel.cpp#666): This code path is triggered only for plain HTTP loads and is used for HTTPS upgrades.
[nsHttpTransaction](https://searchfox.org/mozilla-central/rev/55944eaee1e358b5443eaedc8adcd37e3fd23fd3/netwerk/protocol/http/nsHttpTransaction.cpp#380): This is used for ECH.
Unfortunately, this implementation causes some performance regression when HTTPS RR queries are made via the native resolver.

To mitigate this regression, we have a few options:

1. Not waiting if DoH is disabled.
2. As suggested in [spec 5.1](https://datatracker.ietf.org/doc/html/rfc9460#section-5.1), we could check if we already have A/AAAA responses. If yes, we don't wait for HTTPS RR.
3. Implement an HTTPS RR cache similar to the Alt-Svc cache.
I believe option 2 is a MUST to do. If we choose option 1, we can avoid implementing option 3. Otherwise, we might need to implement option 3, but it is a bit more complicated.

Valentin, what do you think?
Thanks.