htt user's guide

8/2/2019 Htt User's Guide

1/124

htt Users Guide Version 2.0.14

by Marcel Schoen, Switzerland

December 6, 2011


2/124

2


3/124

Contents

1 htt Functionality Overview 9

2 Quickstart 11

2.1 Step 1: GET www.wikipedia.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Step 2: Externalize host and port values . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 htt Commandline Interface 15

3.1 Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 htt Script Structure 17

4.0.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Structure Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 htt Variables 19

5.1 Variable Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 Variable Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3 Setting A Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.4 Using Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Body Types 23

6.1 Bodies And Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1 Parallel Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3


4/124

4 CONTENTS

6.1.2 Execution Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.3 Lifespan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1.4 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 CLIENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3 SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.4 DAEMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.5 BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 htt How Tos 31

7.1 File Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8 htt Commands 33

8.1 Global Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.2 Local Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.2.1 Double Underscore Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9 List Of Global Commands 37

9.1 AUTO CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9.2 BLOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9.3 CLIENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

9.4 DAEMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

9.5 END . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.6 EXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.7 FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

9.8 GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.9 INCLUDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9.10 MODULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9.11 PROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

9.12 SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

9.13 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

9.14 TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


5/124

CONTENTS 5

10 List Of Local Commands 53

10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

10.2 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

10.3 ADD HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

10.4 AUTO CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

10.5 AUTO COOKIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10.6 BPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

10.7 B64DEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.8 B64ENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

10.9 BREAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

10.10 CALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

10.11 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6410.12 CHUNK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

10.13 CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

10.14 DEBUG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10.15 DETACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

10.16 ELSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

10.17 ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

10.18 EXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

10.19 EXIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10.20 EXPECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

10.21 FLUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10.22 FOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.23 GREP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

10.24 HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

10.25 IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

10.26 IGNORE BODY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

10.27 LOG LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

10.28 LOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

10.29 MATCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


6/124

6 CONTENTS

10.30 ONLY PRINTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.31 OP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.32 PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.33 PIPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.34 PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.35 PRINT HEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

10.36 RAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.37 RECORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10.38 RECV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

10.39 RENEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

10.40 REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

10.41 RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.42 RESWAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.43 RPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10.44 SEQUENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

10.45 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

10.46 SH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

10.47 SLEEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

10.48 SOCKET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

10.49 SOCKSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

10.50 SSL BUF 2 CERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

10.51 SSL CERT VAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

10.52 SSL CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

10.53 SSL ACCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

10.54 SSL ENGINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

10.55 SSL GET SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

10.56 SSL LEGACY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10.57 SSL SECURE RENEG SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.58 SSL SESSION ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.59 SSL SET SESSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


7/124

CONTENTS 7

10.60 STRFTIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

10.61 SYNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

10.62 TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

10.63 TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

10.64 TIMER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

10.65 TUNNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

10.66 URLDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10.67 URLENC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

10.68 USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

10.68.1 Overriding commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

10.69 WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

10.70 WHICH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124


8/124

8 CONTENTS


9/124

Chapter 1

htt Functionality Overview

The htt provides a large variety of HTTP-related functionality, useful for implementing allkinds of HTTP-based tests:

Advanced HTTP protocol handling, including fine-grained timeout handling, request andresponse validation

Simulating clients and servers, including startup and shutdown of server daemons. This allowsto create mock-ups of back-end systems in more complex test situations, for example when thetested application needs to interact with a 3rd-party back-end system which is not availablein the testing environment.

Execution of external commandline tools, using their output as request or response data, orfor validation purposes.

Copying stream data (e.g. from a response) and re-using it in variables.

9


10/124

10 CHAPTER 1. HTT FUNCTIONALITY OVERVIEW


11/124

Chapter 2

Quickstart

This short chapter shows some simple, basic htt examples without explaining everything. Someparts should be obvious for anyone who has a solid knowledge of HTTP, everything else will beexplained in more detail in the other chapters.

NOTE: Depending on the version and platform you are using httest on, there may be a bug whichrequires that every script ends with an empty line, below the last statement or variable definition!

2.1 Step 1: GET www.wikipedia.org

This first example sends a simple GET request to www.wikipedia.org and checks that the pagecontains the word Wikipedia, and the HTTP response code is 200.

Enter the following example code into a file named wikipedia.htt:

CLIENT_ R EQ w ww . w i k i p e di a . o r g 8 0

_ _G ET / H TT P / 1. 1

_ _ H os t : w w w . w i ki p e di a . o r g

__

_ E XP E CT . " 20 0 O K "

_ E X PE C T . " W i k i p ed i a "

_WAIT

END

Then execute the newly created script using the httest binary:

% > h t te s t w i k ip e d ia . h t t

11


12/124

12 CHAPTER 2. QUICKSTART

And, given that the system you are running httest on has internet access, the following resultshould be displayed:

r u n w i k ip e d ia . h t t

C LT 0 - 0 s ta rt . ..

_ R EQ w ww . w i k i p e di a . o r g 8 0

_ _G ET / H TT P / 1. 1

_ _ H os t : w w w . w i ki p e di a . o r g__

_ E XP E CT . " 20 0 O K "


_WAIT

> G ET / H TT P / 1. 1

> H o st : w w w . w i ki p e di a . o r g

>

< H TT P / 1. 0 2 00 O K

< D at e : T ue , 1 8 J an 2 01 1 1 2 :3 8: 5 1 G MT

...

. . . m an y m o re h e ad e rs , a n d t h e H T ML p a ge . . .

...

< < / b o d y >

< < / ht ml > O K

Some explanations concerning the output:

The first part (everything before the lines with the > prefix) shows the commands executedby the httest binary.

All lines beginning with > show the data sent to the HTTP server.

All lines beginning with h tt e st - - he lp

h tt e st i s a s c ri pt b as ed t oo l f or t e st in g a nd b e nc h ma r ki n g w eba p p li c at i o ns , w e b s e rv e rs , p r ox y s e r ve r s a nd w eb b r o ws e r s . h t t es t

c an e m ul a te c l ie n ts a nd s e rv e rs i n t he s am e t es t s cr ip t , v er y

u se f ul f or t e st i ng p ro x ys .

U s ag e : h t te s t [ O P T I ON S ] s c r ip t s

O p t i o n s :

-V -- ve rsi on Print ver sion number and exit

-h -- help Di spl ay usage i nf or m at i on ( this m essa ge )

-n -- supp re ss do no print start and OK | FA ILED

-s -- sile nt sile nt mode

-i -- info log level info

-e -- error log level error-w -- warn log level warn

-d -- debug log level debug

- L -- li st - c o m m an d s L is t a ll a v a il a bl e s c ri p t c om ma n ds

- C - -h el p - c om ma nd P ri nt h el p f or s pe ci fi c co mm an d

-T -- tim es ta mp Time stamp on every run

-S -- shell Shell mode

E x a m p l e s :

h t t es t s c ri p t . h t t

h t t es t - T s s c ri p t . h t t

R e p or t b u gs t o h t tp : / / s o u r c ef o r ge . n e t / p r o j ec t s / h t t


17/124

Chapter 4

htt Script Structure

A htt test usually consists of a .htt file (the main script), and optionally some include files(usually with the suffix .htb).

The main script consists of include statements, global or local commands, variables, bodies andcomments:

Command: An instruction to perform an action, like sending a request, setting a header inthat request, evaluating the response etc. There are global and local commands (explainedin the chapter Commands).

Include: A global command used to include re-usable scripting code from other files.

Variables: Holder for values created during the execution of the script.

Body: A block of code containing a number of commands.

Comment: A line of non-executable text

Commands, variables and body types are explained in more detail in the corresponding chapters.

4.0.1 Comments

Comment lines must begin with the # character.

17


18/124

18 CHAPTER 4. HTT SCRIPT STRUCTURE

4.1 Structure Example

A simple htt script code example for showing the structure:

# I nc l ud e s om e m ac r os

I N C LU D E m a c ro s . h t b

# T he a ct ua l t es t c li en t p ar t

CLIENT

.. .

END

# O p ti o na l : a re - u s ed c od e b lo ck

B L OC K D O IT

.. .

END

# O p ti o na l : A t es t m o ni t or i ng d ae mo n

DAEMON.. .

END

In the example above, INCLUDE is a global statement used to include another script file with somere-usable code blocks. It is followed by the CLIENT block which starts the actual HTTP test client,a block of re-usable functionality named DOIT and a DAEMON body which contains some testmonitoring functionality.

4.2 Control Flow

The following options are available to control the flow of a httest script:

Conditions: The IF command supports the execution of a code body depending on a condi-tion.

Loops: While the FOR command allows to execute a code body for a given list of elements,the LOOP command allows to do the same for a certain number of times.


19/124


20/124

20 CHAPTER 5. HTT VARIABLES

5.3 Setting A Variable

The syntax for setting a global variable is:

S E T n a me = v a l u e

The syntax for setting a local variable in a body is:

_ S ET n a me = v a l u e

Examples:

S E T M Y VA R = S o m e Va l u e

CLIENT

_ S E T M Y L O C A L = L o c a l V a l u e

# I nv ok e b lo ck D OI T , m ak es v a ri a bl e " D o Lo ca l "# a va il ab le in t hi s C LI EN T b od y a s w el l .

_ C AL L D O IT

END

B L OC K D O IT

_ S E T D o L o c a l = a n o t h e r V a l u e

END


21/124

5.4. USING VARIABLES 21

5.4 Using Variables

In order to resolve a variable and use the value it is holding, its name must be prefixed with a $character, just like in a shell script. Example:

# S et g lo ba l V a ri a bl e s f or h os t a nd p or t

S E T M y H os t = w w w . a cm e . c o mS E T M y P or t = 8 0 80

CLIENT

# I nv ok e n am ed b lo ck D OI T w hi ch

# s et s t he v ar ia bl e f or t he U RI p at h

_ C AL L D O IT

_ R EQ $ M yH o s t $ M y Po r t

_ _ GE T $ U r iP a t h H T TP / 1 . 1

_ _ H os t : w w w . a cm e . c o m

__

_WAIT

END

B L OC K D O IT

# S et U RI p at h v ar ia bl e w hi ch w il l a ls o

# b ec om e a v ai l ab l e i n t he i n vo k in g b od y .

_ S E T U r i P a t h = / w e b a p p

END


22/124

22 CHAPTER 5. HTT VARIABLES


23/124

Chapter 6

Body Types

The following global body types exist:

CLIENT - The main HTTP test client logic.

SERVER - Allows to start a HTTP server which will react and respond as defined in the givenblock. This allows to simulate HTTP back-end servers (like some application server) that maynot be available in the testing environment.

BLOCK - A block is a named section of the script with a defined begin and ending, not unlikefunctions or methods in common scripting or programming languages.

BLOCK FINALLY - A special block. The FINALLY block is always executed at the end ofthe test, and can be used for clean-up work.

BLOCK ON ERROR - Another special block. A global error handler that will be executed

when an error occurs in a test script. While some errors can be handled within a regularbody (e.g. during the evaluation of a HTTP response), other errors (especially technicalones) sometimes can only be handled in this block.

DAEMON - Other than a SERVER, a DAEMON does not implement any kind of listener. It isjust a separate thread that can be used to monitor or control the execution of the test, e.g.implement timeout functionality to interrupt a hanging test etc.

The following local body types exist:

BPS - Limits the number of bytes sent during a period of time.

ERROR - Ensures that a certain expected error happened within the body.

FOR - Allows to define code with is executed for a given number of elements.

IF - Allows to define code with is executed only if a given condition is true.

23


24/124

24 CHAPTER 6. BODY TYPES

LOOP - Allows to execute the given block of code a certain number of times.

RPS - Limits the number of requests sent during a period of time.

SOCKET - Spawns a socket reader.


25/124

6.1. BODIES AND THREADS 25

6.1 Bodies And Threads

6.1.1 Parallel Execution

Note that all body blocks are executed in separate threads! So, if a htt script contains more thanone CLIENT body, each one will be started in a separate thread, allowing to simulate two distinct,

separate HTTP clients in one test case.

6.1.2 Execution Order

While multiple bodies are executed in parallel threads in general, SERVER and DAEMON bodies arealways started before CLIENT bodies.

6.1.3 Lifespan

If a CLIENT body (or all of them, if theres more than one) ends, the test ends, and the htt processexits. The completion of SERVER and DAEMON bodies, on the other hand, will not automaticallyterminate the test.

6.1.4 Synchronization

There is no means of synchronization between those threads as of now.


26/124


6.2 CLIENT

A CLIENT body is the part of a htt script, where the actual HTTP requests are generated to performsome kind of test. Usually, there is just one single CLIENT body in a htt script, but there can bemultiple ones; in that case, they are executed in parallel threads.

A htt test ends, when all CLIENT bodies complete their work.A simple CLIENT example:

CLIENT

_ R EQ w ww . w i k i p e di a . o r g 8 0

_ _G ET / H TT P / 1. 1

_ _ H os t : w w w . w i ki p e di a . o r g

__

_ E XP E CT . " 20 0 O K "


_WAIT

END


27/124

6.3. SERVER 27

6.3 SERVER

A SERVER body can start a HTTP listener and react to incoming HTTP requests with predefinedresponses. This allows to simulate application backend servers that may not be available in a testenvironment.

There can be multiple SERVER bodies; in that case, they are executed in parallel threads.A htt test does not end when the SERVER bodies complete their work, only when the CLIENT bodieshave finished.

A simple SERVER example:

# S im pl e H TT P l i st e ne r w hi ch j us t r e sp o nd s w it h

# a H TT P 2 00 r et ur n co de , a nd a n e mp ty b od y .

SERVER

_RES

_WAIT

_ _ H TT P / 1 . 1 2 0 0 O K

_ _ C o nt e n t - L e n g t h : A U T O

_ _ C o nt e n t - T y p e : t e x t / h t m l

__

END


28/124


6.4 DAEMON

A DAEMON body does not start a listener, and also not necessarily send any HTTP request. Itspurpose is to perform monitoring tasks during a test. For instance, if a CLIENT body sends aHTTP request that may hang for a long time due to slow response time of the server, the DAEMONmay enforce an exit of the htt test process after a certain time, essentially implementing a timeout

function.

This is only one possibility. A DAEMON can also monitor log files written during the test, executeexternal binaries etc.

There can be multiple DAEMON bodies; in that case, they are executed in parallel threads.

A htt test does not end when the DAEMON bodies complete their work, only when the CLIENT bodieshave finished.

A simple DAEMON example:

# T im e ou t d ae mo n t hr ea d , w hi ch e xi ts t he

# t es t p r oc e ss w it h a f ai l ur e r et ur n c od e ,# i f i t t ak es l on ge r t ha n 3 0 s ec on ds .

DAEMON

_ S L EE P 3 0 00 0

_ DE B UG T es t d u ra ti o n t oo l on g

_ E XI T F A IL E D

END


29/124

6.5. BLOCK 29

6.5 BLOCK

A BLOCK body is not executed by itself like CLIENT or SERVER bodies; it just serves as a holderfor a fragment of re-usable script code, similar to a function or method in common programminglanguages.

Every BLOCK must have a name, in order to distinguish them from each other, and to be able to beinvoked from another body.

Just like high-level programming language functions or methods, a BLOCK can be parameterized, ina way very similar to shell scripts. The name of the BLOCK, mentioned in the previous paragraph,is just the first parameter (and its mandatory). Within the BLOCK body, all parameter values areavailable as variables with simple numeric names, like in a shell script:

$0 - The name of the BLOCK

$1 - The first parameter after the name

$2 - The second parameter after the name $3 - The third parameter, and so on

A simple BLOCK example, without parameters:

B L OC K S E N DR E Q

_ R EQ w ww . a c m e . c om 8 0

_ _G ET / H TT P / 1. 1

_ _ H os t : w w w . a cm e . c o m

__

_WAIT

END

The following example shows a BLOCK with some parameters:

# B lo ck t ak es 3 p a ra m et e rs :

# 1 : h o st n am e , l i ke w w w . a cm e . c o m

# 2: p or t

# 3 : r eq ue st ed U RI p at h

B L OC K S E N DR E Q

_ RE Q $ 1 $2

_ _ GE T $ 3 H T TP / 1 . 1

_ _ H os t : $ 1

___WAIT

END


30/124



31/124

Chapter 7

htt How Tos

7.1 File Upload

Performing a file upload with httest can be a bit tricky. Heres an example of how to upload a file,where the actual data to be posted is read from a local file ./data.xml:

_ R EQ $ H OS T $ P OR T

_ _ P OS T / m y a pp H T TP / 1 . 1

_ _ H os t : $ H OS T : $ P O RT

_ _ C on n e c ti o n : k ee p - a l i v e

_ _ C o nt e n t - T y p e : m u l t i p a r t / f o rm - d a t a ; b o u n d a r y = A a B 0 3 x

_ _ C o nt e n t - L e n g t h : A U T O

__

_ _ - - A a B 0 3 x

_ _ Co n te n t - D i s p o si t i on : f or m - d a t a ; n a me = " x y " ; f i l en a m e = " d at a . x m l "

_ _ C o nt e n t - T y p e : t e x t / x m l

__

_PIPE

_ E XE C c a t . / d a ta . x m l

__

_ _ - - A a B 0 3 x

_ _ C o nt e n t - D i s p o s i t i o n : f o rm - d a t a ; n a m e = " f i l e _ u p l o a d "

__

__Upload

_ - - A a B 0 3 x - -

_ E X PE C T h e a de r s " H T TP / 1 . 1 2 0 0"

_WAIT

Note the additional empty line after the EXEC call; this may be necessary depending on the contentof the posted file data.

Also, the Content-Type header value must match the type of data being posted, of course.

Using a tool like the Firefox add-on HTTP Live-Headers can be very helpful to get the correct

31


32/124

32 CHAPTER 7. HTT HOW TOS

request data for posting a given file!


33/124

Chapter 8

htt Commands

Commands are the actual instructions that make up the test script, such as sending a request to aHTTP server, evaluating the response etc. There are two different types of commands:

Global commands always begin with a capital letter (e.g. INCLUDE) and can be placed inthe root of the script, outside of any body (such as a block).

Local commands always begin with an underscore (e.g. GET) and can only be placed withina body.

Some commands take arguments to perform their operation. Usually, the syntax is

C O M MA N D [ a r g u m en t ] [ a r g u me n t ] [ a r g u me n t ] . ..

There is a special exception, the double-underscore local command (see section Local Commandsfor details) which does not take a blank character between the command and its argument.

33


34/124

34 CHAPTER 8. HTT COMMANDS

8.1 Global Commands

Global commands are used to perform initialization work, clean-up steps, start and end bodies etc.

Global commands can only be used within the root part of the script, i.e. outside of a body. Itis not possible to use a global command within a CLIENT, SERVER, DAEMON or BLOCK body.

Note that some commands can are available in two forms, both as global and local command.

The following global commands perform an operation by themselves:

AUTO CLOSE -

EXEC -

FILE -

GO -

INCLUDE - Includes content from a file.

PROCESS - Runs the test in multiple processes.

SET - Sets a global variable.

TIMEOUT -

While the global commands listed below are used to start or end a body (a block of script code):

CLIENT - Starts a CLIENT body.

SERVER - Starts a SERVER body. DAEMON - Starts a DAEMON body.

END - Ends the current body.

All these commands are explained in more detail in 9.


35/124

8.2. LOCAL COMMANDS 35

8.2 Local Commands

Local commands always begin with an underscore ( ) character. There are a large number oflocal commands, and they are explained in more detail in 10.

8.2.1 Double Underscore Command

Please note that the double-underscore is also a local command! But contrary to all other commands,with the double-underscore theres no blank character between the command and its parameters.

The reason for this somewhat peculiar design is that this command is used to insert a line of datainto the output stream of a HTTP request. And a line always ends with two invisible charactersfor the line-break and line-feed. Now, in some cases it is necessary to calculate the exact length ofa line in order to know the correct length of the HTTP request body; in that case, the length of aline displayed by a text editor can be used directly as the length of the actual line of HTTP datafor body length calculations.


36/124

36 CHAPTER 8. HTT COMMANDS


37/124

Chapter 9

List Of Global Commands

This chapter contains a comprehensive list of all the global commands available in httest scripts.

37


38/124

38 CHAPTER 9. LIST OF GLOBAL COMMANDS

9.1 AUTO CLOSE

Syntax:

AUTO_CLOSE on|off

Purpose:

Closes the current connection automatically.


39/124

9.2. BLOCK 39

9.2 BLOCK

Syntax:

BLOCK

Purpose:

Begins a body with scripting code that can be invoked from anywhere else, using the CALL or_CALL command.

The BLOCK must be closed using the END command.

Error Handler

A special, reserved name for a BLOCK is ON ERROR. It designates the block to be invoked if anunexpected error occurs during a test. The block can then handle the error, output some informationetc. Example:

B L OC K O N _ ER R O R

_DEBUG

_ D E B U G ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

_ DE B UG A n e rr or o cc ur re d , p le as e f ix i t a nd t ry a ga in !

_ D E B U G ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !

_DEBUG

_ E XI T F A IL E D

END


40/124


9.3 CLIENT

Syntax:

CLIENT []

Purpose:

Begin of a body which starts one or multiple threads running a test client for sending HTTPrequests to a server, and evaluating the response.

The number of threads started depends on the value of the argument for the number of concurrentclients. If none is given, it defaults to 1 and only a single thread will be started. Otherwise, thesame CLIENT body will be executed in the specified number of parallel threads.

The CLIENT must be closed using the END command.


41/124

9.4. DAEMON 41

9.4 DAEMON

Syntax:

DAEMON

Purpose:

Begins a body with scripting code that is executed in a separate thread, and can be used toperform tasks like monitoring the tests, enforcing timeouts etc.

The DAEMON must be closed using the END command.


42/124


9.5 END

Syntax:

END

Purpose:

Ends the current body (either a CLIENT, SERVER, DAEMON or BLOCK body).


43/124

9.6. EXEC 43

9.6 EXEC

Syntax:

EXEC

Purpose:

Executes the given command, e.g. an external shell script. Note: The execution will not joinany of the CLIENT or SERVER threads. In other words, the command will execute and completeindependently of any such threads.


44/124


9.7 FILE

Syntax:

FILE

Purpose:

Creates a temporary file with the given name.


45/124

9.8. GO 45

9.8 GO

Syntax:

GO

Purpose:

Starts all CLIENT, SERVER and DAEMON bodies that have been defined up to this point.


46/124


9.9 INCLUDE

Syntax:

INCLUDE

Purpose:

Includes the given file into the current script code. The file name parameter is processed relativeto the working directory of the current process, if it is not an absolute path.


47/124

9.10. MODULE 47

9.10 MODULE

Syntax:

MODULE

Purpose:

A module represents a collection of BLOCKs. It adds a namespace element that can help organizere-usable blocks by adding the module name as a prefix for each block.

So, every block contained in a module must be invoked by adding the module name as a prefix.

# B eg in a m od ul e " u t il it y "

M O D UL E u t i li t y

B L OC K o n e...

END

Invoke the block one from this example then like that:

_ C AL L u t i li t y : o n e


48/124


9.11 PROCESS

Syntax:

PROCESS

Purpose:

Runs the script in parallel processes simultanously.


49/124

9.12. SERVER 49

9.12 SERVER

Syntax:

SERVER [:] []

Purpose:

Begin of a body which starts one or multiple threads running a test server for responding toHTTP requests in predefined ways.

The number of threads started depends on the value of the argument for the number of concurrentservers. If none is given, it defaults to 1 and only a single thread will be started. Otherwise, thesame SERVER body will be executed in the specified number of parallel threads.

The SERVER must be closed using the END command.


50/124


9.13 SET

Syntax:

SET =

Purpose:

Sets a global variable. The variable can then be used in the script with a $-sign prefix.

Example:

S E T M y H os t = w w w . a cm e . c o m

...

_ RE Q $ My H os t 8 0


51/124

9.14. TIMEOUT 51

9.14 TIMEOUT

Syntax:

TIMEOUT

Purpose:

Sets the global TCP socket connection timeout.


52/124



53/124

Chapter 10

List Of Local Commands

This chapter contains a comprehensive list of all the local commands available in httest scripts.

53


54/124

54 CHAPTER 10. LIST OF LOCAL COMMANDS

10.1

Syntax:

Purpose:

Sends the given string data to the current socket, with CRLF line termination characters.

NOTE: There MUST NOT BE a blank between the command and the following string data (orthe blank itself will be part of the string data as well).

The reason for using this peculiar design lies in the history of the httest utility. In early versions,

the value of the content-length HTTP header of a request had to be calculated and set manually.In that situation, it was easier to calculate the actual number of bytes a line of data wouldtake up, because the two underscores at the beginning of the line allowed to just use the numberof columns value displayed by any text editor. The reason: Without these two characters, a texteditor would display only the number of visible characters, but the CRLF characters had also tobe taken into account for a correct content-length header value. So the double underscore was areplacement for the invisible line termination characters.

However, its not necessary for this purpose anymore as httest allows to set the correct contentlength value automatically now.


55/124

10.2. - 55

10.2 -

Syntax:

-

Purpose:

Sends the given string data to the current socket, without any CRLF line termination characters.This is mostly used for sending POST body data.

NOTE: There MUST NOT BE a blank between the command and the following string data (orthe blank itself will be part of the string data as well).


56/124


10.3 ADD HEADER

Syntax:

ADD HEADER

Purpose:

Adds an additional header to received headers.


57/124

10.4. AUTO CLOSE 57

10.4 AUTO CLOSE

Syntax:

AUTO CLOSE on|off

Purpose:

AUTO CLOSE on lets httest automatically close a connection when an incoming Connection:close header is received.


58/124


10.5 AUTO COOKIE

Syntax:

AUTO COOKIE on|off

Purpose:

Automatically handles incoming cookies, so that they are sent with the next request on the sameconnection they were received on. Does not check cookie expiration or path. This only works if theheader Cookie: AUTO is available in the request.

_ A U TO _ C O OK I E o n

_ R EQ l o c al h o st 8 0 80

_ _G ET / H TT P / 1. 1

_ _ H os t : l o c al h o st_ _ C oo k i e : A U TO

__

_WAIT


_ _ GE T / f o o H T TP / 1 . 1

_ _ H os t : l o c al h o st

_ _ C oo k i e : A U TO

__

_WAIT


59/124

10.6. BPS 59

10.6 BPS

Syntax:

BPS

Purpose:

Defines a code body which limits the maximum number of bytes that may be sent during a certainperiod of time (specified in number of seconds).

The body must be closed with the END BPS command.

The following example limits the number of bytes to be sent within the next 300 seconds to 50000:

_ BP S 5 00 00 3 00


_ _G ET / H TT P / 1. 1


__

_WAIT

_ E ND R PS


60/124


10.7 B64DEC

Syntax:

B64DEC ""

Purpose:

Stores a Base64-decoded string into .


61/124

10.8. B64ENC 61

10.8 B64ENC

Syntax:

B64ENC ""

Purpose:

Stores a Base64-encoded string into .


62/124


10.9 BREAK

Syntax:

BREAK

Purpose:

Breaks out of the current loop.

String example:

Break the loop if variable $ABC has been set to Stop:

_ L OO P 5 0 0_ C AL L S o m eB l o ck

_ IF " $ AB C " M AT CH " S to p "

_BREAK

_ EN D I F

_ E ND L O OP


63/124

10.10. CALL 63

10.10 CALL

Syntax:

CALL

Purpose:

Invokes the given BLOCK. See section 6.5 on page 29 for examples.

Namespaces:

Namespace prefixes can be added with the local command USE (see section 10.68 on page 121for details).


64/124


10.11 CERT

Syntax:

CERT []

Purpose:

Configures the certificate to use for the current SSL connection. This is mainly necessary forserver certificates (because an SSL server always must present a certificate). For clients, this isnecessary only if mutual authentication is required.

The file formats are basically the same ones used to configure SSL in an Apache webserver (PEMcertificate and key files).


65/124

10.12. CHUNK 65

10.12 CHUNK

Syntax:

CHUNK

Purpose:

This marks the end of a chunk data block. It counts the number of bytes sent since the lastinvocation of FLUSH and automatically adds chunk info to the request.


66/124


10.13 CLOSE

Syntax:

CLOSE

Purpose:

Closes the current connection (and sets the connection state to CLOSED).


67/124

10.14. DEBUG 67

10.14 DEBUG

Syntax:

DEBUG

Purpose:

Prints a text string to stderr for debugging purposes.


68/124


10.15 DETACH

Syntax:

DETACH

Purpose:

Daemonizes the current httest process, which can be useful if it is just a test server among others.


69/124

10.16. ELSE 69

10.16 ELSE

Syntax:

ELSE

Purpose:

Defines a code body which is executed if the condition defined in the preceeding IF commandwas not fulfilled. The body must then be closed by the END IF command.

NOTE: This command can only be used together with, and following the IF command. Example:

_ IF " f oo " E QU AL " f oo "

_ D O _ S O M E T H I N G

_ELSE_ D O _ S O M E T H I N G _ O T H E R

_ EN D I F


70/124


10.17 ERROR

Syntax:

ERROR

Purpose:

Defines a body wherein a certain error is expected to happen. The body must be closed with theEND ERROR command.

In the following example, the error message Broken pipe is expected to be received during oneof the three requests:

_ E R RO R " B r o k en p i pe "

_ R EQ l o c al h o st 8 0 80_ _ GE T / f o o H T TP / 1 . 1


_WAIT


_ _ GE T / b a r H T TP / 1 . 1


_WAIT


_ _ GE T / a n d / a n ot h e r / o ne H T TP / 1 . 1


_WAIT

_ E ND E R RO R


71/124

10.18. EXEC 71

10.18 EXEC

Syntax:

EXEC

Purpose:

Executes a shell command. EXEC| will pipe the current socket input stream into the invokedshell command.

Use PIPE for streaming the output of the shell command into the current socket output stream(See section 10.33 on page 86).


72/124


10.19 EXIT

Syntax:

EXIT [OK|FAILED]

Purpose:

Exits with OK or FAILED (default is FAILED).


73/124

10.20. EXPECT 73

10.20 EXPECT

Syntax:

EXPECT .|headers|body|error|exec|var() "|[!]"|

Purpose:

Defines what data is expected to be received, either on the current connection, or the stdout ofan executed program, or in a certain variable. A regular expression is used to define the expecteddata.

Use a preceeding exclamation mark (!) before the regular expression to negate the check.

NOTE: This command does not perform any check yet. The actual check on the data is performedin the following WAIT command.

Example 1: Expect a certain output from an executed binary:

_ E X PE C T e x ec " m y V a lu e "

_ E XE C e c ho m y V al u e

Example 2: Expect a certain value in variable $A:

_ S ET A = m y V al u e

_ E X PE C T v a r ( A ) " m y V a l u e "


74/124


10.21 FLUSH

Syntax:

FLUSH

Purpose:

Flushes the cached lines of data that must be sent in a request.

NOTE: The calculation of the content length value for an AUTO content-length header is performedby this command!


75/124

10.22. FOR 75

10.22 FOR

Syntax:

FOR "|*"|

Purpose:

Allows to define a body of script code (similar to a BLOCK) which is executed once for each of agiven number of elements, similar to for-each constructs of some programming languages.

The elements are in a string, separated by blank characters (spaces). The FOR-body must beclosed with a corresponding END FOR command.

_ FO R I " F i rs t S ec on d T hi rd "

_ D EB U G $ I_ E ND F OR


77/124

10.24. HEADER 77

10.24 HEADER

Syntax:

HEADER ALLOW|FILTER

Purpose:

Defines a filter for incoming request headers. The filter can either be a blacklist ( HEADER FILTER) or a whitelist ( HEADER ALLOW ).

By default, theres no filtering; all headers are allowed.


78/124


10.25 IF

Syntax:

IF ("" [NOT] MATCH "regex")|"" EQUAL ""|("" [NOT]

EQ|LT|GT|LE|GT ")"

Purpose:

Allows to define a body of script code (similar to a BLOCK) which is executed only if the givencondition is true. The condition is based on either a given string which must match a regularexpression or another string, or on a numerical value to be equal, less than or greater than a certainnumber.

The IF-body must be closed with a corresponding END IF command.

String example:

Tests if the given matches the regular expression (that string can be a variable, ofcourse):

_ IF " $ M yV ar " M AT CH " .* x y z .* "

_ C A L L S o m e B l o c k

_ EN D I F

Number example:

Tests if the given containing a numerical value is larger than a given threshold value:

_ IF " $ M yN u mb e r " G T " 15 0 0"

_ C AL L S o m eB l o ck

_ EN D I F


79/124

10.26. IGNORE BODY 79

10.26 IGNORE BODY

Syntax:

IGNORE BODY on|off

Purpose:

Recieves the request body data, but does not store it anywhere or inspect it. This is used forperformance testing.


80/124


10.27 LOG LEVEL

Syntax:

LOG LEVEL

Purpose:

Sets the log level. must be a number from 0 - 4.


81/124

10.28. LOOP 81

10.28 LOOP

Syntax:

LOOP

Purpose:

Allows to define a body of script code (similar to a BLOCK) which is executed times. TheLOOP-body must be closed with a corresponding END LOOP command.

String example:

Calls the block SomeBlock 15 times:

_ LO OP 1 5

_ C AL L S o m eB l o ck

_ E ND L O OP


83/124

10.30. ONLY PRINTABLE 83

10.30 ONLY PRINTABLE

Syntax:

ONLY PRINTABLE on|off

Purpose:

Replaces all characters of ASCII code lower than 32 and higher than 127 with a blank (space)character.


84/124


10.31 OP

Syntax:

OP ADD|SUB|DIV|MUL

Purpose:

Performs a calculation on the two values and , with the given operand:

ADD: Addition

SUB: Subtraction

DIV: Division

MUL: Multiplication

The result is stored in .


85/124

10.32. PID 85

10.32 PID

Syntax:

PID

Purpose:

Stores the current PID into .


86/124


10.33 PIPE

Syntax:

PIPE [chunked []]

Purpose:

Starts a pipe for streaming the output of EXEC into the socket output stream, with optionalchunk support.


87/124

10.34. PLAY 87

10.34 PLAY

Syntax:

PLAY SOCKET | VAR

Purpose:

Plays back recorded data, either on the current socket or into a variable.


88/124


10.35 PRINT HEX

Syntax:

PRINT HEX on|off

Purpose:

Output data is displayed as hex digits.


89/124

10.36. RAND 89

10.36 RAND

Syntax:

RAND

Purpose:

Generates a random number between and and stores the result in .


90/124


10.37 RECORD

Syntax:

RECORD RES [ALL] STATUS | HEADERS | BODY*

Purpose:

Records a response for later replay, or stores it.


91/124

10.38. RECV 91

10.38 RECV

Syntax:

RECV |POLL|CHUNKED|CLOSE [DO NOT CHECK]

Purpose:

Receives an amount of bytes, either specified by the number of bytes to read, or until a sockettimeout will occur in POLL mode.

Optional: DO NOT CHECK does not check the MATCH and EXPECT clauses.

With CHECK this can be done later, over a couple of not yet checked RECVs.


92/124


10.39 RENEG

Syntax:

RENEG [verify]

Purpose:

Starts an SSL renegotiation.


93/124

10.40. REQ 93

10.40 REQ

Syntax:

REQ [:][:] [ ]

Purpose:

Opens a new TCP connection to the given host and port. If the connection exists already, nonew connection will be created.

Parameters:

SSL : Defines the type of SSL connection. Must be one of these values: SSL, SSL2, SSL3 or TLS1.

host : The host name or IPv4 / IPv6 address of the target system. Note: An IPv6 address mustbe enclosed in square brackets!

tag : Setting a tag on a connection allows to open multiple connections to the same target. Ifa connection with the same tag already exists, that connection will be selected (for the followingrequest).

cert-file, key-file, ca-cert-file : Optional; required for SSL connections.


94/124


10.41 RES

Syntax:

RES

Purpose:

Waits for a connection accept. This is used within a SERVER body to receive incoming requestsfrom clients.


95/124

10.42. RESWAIT 95

10.42 RESWAIT

Syntax:

RESWAIT

Purpose:

Combines the RES and the WAIT command, ignoring connections that are not sending any dataat all.


96/124


10.43 RPS

Syntax:

RPS

Purpose:

Defines a code body which limits the maximum number of requests that may be sent duringa certain period of time (specified in number of seconds). The requests are counted during theinvocation of the WAIT command.

The body must be closed with the END RPS command.

The following example limits the number of requests to be sent within the next 300 seconds to20:

_ RP S 2 0 3 00


_ _G ET / H TT P / 1. 1


__

_WAIT

_ E ND R PS


97/124

10.44. SEQUENCE 97

10.44 SEQUENCE

Syntax:

SEQUENCE

Purpose:

Defines a sequence of MATCH or GREP variables which must appear in the given order in theresponse.

With MATCH or GREP, it is possible to define certain values that are expected in a response, oneat a time. But the order of those values within the response is not determined by those commands.In the following example, the MATCH commands make sure that the response contains three stringsone, two and three. And the SEQUENCE command then makes sure that they are in exactthis order within the response:

CLIENT


_ _ GE T / i n d ex . h t m l H T TP / 1 . 1


__

_ M A TC H b o dy " ( o ne ) " f i rs t

_ M A TC H b o dy " ( t wo ) " s e c on d

_ M A TC H b o dy " ( t h re e ) " t h ir d

_ S E QU E N CE f i rs t s e c on d t h ir d

_WAIT

END


98/124


10.45 SET

Syntax:

SET =

Purpose:

Allows to set a variable. See chapter 5 on page 19 for usage examples.


99/124

10.46. SH 99

10.46 SH

Syntax:

SH shell script line or END

Purpose:

Embeds a shell script within a tmp file, and executes it when END is found.


100/124


10.47 SLEEP

Syntax:

SLEEP

Purpose:

Stops execution for the defined amount of time (number of milliseconds).


101/124

10.48. SOCKET 101

10.48 SOCKET

Syntax:

SOCKET

Purpose:

Spawns a socket reader over the next WAIT and RECV commands.

close body with END SOCKET.


102/124


10.49 SOCKSTATE

Syntax:

SOCKSTATE

Purpose:

Stores connection state CLOSED or CONNECTED of the current connection in the variable.


103/124

10.50. SSL BUF 2 CERT 103

10.50 SSL BUF 2 CERT

Syntax:

SSL BUF 2 CERT pem cert

Purpose:

Reads the given buf as a PEM certificate, usable with SSL CERT VAL.


104/124


10.51 SSL CERT VAL

Syntax:

SSL CERT VAL

Purpose:

Extracts a from a certificate which was received with RENEG or VERIFY PEER, andstores it in .

Valid values for are:

M VERSION

M SERIAL

V START

V END

V REMAIN

S DN

S DN

I DN

I DN

A SIG

A KEY

CERT


105/124

10.52. SSL CONNECT 105

10.52 SSL CONNECT

Syntax:

SSL CONNECT SSL|SSL2|SSL3|TLS1 [ ]

Purpose:

Performs an SSL connect on an already existing TCP socket. This is usefule for protocols wherethe SSL handshake is done after some plain text exchange, for example pop3 TLS.

Parameters:


cert-file, key-file : Optional; required for SSL connections.


106/124


10.53 SSL ACCEPT

Syntax:

SSL ACCEPT SSL|SSL2|SSL3|TLS1 [ [ca-cert-file]]

Purpose:

Performs an SSL accept on an already accepted TCP socket. This is usefule for protocols wherethe SSL handshake is done after some plain text exchange, for example POP3 TLS server.

Parameters:


cert-file, key-file, ca-cert-file : Optional; required for SSL connections.


107/124


108/124


10.55 SSL GET SESSION

Syntax:

SSL GET SESSION

Purpose:

Gets the SSL session of this connection and stores it in a variable as a Base64 encoded string.This session can be set with SSL SET SESSION for example to implement session reuse.


109/124

10.56. SSL LEGACY 109

10.56 SSL LEGACY

Syntax:

SSL LEGACY on|off

Purpose:

Turns SSL legacy behaviour on or off for renegotiation (for OpenSSL libraries 0.9.81 and above).


110/124


10.57 SSL SECURE RENEG SUPPORTED

Syntax:

SSL SECURE RENEG SUPPORTED

Purpose:

Tests if the remote peer supports secure SSL renegotiation.


111/124

10.58. SSL SESSION ID 111

10.58 SSL SESSION ID

Syntax:

SSL SESSION ID

Purpose:

Stores the session ID of the current SSL socket in , Base64 encoded. Can be used totest if a SSL socket has a specific ID, for example for a session reuse test.


112/124


10.59 SSL SET SESSION

Syntax:

SSL SET SESSION

Purpose:

Sets the SSL session for the current connection from which must contain a Base64encoded SSL session (stored with SSL GET SESSION).


113/124

10.60. STRFTIME 113

10.60 STRFTIME

Syntax:

STRFTIME "" [Local|GMT]

Purpose:

Stores the given time (in milliseconds) as a string in . The string is formatted asdefined in .


114/124


10.61 SYNC

Syntax:

SYNC

Purpose:

Waits until the next full second is reached. This can be used to synchronize code that is executedin separate threads, such as multiple CLIENTs or a CLIENT and a SERVER.


115/124

10.62. TIME 115

10.62 TIME

Syntax:

TIME

Purpose:

Stores the current time in milliseconds in .


116/124


10.63 TIMEOUT

Syntax:

TIMEOUT

Purpose:

Sets an idle timeout for the current socket in number of milliseconds.


117/124

10.64. TIMER 117

10.64 TIMER

Syntax:

TIMER GET|RESET

Purpose:

Stores the time duration since the last reset, or since the start of the test.

Start measuring time:

Starts time measuring, using the variable $HOLDER to store the result:

_ T I ME R R E SE T $ H O LD E R

Measure time:

This makes the time available as a text string in the variable $HOLDER:

_ T I ME R G E T $ H O LD E R


118/124


10.65 TUNNEL

Syntax:

TUNNEL [:][:] [ []]

Purpose:

Opens a tunnel to the defined host and port, with SSL support. If a connection to that host andport already exists, it will be re-used and no connect will be performed.

Parameters:

Valid parameter values are:

SSL: SSL, SSL2, SSL3, TLS1

tag: The tag of the connection, if multiple connections to the same target host and port areused.

, and are optional, for client/server authentication.


119/124

10.66. URLDEC 119

10.66 URLDEC

Syntax:

URLDEC ""

Purpose:

Stores a URL-decoded string into .


120/124


10.67 URLENC

Syntax:

URLENC ""

Purpose:

Stores a URL-encoded string into .


121/124

10.68. USE 121

10.68 USE

Syntax:

USE

Purpose:

Allows to invoke blocks from the given module without having to specify the module prefix. So,its quite similar to a static import in a Java source file.

For example, assume a htt file that contains a module named UTILITY like this:

M O D UL E U T I LI T Y

B L OC K O N E

...END

B L OC K _ T WO

...

END

Usually, to invoke the block ONE, the code in the actual test script would look like this:

_ C AL L U T I LI T Y : O N E

Instead, with USE the call gets simpler:

_ U SE U T IL I T Y

...

_ C AL L O N E


122/124


Or, in case of the second block named TWO, it can be even simpler (because blocks whose namestarts with an underscore dont need to be invoked with CALL):

_ U SE U T IL I T Y

...

_TWO

So, in a sense, by using modules and naming the blocks with underscores, it is possible to reallycreate custom htt local commands.

10.68.1 Overriding commands

Using this mechanism, its possible to override the existing htt commands (by creating a customWAIT command in a module, for example). However, overriding isnt really a tested feature, so

results can be unpredictable.

For this reason, its not recommended to override existing, real htt commands!


123/124

10.69. WAIT 123

10.69 WAIT

Syntax:

WAIT [


124/124


10.70 WHICH

Syntax:

WHICH

Purpose:

Stores the concurrency number of the current thread in .

htt user's guide

Documents