You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected:
Cookies are provided in request headers when running folders
Example:
First response will set cookie (in example: response header includes "< set-cookie: _gh_sess=..." )
Second response will not set a cookie as it should already be provided
Actual.
Cookies are not provided when running folders
Example:
First response of GET https://github.com sets session cookie (in example: response header includes "< set-cookie: _gh_sess=..." )
Second response of GET https://github.com also sets session cookie, eventhough it was already set before (in example: response header includes "< set-cookie: _gh_sess=..." )
If I run the requests one by one instead of running the folder, the cookie management works as expected.
I have checked the following:
Describe the bug
If I run all requests of a folder, the cookie management does not work same as when I run the requests one by one
Steps to reproduce with a simple example:
Expected:
Cookies are provided in request headers when running folders
Example:
First response will set cookie (in example: response header includes "< set-cookie: _gh_sess=..." )
Second response will not set a cookie as it should already be provided
Actual.
Cookies are not provided when running folders
Example:
First response of GET https://github.com sets session cookie (in example: response header includes "< set-cookie: _gh_sess=..." )
Second response of GET https://github.com also sets session cookie, eventhough it was already set before (in example: response header includes "< set-cookie: _gh_sess=..." )
If I run the requests one by one instead of running the folder, the cookie management works as expected.
.bru file to reproduce the bug
Attached example collection with example requests and a test in the second
Cookie Folder Run Test.zip
Screenshots/Live demo link
see provided bruno collection in attachments to reproduce the bug.
The text was updated successfully, but these errors were encountered: