ooni-probe-cli/internal/measurex/tracing.go

94 lines
3.0 KiB
Go
Raw Normal View History

package measurex
import (
"net/http"
"net/url"
"time"
"github.com/ooni/probe-cli/v3/internal/model"
"github.com/ooni/probe-cli/v3/internal/netxlite"
)
// NewTracingHTTPTransport creates a new HTTPTransport
// instance with events tracing.
//
// Arguments:
//
// - logger is the logger to use
//
// - begin is the zero time for measurements
//
// - db is the DB in which to write events that will
// eventually become the measurement
//
// - dialer is the base dialer to establish conns
//
// - resolver is the underlying resolver to use
//
// - handshake is the TLS handshaker to use
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
//
// - maxBodySnapshotSize is the max size of the response body snapshot
// to save: we'll truncate bodies larger than that.
func NewTracingHTTPTransport(logger model.Logger, begin time.Time, db WritableDB,
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
resolver model.Resolver, dialer model.Dialer, handshaker model.TLSHandshaker,
maxBodySnapshotSize int64) *HTTPTransportDB {
resolver = WrapResolver(begin, db, resolver)
dialer = netxlite.WrapDialer(logger, resolver, WrapDialer(begin, db, dialer))
tlsDialer := netxlite.NewTLSDialer(dialer, handshaker)
return WrapHTTPTransport(
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
begin, db, netxlite.NewHTTPTransport(logger, dialer, tlsDialer),
maxBodySnapshotSize)
}
// NewTracingHTTPTransportWithDefaultSettings creates a new
// HTTP transport with tracing capabilities and default settings.
//
// Arguments:
//
// - begin is the zero time for measurements
//
// - logger is the logger to use
//
// - db is the DB in which to write events that will
// eventually become the measurement
func NewTracingHTTPTransportWithDefaultSettings(
begin time.Time, logger model.Logger, db WritableDB) *HTTPTransportDB {
return NewTracingHTTPTransport(logger, begin, db,
netxlite.NewStdlibResolver(logger),
netxlite.NewDialerWithoutResolver(logger),
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
netxlite.NewTLSHandshakerStdlib(logger),
DefaultHTTPMaxBodySnapshotSize)
}
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
// NewTracingHTTPTransportWithDefaultSettings creates a new
// HTTP transport with tracing capabilities and default settings.
//
// Arguments:
//
// - db is the DB in which to write events that will
// eventually become the measurement
func (mx *Measurer) NewTracingHTTPTransportWithDefaultSettings(db WritableDB) *HTTPTransportDB {
return NewTracingHTTPTransport(
mx.Logger, mx.Begin, db, mx.NewResolverSystem(db, mx.Logger),
mx.NewDialerWithoutResolver(db, mx.Logger),
refactor(measurex): allow to configure timeouts and max-snapshot-size (#645) This diff lightly refactors the code in measurex to allow a user to configure all possible timeouts and the max-snapshot-size. There is currently a little bit of tension between setting timeouts inside of measurex and the watchdog timeouts inside of netxlite. This tension has been documented. Let us repeat the issue also in this commit message. If you are using a masurex.Measurer configured with very large timeouts and the underlying netxlite implementation uses shorter whatchdog timeouts, then you are going to see shorter than expected timeouts. Ideally, we would like to have just a single timeout but there is no way to ask the context "hey, can you tell me if you already have a configured timeout?". It may be that the right solution is to modify netxlite to have some sort of root/library object with this configuration. If that's the case, then a Measurer could be refactored as follows: - create the underlying netxlite "library" - initialize the timeouts desired by the Measurer - create a Dialer, of whatever is needed - use it Now this is not possible because netxlite timeouts are internal static settings rather than attributes of a structure. Anyway, for now I'm happy with this just being documented. (I suspect this issue will need to be addresses when we'll write unit tests for measurex; at that time a proper solution should come out naturally due to the unit tests constraints.) I'm working on this refactoring, BTW, to facilitate rewriting `tor` using measurex (see https://github.com/ooni/probe/issues/1688).
2022-01-04 13:20:48 +01:00
mx.TLSHandshaker, mx.httpMaxBodySnapshotSize())
}
// UnmeasuredHTTPEndpoints returns the endpoints whose IP address
// has been resolved but for which we don't have any measurement
// inside of the given database. The returned list will be
// empty if there is no such endpoint in the DB. This function will
// return an error if the URL is not valid or not HTTP/HTTPS.
func UnmeasuredHTTPEndpoints(db *MeasurementDB, URL string,
headers http.Header) ([]*HTTPEndpoint, error) {
parsedURL, err := url.Parse(URL)
if err != nil {
return nil, err
}
m := &DNSMeasurement{
Domain: parsedURL.Hostname(),
Measurement: db.AsMeasurement(),
}
return AllHTTPEndpointsForURL(parsedURL, headers, m)
}