Your JoeDog has fixed a glaring bug! Cookie persistence was failing from one run to the next when siege was invoked with -g/–get. We often use this feature for debugging web programs and we’re surprised this failure remained hidden for so long. Cookies are persistent at the user level in $HOME/.siege/cookies.txt When siege was run as ‘siege -g <URL>’ it stored persistent cookies in that file. But when it was invoked a second time, it didn’t return it.
Huh? That’s what we said! Here’s the thing: In its primary role as a load tester, siege runs on a thread pool. It matched cookies with individual threads (or users, as we like to call them). In -g/–get mode the IDs didn’t recognize the main thread so the cookie was never returned. Version 4.1.2 fixes that.
This version also removes the stat summary when it’s run with -g/–get The purpose of that mode is for debugging headers for HTTP configurations and debugging code for web development. The stats are important in that mode and they remove valuable console real estate. If you need one-user stats, run it with one user like this: ‘siege -c1 –reps=once <URL>’
This version also fixes several typos. Thanks, Cui Fliter.