Requests wrongly reusing headers from previous requests?

[kuikiker]

I converted a postman collection to K6 but I cannot properly run it. After analysing the HTTP requests with Fiddler I noticed that some requests are wrongly reusing headers from previous requests. For instance:

1. Request to /login (user/pass)-> OK (no Content-Type is specified so the default and correct application/x-www-form-urlencoded value is sent).
2. Request to /endpoint1 using an Authorization bearer header obtained from the previous request. -> OK
3. Another request to /login (which is a verbatim copy of the first request) -> FAIL, due to wrong headers (Content-Type: application/json & Authorization: Bearer xxxxxxxx) that seems to be coming from the previous request to /endpoint1

Is there something I can do to avoid this behaviour? I have tried to manually add the Content-Type: application/x-www-form-urlencoded header to the /login requests but the second request to the /login still fails due to the incorrect Authorization: bearer xxxxxxxx header, even though a 'basic' auth is defined for these requests.

Thanks

[thim81]

hi @kuikiker

A lot of these things you mentioned often are linked to the Postman collection. Would it be possible to share the Postman collection (with fake credentials), so we can see what happens in the Postman collection and what K6 scripts are generated.

[kuikiker]

Hi @thim81 , I have left the bare minimum of my Postman collection; using fake credentials and only leaving the requests until the second try to /login fails (wrong Content-Type & Authorization headers)

Find attached the Postman collection and the generated K6 script (where I only commented the setTimeout function which is not recognized).

postmanToK6.zip

[thim81]

hi @kuikiker I havent gotten around to look into this, apologies. I hope to find some time in the coming weeks.

[furiousdog]

I have the same problem with X-Client-Id header in my scenario. It might only be fixed if I set the value to null.

[thim81]

hi @kuikiker @furiousdog

Is this still happening?

[titanzx]

hi @kuikiker @furiousdog

Is this still happening?

Yes it is

[thim81]

hi @titanzx

We tried to reproduce it with the sample provided but it looked OK.

Do you have a simple example that you can share, that we can use for reproducing it? It would be helpful to have a simple Postman collection, the postman-to-k6 settings and the expected, correct output.

[titanzx]

hi @titanzx

We tried to reproduce it with the sample provided but it looked OK.

Do you have a simple example that you can share, that we can use for reproducing it? It would be helpful to have a simple Postman collection, the postman-to-k6 settings and the expected, correct output.

Postman Collection

K6 Script

  group("Block3", function() {
    group("KYC_PDPA", function() {
      postman[Request]({
        name: "KYC",
        id: "b7bbf1c8-650a-42e3-a400-01a50c8a7fc7",
        method: "GET",
        address: "{{https}}{{host}}{{url_kyc}}",
        headers: {
          "X-Correlation-Id": "{{$randomUUID}}",
          TimeStamp: "{{timestamp}}",
          "Content-Signature": "{{signature_key}}"
        },
        pre() {
        },
        post(response) {
          var json = pm.response.json();

          pm.test("Message should be success", function() {
            pm.expect(json.status.message).to.eql("success");
          });

          pm.test("Status code is 200", function() {
            pm.expect(pm.response.code).to.eql(200);
          });
        },
        auth(config, Var) {
          config.headers.Authorization = `Bearer ${pm[Var]("access_token")}`;
        }
      });

      postman[Request]({
        name: "PDPA",
        id: "6b1a5943-3e7a-4b28-9296-438f62f2e9ec",
        method: "GET",
        address: "{{https}}{{host}}{{url_pdpa}}",
        headers: {
          "X-Correlation-Id": "{{$randomUUID}}",
          TimeStamp: "{{timestamp}}",
          "Content-Signature": "{{signature_key}}"
        },
        pre() {
        },
        post(response) {
          var json = pm.response.json();

          pm.test("Message should be success", function() {
            pm.expect(json.status.message).to.eql("success");
          });

          pm.test("Status code is 200", function() {
            pm.expect(pm.response.code).to.eql(200);
          });
        },
        auth(config, Var) {
          config.headers.Authorization = `Bearer ${pm[Var]("access_token")}`;
        }
      });
    });
  });

  group("Block3.5", function() {
    group("My_Widget", function() {
      postman[Request]({
        name: "My_Tax",
        id: "071d6899-2800-4ee7-b56b-97379a035eb6",
        method: "POST",
        address: "{{https}}{{host}}{{url_my_widget}}",
        data:
          '{\n    "isLogin": true,\n    "widget_id": "0",\n    "callFrom": "my-tax"\n}',
        headers: {
          "X-Correlation-Id": "{{$randomUUID}}",
          deviceId: "{{deviceIdEncrypt}}",
          Timestamp: "{{timestamp}}"
        },
        pre() {
        },
        post(response) {
          var json = pm.response.json();

          pm.test("Message should be success", function() {
            pm.expect(json.status.message).to.eql("success");
          });

          pm.test("Status code is 200", function() {
            pm.expect(pm.response.code).to.eql(200);
          });
        }
      });
    })
  })

K6 Log

[thim81]

hi @titanzx

I rebuild your postman collection but it seems to properly render the headers.

In attachment, you can find the result. k6-result.zip.zip

Can you point out what is incorrect?

[titanzx]

hi @titanzx

I rebuild your postman collection but it seems to properly render the headers.

In attachment, you can find the result. k6-result.zip.zip

Can you point out what is incorrect?

The request does not include an authorization header, but when the request is executed, the authorization is automatically added from previous request authorization header

[thim81]

I was focussed on the K6 script, but not on the K6 execution. I spotted just now what you mean:

Thanks for helping to understand this unexpected behaviour.

I'll further investigate, to try to find the source.

[thim81]

@titanzx and @kuikiker Found the cause and just released a new version 1.12.0 that should solve your issue. Before the fix, the headers were passed along as options, which made that they were passed along between requests.

Can you update your project to use postman-to-k6 1.12.0 and verify if your issue is resolved?

[daniel-gonzaleza]

Hey @thim81, found this thread while investigating an issue in our executions where headers used on some requests were being incorrectly reused by later requests. Updating to version 1.12.0 fixed the issue for us.

[thim81]

@daniel-gonzaleza thanks for the validation and confirmation.

I ll close the issue, based on your feedback.

If you experiencing other issues, please do report them so we can investigate and improve postman-to-k6