Handling CORS Issues in FrankenPHP with Mixed Local and Stage Requests

[g-ra]

We are using
Apiplatform 3.3.11

Background:
In our staging environment, we encounter a recurring issue with FrankenPHP that seems to occur every 20th request. The frontend team develops locally, sending requests from localhost:3000 to the staging backend, while the staging frontend also sends requests to the same backend. To ensure proper operation, we configure CORS in NelmioCorsBundle with the following setting:

CORS_ALLOW_ORIGIN="^(https|http)?://(localhost|127.0.0.1|stage.sales.qwe.ru)(:[0-9]+)?$"

Observed Issue:
Approximately every 20th request fails during local development and on the staging environment. It appears that FrankenPHP might be pooling requests from both localhost:3000 and the staging environment (stage.sales.qwe.ru). The failed requests seem to return incorrect CORS headers, such as Allow: localhost:3000, when the response is meant for staging.

Questions for Discussion:

Preventing Worker Pool Mixing:

How can we configure FrankenPHP to segregate worker pools based on the source of requests? Specifically, how can it differentiate requests originating from localhost:3000 versus those from stage.sales.qwe.ru?

Switching Workers to CGI Mode:

Is it possible to switch FrankenPHP’s mode of operation from worker-based to CGI? If so, what are the recommended steps to achieve this?

CORS Header Configuration:

Beyond setting Access-Control-Allow-Origin: *, what are the best practices to ensure correct CORS headers are served based on the request’s origin? Can FrankenPHP or Caddy help dynamically adjust CORS headers for each request?

Current FrankenPHP and Caddy Configuration:
Here is the configuration we are currently using:

Caddy Configuration

{
    {$CADDY_GLOBAL_OPTIONS}

    frankenphp {
        {$FRANKENPHP_CONFIG}
    }

    # https://caddyserver.com/docs/caddyfile/directives#sorting-algorithm
    order mercure after encode
    order vulcain after reverse_proxy
    order php_server before file_server

    servers {
        metrics
    }

    cache {
        allowed_http_verbs GET
        mode bypass
        api {
            prometheus
            souin
        }

          timeout {
              backend 20s
              cache 200ms
          }
      }

    log {
        output file /var/log/caddy/caddy_main.log {
            roll_size 100MiB
            roll_keep 5
            roll_keep_for 100d
        }
        format json
        level INFO
    }

    admin 0.0.0.0:2019
}

{$CADDY_EXTRA_CONFIG}

{$SERVER_NAME:localhost} {
    log {
        # Redact the authorization query parameter that can be set by Mercure
        format filter {
            request>uri query {
                replace authorization REDACTED
            }
        }
    }

    cache
    root * /app/public
    encode zstd br gzip

    mercure {
        # Transport to use (default to Bolt)
        transport_url {$MERCURE_TRANSPORT_URL:bolt:///data/mercure.db}
        # Publisher JWT key
        publisher_jwt {env.MERCURE_PUBLISHER_JWT_KEY} {env.MERCURE_PUBLISHER_JWT_ALG}
        # Subscriber JWT key
        subscriber_jwt {env.MERCURE_SUBSCRIBER_JWT_KEY} {env.MERCURE_SUBSCRIBER_JWT_ALG}
        # Allow anonymous subscribers (double-check that it's what you want)
        anonymous
        # Enable the subscription API (double-check that it's what you want)
        subscriptions
        # Extra directives
        {$MERCURE_EXTRA_DIRECTIVES}
    }

    vulcain

    # Add links to the API docs and to the Mercure Hub if not set explicitly (e.g. the PWA)
    header ?Link `</docs.jsonld>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation", </.well-known/mercure>; rel="mercure"`
    # Disable Topics tracking if not enabled explicitly: https://github.com/jkarlin/topics
    header ?Permissions-Policy "browsing-topics=()"

    # Matches requests for HTML documents, for static files and for Next.js files,
    # except for known API paths and paths with extensions handled by API Platform
    #@pwa expression `(
    # 		header({'Accept': '*text/html*'})
    #		&& !path(
    #			'/docs*', '/graphql*', '/bundles*', '/contexts*', '/_profiler*', '/_wdt*',
    #			'*.json*', '*.html', '*.csv', '*.yml', '*.yaml', '*.xml'
    #		)
    #	)
    #	|| path('/favicon.ico', '/manifest.json', '/robots.txt', '/sitemap*', '/_next*', '/__next*')
    #	|| query({'_rsc': '*'})`

    # Comment the following line if you don't want Next.js to catch requests for HTML documents.
    # In this case, they will be handled by the PHP app.
    # reverse_proxy @pwa http://{$PWA_UPSTREAM}

    @blocked {
       path /docs/*
       path /templates/*
    }
    respond @blocked 403

FROM frankenphp_base AS frankenphp_prod

ENV APP_ENV=prod
ENV FRANKENPHP_CONFIG="worker.enabled=0"

RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

COPY --link frankenphp/conf.d/app.prod.ini $PHP_INI_DIR/conf.d/
COPY --link frankenphp/worker.prod.Caddyfile /etc/caddy/worker.Caddyfile

Objective:
Our goal is to:

Resolve the intermittent CORS issue without resorting to overly permissive settings like Access-Control-Allow-Origin: *.

Understand and, if necessary, modify FrankenPHP’s request handling to prevent mixing of request pools.

Explore alternatives to worker mode for handling PHP requests to avoid these conflicts.

Your insights and recommendations would be invaluable in helping us address this challenge effectively.

its ok

i dont understand what is it

[AlliBalliBaba]

Looking at your configuration, it doesn't seem like worker mode is enabled (to enable it you have to define a worker script).
Wrong hosts in CORS headers usually come from serving a cached request with cached headers. It's always best to handle CORS at the outermost possible layer of your architecture. Is your server maybe behind a CDN? Or does souin somehow cache the header?

[withinboredom]

CORS_ALLOW_ORIGIN="^(https|http)?://(localhost|127.0.0.1|stage.sales.qwe.ru)(:[0-9]+)?$"

Are you setting this via an environment variable by chance? There's a really weird PHP bug that I've been chasing down off-and-on for months now. If so, are you using getenv() or $_ENV?

The bug I am chasing down in php-src and it looks like this (though this simple of a script won't reproduce the issue, otherwise I'd have fixed it by now):

echo $_ENV['SOME_VAR'];

function test() {
  echo $_ENV['SOME_VAR'];
}

test();

Two different values will be output from other threads, and it only affects $_ENV accesses, getenv seems to work fine.