[Bug Report]: AppGateway Request and Response buffers default in module

[ramuvr]

Describe the bug

As per MS Doc, the value for buffers should default to true.

"By default, both Request and Response buffers are enabled on your Application Gateway resource but you can choose to configure them separately."

To reproduce

Access file modules\network\application-gateway\main.bicep and see code snippet values

Code snippet

@description('Optional. Enable request buffering.')
param enableRequestBuffering bool = false

@description('Optional. Enable response buffering.')
param enableResponseBuffering bool = false

Relevant log output

No response

[AlexanderSehr]

Hey @ramuvr , thank you for opening this back and thank you for providing the docs reference.
If I understand you correctly, all this takes is changing both buffering switches to true to align with the best-practices? If so, we can certainly do that.

[ramuvr]

Hey @ramuvr , thank you for opening this back and thank you for providing the docs reference. If I understand you correctly, all this takes is changing both buffering switches to true to align with the best-practices? If so, we can certainly do that.

Yes, @AlexanderSehr that's my understanding. Deployed couple of appGateways recently without the attribute and noticed they were false but our template had default value so what-if was reporting I was going to change them.

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[AlexanderSehr]

Hey @ilhaan,
I just migrated this issue over from CARML. Please take a look and triage if still relevant :)

[ilhaan]

@AlexanderSehr I will take a look

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.

[AlexanderSehr]

Hey @ilhaan, please triage the issue when you get the chance :)

[ilhaan]

@AlexanderSehr So the MS doc linked in the original issue by @ramuvr does say that request and response buffers are enabled by default. However, it also does say this:

You can keep either the Request or Response buffer, enabled or disable, based on your requirements and/or the observed performance of the client systems that communicate with your Application Gateway.
Warning
We strongly recommend that you test and evaluate the performance before rolling this out on the production gateways.

The change to make these default to true is simple, but I am concerned about the impact it can have on users of the module who are using the current default of false when they upgrade to a new published version after we publish this update.

I see us having two options in this situation:

1. Remove the default false and force users to explicitly define a value for this so they are aware and can make a decision on their own.
2. Change major version so that users know there is a major change to this config. Not sure how we've been handling such changes in AVM and a quick search through AVM docs does not bring up info on versioning.

Please let me know your thoughts @AlexanderSehr

[AlexanderSehr]

Hey @ilhaan,
thanks for the research. Regarding the versioning we'd go with semver - if - we're already on 1.0. However, as we're not, breaking changes are treated as 'minor' version updates. So we'd update the version.json from let's say 0.2 to 0.3.

To the topic at hand - if they're enabled by default then I'm inclined to recommend setting them to enabled as well. But I can't say that I know the service well enough to judge the implications. Ultimately, it would be up to you.
Mind you, this is just an issue we carried over from CARML to finally get around and properly triage it. If in doubt, you're more than welcome to close it as 'not planned' with the reasoning you've given above. No pressure 💪