Documentation
¶
Overview ¶
Package probetest builds the stub debug endpoints that RFC-0013's tests run against: a port that accepts and stalls, one that completes the WebSocket upgrade (now or later), and one with nothing listening at all.
It exists because the consent-pending state is exactly a TCP listener that accepts and says nothing, so every scenario in that RFC is reproducible with net.Listen and no browser — which matters more here than usual: reproducing the bug by hand wedged a real user's Chrome twice, and a regression test that needs a human to click a browser-modal dialog is not a test.
Three packages needed the same three listeners and each grew its own, with different signatures and separately maintained comments. Only two of them counted accepted connections, which is the assertion that proves the property the whole RFC turns on: each connection to the debug endpoint is a consent request, so "how many did we open" is the question.
It cannot live in chrometest: that package imports internal/chrome, and internal/chrome is one of the packages that needs this.
Index ¶
- func AcceptFor(key string) string
- func RequestKey(req string) string
- type Endpoint
- func Answer(t *testing.T, delay time.Duration, status string) *Endpoint
- func AnswerRaw(t *testing.T, delay time.Duration, reply func(req string) string) *Endpoint
- func Chrome(t *testing.T, delay time.Duration, status string) *Endpoint
- func Closed(t *testing.T) *Endpoint
- func Stall(t *testing.T) *Endpoint
- func (e *Endpoint) Addr() net.Addr
- func (e *Endpoint) AnsweredLive() bool
- func (e *Endpoint) Conns() int32
- func (e *Endpoint) HostPort() string
- func (e *Endpoint) Port() string
- func (e *Endpoint) PortFile(t *testing.T) string
- func (e *Endpoint) UsePortFile(t *testing.T) string
- func (e *Endpoint) WS() string
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func AcceptFor ¶
AcceptFor is RFC 6455's Sec-WebSocket-Accept for a given key.
This is deliberately a SECOND implementation of the accept key rather than a call into the one under test: a fake server that shares the client's helper agrees with it whatever it computes, which is how a mistyped GUID once passed every test in this package and still could not complete a handshake with Chrome. Both implementations are pinned to RFC 6455 section 1.3's published key/accept vector by TestAcceptForMatchesRFCVector in internal/chrome, which asserts this function AND acceptFor against it — so the two agreeing with each other is no longer sufficient to pass.
func RequestKey ¶
RequestKey pulls the Sec-WebSocket-Key out of a handshake request.
Types ¶
type Endpoint ¶
type Endpoint struct {
// contains filtered or unexported fields
}
Endpoint is a stub Chrome debug endpoint in one of the shapes the probe has to tell apart.
func Answer ¶
Answer accepts and, after delay, completes the WebSocket upgrade with status — the user finding the dialog behind the window and clicking Allow. A 101 status gets a full, VALID RFC 6455 response, with Sec-WebSocket-Accept computed from the key the client actually sent; the probe verifies it, so a stub that skipped it would be testing nothing.
Pass a non-101 status for a live server that is not a CDP browser (a stale port file whose port another process has taken).
func AnswerRaw ¶
AnswerRaw accepts and, after delay, writes exactly what reply returns for the request it received — for the handshakes that are meant to be wrong.
func Chrome ¶
Chrome is an endpoint with the HTTP JSON API present, i.e. a Chrome launched with --remote-debugging-port rather than toggled on in chrome://inspect. It answers /json/version with a WebSocket URL on its OWN host:port — which is the only authority the resolver will believe — and treats every other request as the upgrade: stalling forever when status is empty, replying with status after delay otherwise.
One listener, because a real Chrome is one listener. Splitting the JSON API and the WebSocket across two ports would be testing a shape that cannot occur, and the resolver rejects it on purpose.
func Closed ¶
Closed returns an endpoint with nothing listening on it: a stale port file, or a Chrome that has quit. It must fail in milliseconds, which is the safety property that makes waiting minutes on a stalling one acceptable.
func Stall ¶
Stall accepts connections and never answers — Chrome holding an unanswered consent prompt, which is the only state that hangs rather than failing.
func (*Endpoint) AnsweredLive ¶
AnsweredLive reports whether an Answer endpoint's reply landed on a socket that was still open — i.e. whether the consent the user granted went to a connection somebody had kept.
func (*Endpoint) Conns ¶
Conns is how many connections have been accepted. Every one of them is a consent request, so a test that asserts zero (or exactly one) is asserting the property the RFC exists to protect.
func (*Endpoint) PortFile ¶
PortFile writes a DevToolsActivePort file pointing at this endpoint and returns its path.
func (*Endpoint) UsePortFile ¶
UsePortFile writes the port file and points CHROME_CDP_PORT_FILE at it, so a command discovers this endpoint the way it discovers a real Chrome.
Source Files