in_http: allow empty Origin header requests to pass CORS checks

[dlackty]

Which issue(s) this PR fixes:

What this PR does / why we need it:
Some requests, such as those made by apps, certain automated scripts, or older browsers, may not include an Origin header. Previously, such requests were blocked by the CORS check, even though they may not necessarily be cross-origin.

For CORS, the server is responsible for reporting the allowed origins. The web browser is responsible for enforcing that requests are only sent from allowed domains. So this change updates the CORS handling logic to allow requests with an empty Origin header to pass, ensuring compatibility with legitimate non-browser clients while maintaining security.

Docs Changes:
fluent/fluentd-docs-gitbook#574

Release Note:
The same as the title.

[daipom]

@dlackty Thanks for this PR!
I will review this soon.

[daipom]

For CORS, the server is responsible for reporting the allowed origins. The web browser is responsible for enforcing that requests are only sent from allowed domains.

I see.
I am not familiar with CORS, but it certainly seems to be true.
CORS does not protect the server.
The browser makes the decision on whether to allow the communication.

Given this CORS specification, this in_http's specification, which returns 403 depending on cors_allow_origins, would not necessarily be required.
So, it would be possible to relax the condition as this PR.

On the other hand, it would also be possible that in_http intentionally checks the condition strictly, although it is not a CORS specification.
If there is a possibility that some users are intentionally using the current strict feature, it may be better not to change the default behavior in order to keep compatibility.

I would like to hear opinions on this point.

Note:

• https://docs.fluentd.org/input/http#cors_allow_origins

  • If you set ["domain1", "domain2"] to cors_allow_origins, in_http returns 403 to access from other domains.

  • Looks like in_http intentionally checks the condition strictly, although it is not a CORS specification.
• in_http improvements #473
  • Looks like it was initially implemented not as a CORS, but simply as a allow list. It doesn't look like this was intentional.
• Add 'Access-Control-Allow-Origin' to in_http plugin #882
  • Looks like the proper CORS behavior was added later.

[daipom]

At least, there would be no problem to relax the condition like this PR.
(In the first place, I don't think it is necessary to return 403.)

I will wait a while, and if there are no objections, I will merge this.
Thanks!

[dlackty]

Suggestion: To avoid breaking compatibility while still allowing requests with an empty Origin header, we could consider allowing cors_allow_origins to include nil as a valid value.

For example:

cors_allow_origins [nil, "example.com", "another-domain.com"]

This way:
• Existing strict behavior remains unchanged by default.
• Users who explicitly want to allow empty Origin headers can opt in by adding nil.
• This keeps the logic flexible without affecting current users who rely on the strict enforcement.

Would love to hear your thoughts on this approach! 🚀

[daipom]

I see! Thanks!
So, we have a workaround. We can use this workaround for the current version.

Even if we have a workaround, I see no problem with this change.

If anyone has a different opinion, please let me know.
I will wait a while, and if there are no objections, I will merge this for v1.19.0.

[daipom]

Thanks @dlackty !