| Commit-Queue | +1 |
awillia@: PTAL overall
nidhijaju@: PTAL histograms.xml
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
stefanoduo@: FYI, as you've been touching DnsTransaction recently.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm
HttpConnectionInfoCoarseToString(info.connection_info);Maybe we should include "net/http/http_connection_info.h" for IWYU.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Returns the HTTP information for this attempt, if it was an HTTP attempt.
virtual std::optional<DnsHttpAttemptInfo> GetHttpAttemptInfo() const;What if we instead passed ResolveContext (or some higher-level abstraction) to DnsHttpAttempt? This would let it call RecordDohSessionStatus internally. Without having to leak, within DnsTransaction (other than at DnsAttempt creation time), whether a DnsAttempt is a DnsHttpAttempt or something else.
I'm worried that over time DnsAttempt would become a set of partially implemented methods, making it hard to figure out whether it's safe to call something.
// Returns the HTTP information for this attempt, if it was an HTTP attempt.
virtual std::optional<DnsHttpAttemptInfo> GetHttpAttemptInfo() const;What if we instead passed ResolveContext (or some higher-level abstraction) to DnsHttpAttempt? This would let it call RecordDohSessionStatus internally. Without having to leak, within DnsTransaction (other than at DnsAttempt creation time), whether a DnsAttempt is a DnsHttpAttempt or something else.
I'm worried that over time DnsAttempt would become a set of partially implemented methods, making it hard to figure out whether it's safe to call something.
Yeah I considered passing ResolveContext DnsAttempt at first, but I had a feeling that the original implementer explicitly intended to make DnsAttempt independent (unaware) of ResolveContext, so took this approach.
awillia@ gave me initial feedback and I plan to rework this CL so I'll consider this approach as well.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Returns the HTTP information for this attempt, if it was an HTTP attempt.
virtual std::optional<DnsHttpAttemptInfo> GetHttpAttemptInfo() const;Kenichi IshibashiWhat if we instead passed ResolveContext (or some higher-level abstraction) to DnsHttpAttempt? This would let it call RecordDohSessionStatus internally. Without having to leak, within DnsTransaction (other than at DnsAttempt creation time), whether a DnsAttempt is a DnsHttpAttempt or something else.
I'm worried that over time DnsAttempt would become a set of partially implemented methods, making it hard to figure out whether it's safe to call something.
Yeah I considered passing ResolveContext DnsAttempt at first, but I had a feeling that the original implementer explicitly intended to make DnsAttempt independent (unaware) of ResolveContext, so took this approach.
awillia@ gave me initial feedback and I plan to rework this CL so I'll consider this approach as well.
Changed to pass ResolveContext and DnsSession. Does this look better?
if (!is_probe_ && resolve_context_ && session_ &&
session_->config().secure_dns_mode == SecureDnsMode::kAutomatic) {awillia@: Does this look what you suggested?
Maybe we should include "net/http/http_connection_info.h" for IWYU.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |