artillery
artillery copied to clipboard
tough.CookieJar() preventing access to some sites with "Could not parse cookieString" error
Hi!
Firstly, thanks for your work on Artillery! Smart testing framework with simplicity in mind. 👋 🙂
Today I used patch-package to patch [email protected]
for the project I'm working on.
Tests run fail with a summary message errors.cookie_parse_error_invalid_cookie
.
Running with DEBUG="http"
I can see,
| 2022-08-23T18:22:09.276Z http Could not parse cookieString "GUEST_LANGUAGE_ID=es_ES; Domain=.example.net; Expires=Wed, 23-Aug-2023 18:22:09 GMT; Path=/; HttpOnly" from response header, skipping it
2022-08-23T18:22:09.323Z http request: {
"url": "https://mydomain.example.net/",
"method": "GET",
"headers": {
"user-agent": "Artillery (https://artillery.io)"
}
Here is the diff that solved my problem:
diff --git a/node_modules/artillery/core/lib/engine_http.js b/node_modules/artillery/core/lib/engine_http.js
index fb72c99..588fd55 100644
--- a/node_modules/artillery/core/lib/engine_http.js
+++ b/node_modules/artillery/core/lib/engine_http.js
@@ -776,7 +776,7 @@ HttpEngine.prototype.setInitialContext = function (initialContext) {
initialContext._defaultStrictCapture = this.config.defaults.strictCapture;
- initialContext._jar = new tough.CookieJar();
+ initialContext._jar = new tough.CookieJar(undefined, false);
initialContext._enableCookieJar = false;
// If a default cookie is set, we will use the jar straightaway:
if (typeof this.config.defaults.cookie === 'object') {
This issue body was partially generated by patch-package.
hi @theTestTube, thank you for the bug fix!
I'm not sure why that change solves the issue though 🤔 Looking at the CookieJar
API, passing undefined
as the first argument should make it default to using in-memory cookie storage, which it's doing already. Passing false
as the second parameter presumably is ignored by the constructor as it expects an object, so the behavior should be the same.
Docs here: https://github.com/salesforce/tough-cookie#cookiejarstore-options
Passing undefined
as first argument in order to pass this second options
false argument.
I think you should guess which of the true/false options (rejectPublicSuffixes
, looseMode
, prefixSecurity
, allowSpecialUseDomain
) could be causing this or, at least, allow Artillery configure the respective though-cookie options.
Otherwise we should be guessing why a production-ready application (and no incidents or problems for cookie validation in our current browsers) fails on Artillery tests due to too-restrictive cookie validation.
Cheers.-
Thanks for the suggestion to add ability to customize cookie parsing behavior. It has been implemented in #1581 now.
For your specific error though - I set up a mock endpoint that sends back a set-cookie
header with the value you shared, and that works fine with the most recent version of Artillery, i.e. without your patch or without setting any extra cookie parsing options.
Can you try running curl
on the exact same URL that is producing errors for you with Artillery and see if curl
is parsing the cookie successfully under the same conditions? curl --cookie-jar jar.txt <url>
and then cat jar.txt
.
Otherwise we should be guessing why a production-ready application (and no incidents or problems for cookie validation in our current browsers)
Artillery's default HTTP engine does not attempt to mimic a browser. Not sure if you've seen it but Artillery supports load testing with real Chrome browsers via https://github.com/artilleryio/artillery-engine-playwright. Might be a good fit for some of your testing?