Skip to content

V
varnish-cache
Commit 978c3e39 authored by Federico G. Schwindt's avatar Federico G. Schwindt
Browse files
Options

Correct output and general cleanup

parent 351a4e14
Hide whitespace changes
Inline Side-by-side
Showing with 54 additions and 97 deletions
bin/varnishtest/vtc.c
View file @ 978c3e39
......@@ -512,13 +512,13 @@ cmd_err_shell(CMD_ARGS)
VSB_destroy(&vsb);
}
/* SECTION: client-server.spec.delay delay
/* SECTION: delay delay
*
* Take a float as argument and sleep for that number of seconds.
*/
/* SECTION: stream.spec.delay delay
*
* Take a float as argument and sleep for that number of seconds.
* Same as for the top-level delay.
*/
void
cmd_delay(CMD_ARGS)
......
bin/varnishtest/vtc_doc_hdr.rst deleted 100644 → 0
View file @ 351a4e14
Syntax RFP for HTTP2 in varnishtest
===================================
This document tries to document how varnishtest would work this H/2, adapting to
the introduction of stream. The main idea is the introduction of a new command
(stream) inside client and server specification that naively maps to RFC7540.
It provides little abstraction, allowwing great control over test scenario,
while still retaining a familiar logic.
Here's an example of test file::
server s1 {
non-fatal
stream 1 {
rxreq
expect req.http.foo == <undef>
txgoaway -laststream 0 -err 9 -debug "COMPRESSION_ERROR"
} -run
} -start
client c1 -connect ${s1_sock} {
stream 1 {
txreq -idxHdr 100 -litHdr inc plain "foo" plain "bar"
rxgoaway
expect goaway.err == 9
expect goaway.laststream == 0
expect goaway.debug == "COMPRESSION_ERROR"
} -run
} -run
.. contents::
bin/varnishtest/vtc_http.c
View file @ 978c3e39
......@@ -92,7 +92,7 @@ static const struct cmds http_cmds[];
* \-run (client only)
* Equivalent to "-start -wait".
*
* \repeat NUMBER
* \-repeat NUMBER
* Instead of processing the specification only once, do it NUMBER times.
*
* \-break (server only)
......@@ -709,9 +709,9 @@ cmd_http_rxresp(CMD_ARGS)
vtc_log(hp->vl, 4, "bodylen = %s", hp->bodylen);
}
/* SECTION: client-server.spec.rxreqhdrs
/* SECTION: client-server.spec.rxresphdrs
*
* rxresp (client only)
* rxresphdrs (client only)
* Receive and parse a response's headers.
*/
static void
......@@ -921,7 +921,7 @@ http_tx_parse_args(char * const *av, struct vtclog *vl, struct http *hp,
return (av);
}
/* SECTION: client-server.spec.txre
/* SECTION: client-server.spec.txreq
*
* txreq|txresp [...]
* Send a minimal request or response, but overload it if necessary.
......@@ -1153,7 +1153,7 @@ cmd_http_rxreqbody(CMD_ARGS)
/* SECTION: client-server.spec.rxrespbody
*
* rxrespbody
* rxrespbody (client only)
* Receive a response's body.
*/
......@@ -1178,7 +1178,7 @@ cmd_http_rxrespbody(CMD_ARGS)
/* SECTION: client-server.spec.rxchunk
*
* rxchunk
* Receive an HTTP chunk
* Receive an HTTP chunk.
*/
static void
......@@ -1512,13 +1512,7 @@ cmd_http_timeout(CMD_ARGS)
/* SECTION: client-server.spec.expect_close
*
* expect_close
* Wait for the connected client to close the connection.
*/
/* SECTION: client-server.spec.expect_close expect_close (server)
*
* Reads from the connection, expecting nothing to read but an EOF.
*
* Reads from the connection, expecting nothing to read but an EOF.
*/
static void
cmd_http_expect_close(CMD_ARGS)
......@@ -1563,14 +1557,8 @@ cmd_http_expect_close(CMD_ARGS)
/* SECTION: client-server.spec.close
*
* close (server only)
* Close the active TCP connection
*/
/* SECTION: client-server.spec.close close (server)
*
* Close the connection. Not that if operating in H/2 mode, no extra (GOAWAY)
* frame is sent, it's simply a TCP close.
*
* Close the connection. Note that if operating in HTTP/2 mode no
* extra (GOAWAY) frame is sent, it's simply a TCP close.
*/
static void
cmd_http_close(CMD_ARGS)
......@@ -1580,6 +1568,7 @@ cmd_http_close(CMD_ARGS)
(void)cmd;
(void)vl;
CAST_OBJ_NOTNULL(hp, priv, HTTP_MAGIC);
ONLY_SERVER(hp, av);
AZ(av[1]);
assert(hp->sfd != NULL);
assert(*hp->sfd >= 0);
......@@ -1589,16 +1578,11 @@ cmd_http_close(CMD_ARGS)
vtc_log(vl, 4, "Closed");
}
/* SECTION: client-server.spec.accept_close
/* SECTION: client-server.spec.accept
*
* accept (server only)
* Close the active connection (if any) and accept a new one.
*/
/* SECTION: client-server.spec.accept accept (server)
*
* Close the potential current connection, and accept a new one. Note that this
* new connection is H/1.
* Close the current connection, if any, and accept a new one. Note
* that this new connection is HTTP/1.x.
*/
static void
cmd_http_accept(CMD_ARGS)
......@@ -1608,6 +1592,7 @@ cmd_http_accept(CMD_ARGS)
(void)cmd;
(void)vl;
CAST_OBJ_NOTNULL(hp, priv, HTTP_MAGIC);
ONLY_SERVER(hp, av);
AZ(av[1]);
assert(hp->sfd != NULL);
assert(*hp->sfd >= 0);
......@@ -1680,10 +1665,11 @@ cmd_http_fatal(CMD_ARGS)
const char PREFACE[24] = "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n";
/* SECTION: client-server.spec.txpri txpri (client)
/* SECTION: client-server.spec.txpri
*
* Send an H/2 preface ("PRI * HTTP/2.0\\r\\n\\r\\nSM\\r\\n\\r\\n") and set
* client to H/2.
* txpri (client only)
* Send an HTTP/2 preface ("PRI * HTTP/2.0\\r\\n\\r\\nSM\\r\\n\\r\\n")
* and set client to HTTP/2.
*/
static void
cmd_http_txpri(CMD_ARGS)
......@@ -1710,10 +1696,11 @@ cmd_http_txpri(CMD_ARGS)
AN(hp->h2);
}
/* SECTION: client-server.spec.rxpri rxpri (server)
/* SECTION: client-server.spec.rxpri
*
* Receive a preface, and if it matches, sets the server to H/2, aborts
* otherwise.
* rxpri (server only)
* Receive a preface. If valid set the server to HTTP/2, abort
* otherwise.
*/
static void
cmd_http_rxpri(CMD_ARGS)
......@@ -1735,8 +1722,8 @@ cmd_http_rxpri(CMD_ARGS)
/* SECTION: client-server.spec.settings
*
* settings -dectbl INT
* Force internal H/2 settings to certain values. Currently only
* support setting the decoding table size.
* Force internal HTTP/2 settings to certain values. Currently only
* support setting the decoding table size.
*/
static void
cmd_http_settings(CMD_ARGS)
......
bin/varnishtest/vtc_http2.c
View file @ 978c3e39
......@@ -1294,10 +1294,11 @@ cmd_sendhex(CMD_ARGS)
/* SECTION: stream.spec.data_0 txreq, txresp, txcont, txpush
*
* These four commands are about sending headers. txreq, txresp will send
* HEADER frames, txcont will send CONTINUATION frames, and txpush PUSH frames.
* The only difference between txreq and txresp are the default headers set by
* each of them.
* These four commands are about sending headers. txreq and txresp
* will send HEADER frames; txcont will send CONTINUATION frames; txpush
* PUSH frames.
* The only difference between txreq and txresp are the default headers
* set by each of them.
*
* \-noadd
* Do not add default headers. Useful to avoid duplicates when sending
......@@ -2095,7 +2096,7 @@ rxstuff(struct stream *s)
wt < TYPE_MAX ? h2_types[wt] : "?", wt); \
} while (0);
/* SECTION: stream.spec.data_12 rxhdrs
/* SECTION: stream.spec.data_11 rxhdrs
*
* ``rxhdrs`` will expect one HEADER frame, then, depending on the arguments,
* zero or more CONTINUATION frame.
......@@ -2273,7 +2274,7 @@ cmd_rxreqsp(CMD_ARGS)
s->frame = f;
}
/* SECTION: stream.spec.data_11 rxpush
/* SECTION: stream.spec.data_12 rxpush
*
* This works like ``rxhdrs``, expecting a PUSH frame and then zero or more
* CONTINUATION frames.
......@@ -2338,37 +2339,37 @@ cmd_rxpush(CMD_ARGS)
/* SECTION: stream.spec.prio_rxprio rxprio
*
* Receive a PRIORITY frame
* Receive a PRIORITY frame.
*/
RXFUNC(prio, PRIORITY)
/* SECTION: stream.spec.reset_rxrst rxrst
*
* Receive a RST_STREAM frame
* Receive a RST_STREAM frame.
*/
RXFUNC(rst, RST_STREAM)
/* SECTION: stream.spec.settings_rxsettings rxsettings
*
* Receive a SETTINGS frame
* Receive a SETTINGS frame.
*/
RXFUNC(settings,SETTINGS)
/* SECTION: stream.spec.ping_rxping rxping
*
* Receive a PING frame
* Receive a PING frame.
*/
RXFUNC(ping, PING)
/* SECTION: stream.spec.goaway_rxgoaway rxgoaway
*
* Receive a GOAWAY frame
* Receive a GOAWAY frame.
*/
RXFUNC(goaway, GOAWAY)
/* SECTION: stream.spec.winup_rxwinup rxwinup
*
* Receive a WINDOW_UPDATE frame
* Receive a WINDOW_UPDATE frame.
*/
RXFUNC(winup, WINDOW_UPDATE)
......@@ -2607,29 +2608,31 @@ stream_run(struct stream *s)
/* SECTION: client-server.spec.zstream stream
/* SECTION: client-server.spec.stream
*
* H/2 introduces the concept of streams, and these come with their own
* specification, and as it's quite big, have bee move to their own chapter.
* stream
* HTTP/2 introduces the concept of streams, and these come with
* their own specification, and as it's quite big, have been moved
* to their own chapter.
*
* SECTION: stream stream
*
* (note: this section is at the top-level for easier navigation, but it's part
* of the client/server specification)
* (note: this section is at the top-level for easier navigation, but
* it's part of the client/server specification)
*
* Streams map roughly to a request in H/2, a request is sent on stream N,
* the response too, then the stream is discarded. The main exception is the
* first stream, 0, that serves as coordinator.
* Streams map roughly to a request in HTTP/2, a request is sent on
* stream N, the response too, then the stream is discarded. The main
* exception is the first stream, 0, that serves as coordinator.
*
* Stream syntax follow the client/server one::
*
* stream ID [SPEC] [ACTION]
*
* ID is the H/2 stream number, while SPEC describes what will be done in that
* stream.
* ID is the HTTP/2 stream number, while SPEC describes what will be
* done in that stream.
*
* Note that, when parsing a stream action, if the entity isn't operating in H/2
* mode, these spec is ran before::
* Note that, when parsing a stream action, if the entity isn't operating
* in HTTP/2 mode, these spec is ran before::
*
* txpri/rxpri # client/server
* stream 0 {
......@@ -2640,7 +2643,7 @@ stream_run(struct stream *s)
* expect settings.ack == true
* } -run
*
* And H/2 mode is then activated before parsing the specification.
* And HTTP/2 mode is then activated before parsing the specification.
*
* SECTION: stream.actions Actions
*
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment