Welcome @twoGiants! It looks like this is your first PR to knative/eventing 🎉

Hi @twoGiants. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

I think it works with strict (for TLS)? (see: #8705 (comment))

So wondering why than not when TLS is disabled (which is not recommended)

/ok-to-test

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.19%. Comparing base (903c74c) to head (e502127).
⚠️ Report is 2 commits behind head on main.

@@            Coverage Diff             @@
##             main    #8727      +/-   ##
==========================================
- Coverage   50.22%   50.19%   -0.03%     
==========================================
  Files         409      409              
  Lines       26659    26662       +3     
==========================================
- Hits        13390    13384       -6     
- Misses      12430    12436       +6     
- Partials      839      842       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I think it works with strict (for TLS)? (see: #8705 (comment))

So wondering why than not when TLS is disabled (which is not recommended)

I think I mentioned it in our call but just to have it also documented here. The reason is that the in-memory channel dispatcher creates two handlers => httpHandler and httpsHandler. And the httpHandler is the one who receives the request without TLS. So when OIDC is enabled (and only then 😺 ) it uses internally the ParseChannelFromHost function to extract the channel name from the host broker-kne-trigger-kn-channel.namespace-1.svc.cluster.local and fails to do so correctly because it fails to take the k8 service name suffix -kn-channel into account.

So when OIDC is enabled (and only then 😺 ) it uses internally the ParseChannelFromHost function to extract the channel name from the host broker-kne-trigger-kn-channel.namespace-1.svc.cluster.local and fails to do so correctly because it fails to take the k8 service name suffix -kn-channel into account.

@twoGiants this seems likely to be the problem to me - why are we switching the parsing for this case in particular?

So when OIDC is enabled (and only then 😺 ) it uses internally the ParseChannelFromHost function to extract the channel name from the host broker-kne-trigger-kn-channel.namespace-1.svc.cluster.local and fails to do so correctly because it fails to take the k8 service name suffix -kn-channel into account.

@twoGiants this seems likely to be the problem to me - why are we switching the parsing for this case in particular?

I think the switch comes as we might setup two servers: one for http (which uses the host based name detection) and one for https (which uses the path based name detection) (see #6865).

So when OIDC is enabled (and only then 😺 ) it uses internally the ParseChannelFromHost function to extract the channel name from the host broker-kne-trigger-kn-channel.namespace-1.svc.cluster.local and fails to do so correctly because it fails to take the k8 service name suffix -kn-channel into account.

@twoGiants this seems likely to be the problem to me - why are we switching the parsing for this case in particular?

Yeah and to add to @creydr answer => we don't have the full path in the request when the httpHandler is triggered, there request.URL.Path is / so we can't parse the channel name from it.

/ok-to-test

/test reconciler-tests

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: creydr, twoGiants

The full list of commands accepted by this bot can be found here.

The pull request process is described here

infra issue...
/test upgrade-tests

    magic.go:135: failed to wait for resources to be deleted: timed out waiting for the condition
    logger.go:146: 2025-09-24T14:22:56.809Z	DEBUG	milestone/emitter_log.go:117	Finished: Failed	{"test": "TestIntegrationSourceWithSinkRef", "namespace": "test-zotfctds"}
    logger.go:146: 2025-09-24T14:22:56.947Z	INFO	milestone/emitter_log.go:149	Events (119) dump written to: /logs/artifacts/events-dump.4155021939.json	{"test": "TestIntegrationSourceWithSinkRef", "namespace": "test-zotfctds"}
--- FAIL: TestIntegrationSourceWithSinkRef (394.10s)

unrelated (flake)
/test reconciler-tests

/cherry-pick release-1.18

@twoGiants: #8727 failed to apply on top of branch "release-1.18":

Applying: fix: extract channel service suffix into constant
Using index info to reconstruct a base tree...
M	pkg/channel/event_receiver.go
M	pkg/channel/event_receiver_test.go
M	pkg/reconciler/inmemorychannel/dispatcher/inmemorychannel_test.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/reconciler/inmemorychannel/dispatcher/inmemorychannel_test.go
Auto-merging pkg/channel/event_receiver_test.go
CONFLICT (content): Merge conflict in pkg/channel/event_receiver_test.go
Auto-merging pkg/channel/event_receiver.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 fix: extract channel service suffix into constant

/cherry-pick release-1.19

@twoGiants: new pull request created: #8777