Open Rarst opened 2 years ago
Try opcache.restrict_api=C:/server
; that should work for Apache.
I'm not totally convinced that OPcache should automatically care about that slash vs. backslash issue. Maybe we just should document it.
Yes, changing slash makes it work for my Apache (and breaks it for CLI accordingly).
I think that is extra confusing, since then it visibly doesn't match __FILE__
as reported by PHP.
In general I would expect paths to be normalized for any comparison purposes, but I am not familiar what's the practices are in PHP code base.
P.S. for the context my use case started as implementing a check for this for systems I don't control (WordPress plugin), rather than just configuring something of my own.
In general I would expect paths to be normalized for any comparison purposes, but I am not familiar what's the practices are in PHP code base.
For apache2handler, the internal SG(request_info).path_translated
is set from what Apache reports, without any modifications. And apparently, Apache prefers slashes as directory separator, even if configured otherwise. Not sure if we should change the slashes to backslashes there.
I'm not totally convinced that OPcache should automatically care about that slash vs. backslash issue. Maybe we just should document it.
Since opcache.restrict_api
is an allowed path (rather than a denied path), I think that we should not try to transform it or to compare it in a lose way. Agreed that we should document it.
Reclassifying as documentation problem according to @arnaud-lb's comment above.
Description
I observe an issue when correct
opcache.restrict_api
setting isn't correctly applied when run through an Apache (2.4.52) web server.The following code:
Non-matching path, CLI (correct, warning)
Non-matching path, web server (correct, warning)
Matching path, CLI (correct, no warning)
Matching path, web server (INCORRECT, warning)
PHP Version
8.1.2
Operating System
Windows 10