✅ Deploy Preview for chimerical-kitsune-a0bfa0 ready!

Name	Link
🔨 Latest commit	714c5b4
🔍 Latest deploy log	https://app.netlify.com/projects/chimerical-kitsune-a0bfa0/deploys/6827b6d248ffb400089ab1fe
😎 Deploy Preview	https://deploy-preview-327--chimerical-kitsune-a0bfa0.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Hi, thanks for the PR. This seems like a really good implementation.

I have one change required:

It also works on folders (or any parent) and the headers will follow the hierarchy order, that is, if a folder defines a header named X-Custom-Header as x-value and a request inside that folder defines X-Custom-Header as y-value the end request will have the header x-value, y-value (the parent is defined first)

The issue is a lot of people use parent and child relationship to override headers / envs. Here the behavior changes to merge.

Parent:
Header1: Value1

Child:
Header1: Value2

Final Before:
Header1: Value2

^ This is useful when most requests in the folder have the same header value but one request needs a different value.

Final Now:
Header1: Value1, Value2

We can retain the original behavior as is (to prevent breaking existing assumptions) and provide a setting to enable the new behavior. So parent header and child header gets merged together instead of overridden.

This actually makes a lot of sense

^ This is useful when most requests in the folder have the same header value but one request needs a different value.

Would the following "business rule" capture this requirement? if the same header is defined multiple times either on the child or the parent the values are merger, but the parent will always override the child value

An example would be:

• Parent:
  • Header1: Value1
  • Header1: Value2
  • Header6: Value9
• Child:
  • Header1: Value3
  • Header42: Value3
  • Header42: Value4
  • Header6: Value-X
  • Header4: Value20

result:

{
  "header1": "Value1, Value2", //parent headers merged, child header ignored
  "header42": "Value3, Value4", //child headers merged
  "header6": "Value9",
  "header4": "Value20"
}

In Restfox, the child always takes precedence, so the above would not be correct. Child gets the final say in what headers it will use, as the request is initiated from the child's side.

The requirement would be: if the same header is defined multiple times either on the child or the parent the values are merged, but the child will always override the parent value

Parent:
Header1: Value1
Header1: Value2
Header6: Value9
Header7: Value10

Child:
Header1: Value3
Header42: Value3
Header42: Value4
Header6: Value-X
Header4: Value20

result:

{
  "header1": "Value3", // parent header ignored, as child is overriding it
  "header42": "Value3, Value4", // child headers merged
  "header6": "Value-X", // child header overrides parent
  "header4": "Value20", // child header overrides parent
  "header7": "Value10" // inherited from parent
}

The requirement would be: if the same header is defined multiple times either on the child or the parent the values are merged, but the child will always override the parent value

Yeah, off course LMAO I did the same mistake again, sorry. Now I get it!

Here is a test case based on the earlier example

Looks good! I'll run some manual tests today and we should be good to merge.

Seeing this difference when a header value contains comma.

Ours:

Postman:

Insomnia:

I can't tell if we're wrong or if they're wrong :D

As these are the 2 most used http clients, I feel like we should maybe err on their side.

Judging by the output of insomnia and postman, I assume that they are interpreting 2, cassasa as a list of two values, not a single value.

In my opinion, that's not the most semantic interpretation. If a user defines the same header multiple times, I’d assume they’re intentionally creating a list. In such case I think each individual value should be treated as-is. So if one of the values contains a comma, I think it makes more sense to preserve it as a single value (by quoting it), rather than splitting it further.

That being said, I’m honestly not sure how most HTTP header parsers behave in these cases, it may vary, maybe some treat everything as a flat list regardless, if I'm not mistaken express.js does that, everything becomes just a single string.

Now, it is an important observation that insomnia and postman use the simpler implementation of just combining the values, ignoring whether commas are part of a value (I assume they also ignore the leading space case). If conformity with those clients is a priority, it makes sense to drop the quoting behavior for consistency.

Ultimately, I think you are much more suited to make this decision. I’m not fully aware of the broader goals of the project, especially in terms of how closely we want to mirror the behavior of other clients.

I think your implementation is the semantically correct one but I think we should go with the same approach as postman and insomnia to avoid breaking expectation of users.

Some users might already be using comma separated header values to pass multiple header values in a single header, so our new implementation would break this.

Now the header value is passed as typed, no transformations are applied.

Thank you. Looks good. Will merge.