feat(http-add-on): Add appProtocol support for interceptor admin and TLS service ports

[gyanesh-mishra]

Add configurable appProtocol for the interceptor's admin and TLS service ports.

Closes #828

Changes

New Helm Values

Value	Default	Description
interceptor.admin.appProtocol	""	appProtocol for the admin service port
interceptor.tls.appProtocol	""	appProtocol for the TLS proxy service port

interceptor.proxy.appProtocol already existed — no changes there.

Template Changes

• templates/interceptor/service-admin.yaml — adds optional appProtocol field
• templates/interceptor/service-proxy.yaml — adds optional appProtocol field for the TLS port, independent of proxy.appProtocol

Documentation

• README.md regenerated with helm-docs

Backward Compatibility

Default empty values maintain current behavior. Note: proxy.appProtocol no longer implicitly applies to the TLS port — the two ports are now independently controlled.

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• README is updated with new configuration values learn more
• A PR is opened to update KEDA core (repo) (not applicable — chart-only change)

Fixes #828

[gyanesh-mishra]

@JorTurFer @zroubalik — updated this PR to also cover the admin service (port name + appProtocol), regenerated docs with helm-docs, and squashed into a single DCO-signed commit. Would appreciate a review when you get a chance!

[linkvt]

Hi @gyanesh-mishra ,
thanks for the PR, looks good to me in general!

I have two questions/notes:

1. isn't adding the appProtocol enough? If you set a helm value to change the port name it would be the same effort to just set the appProtocol, right? We could add a tls.appProtocol and drop the portName overrides IMO to reduce the surface area
2. It would IMO be good if the comment would be more generic and not link to a specific service mesh like istio in this case

[gyanesh-mishra]

Thanks for the review @linkvt!

On point 1 (appProtocol vs portName): You're right that appProtocol alone is sufficient for Istio. However, other service meshes may rely on port naming conventions rather than (or in addition to) appProtocol for protocol detection. I was being proactive in allowing both to be configured to maximize compatibility across different mesh implementations.

That said, if you'd prefer to keep the surface area smaller, I'm happy to reduce this PR to just appProtocol support (adding tls.appProtocol and admin.appProtocol) and follow up with a separate PR for the portName overrides. Let me know your preference!

On point 2 (generic comments): Agreed! I've updated the comments to remove the Istio-specific links — they now just say "Useful for service mesh protocol selection" with example values. Pushed the update just now.

[linkvt]

Hi @gyanesh-mishra ,

I understand but would prefer to limit this change for now to the appProtocol fields, I'm a big fan of YAGNI 🙂
I did a quick research and Istio, Linkerd or Cilium seem to use appProtocol - from the ones I looked at only istio seems to use the portName which is why I think the appProtocol is fine.

Thanks already for the change of the description!

[gyanesh-mishra]

Thanks @linkvt! Updated the PR to drop all portName overrides and limit the change to appProtocol fields only:

• interceptor.admin.appProtocol (new)
• interceptor.tls.appProtocol (new)
• interceptor.proxy.appProtocol already existed — untouched

Made tls.appProtocol independent of proxy.appProtocol since the two ports would typically take different values (e.g. http vs https). README regenerated with helm-docs.

[linkvt]

Hi @gyanesh-mishra , thanks the changes look good!
I (ab-)used my permissions and force-pushed into this PR to a) rebase on main and b) add a fallback to the tls port appProtocol to use the default one if it is set to not break the existing behavior.
I thought this is easier than us going back and forth for that minor change, hope you don't mind!

[linkvt]

CI failure is unrelated and caused by the merge of kedacore/http-add-on#1532 - this will be handled in #835

[gyanesh-mishra]

Thank you!