# Bug in RockyLinux 8 (Apache+mod\_proxy\_fcgi+php-fpm)

**URL:** <https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404>\
**Category:** Rocky Linux Help & Support\
**Tags:** rocky-linux-8\
**Created:** [November 6, 2024, 6:00pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404 "2024-11-06T18:00:21Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Screenerco](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@Screenerco](https://forums.rockylinux.org/u/Screenerco)\
**Post date:** [November 6, 2024, 6:00pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/1 "2024-11-06T18:00:21Z")

</div>

When we migrated our application from CentOS 7 to RockyLinux 8, we encountered a nasty bug. The application worked correctly on CentOS 7 (Apache+mod\_php).

Background  
Apache has a configuration variable called “LimitRequestLine” that allows the maximum querystring length (useful for large GET requests) to be expanded beyond the system default. We use a large setting, which worked correctly with Apache+mod\_php on CentOS 7. However, there is a hard-coded querystring limit in the version of Apache included in Rocky Linux 8, for mod\_proxy\_fcgi, that limits the max querystring length to 16384 bytes irrespective of the LimitRequestLine setting. This means that PHP scripts cannot use longer querystrings.

Manifestation  
This bug was difficult to track down. It produces a line in the HTTPD error\_log file as something like:

AH02536: couldn’t encode envvar ‘QUERY\_STRING’ in 16384 bytes

Correct Behavior  
The correct behavior would be for mod\_proxy\_fcgi to use the active LimitRequestLine value (or the default if there is not an explicit setting) as the maximum querystring (and environment variable) length rather than a hard coded limit.

Other Info  
According to other online sources, the only way to overcome this bug is either to use the deprecated mod\_php instead of php-fpm or manually recompile Apache with a different hard-coded value for the maximum environment variable size for mod\_proxy\_fcgi. Neither of these options is a good one.

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [November 6, 2024, 6:42pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/2 "2024-11-06T18:42:04Z")

</div>

> **[SOURCES/httpd-2.4.37-r1885607.patch · r8-stream-2.4 · staging / rpms / httpd...](https://git.rockylinux.org/staging/rpms/httpd/-/blob/r8-stream-2.4/SOURCES/httpd-2.4.37-r1885607.patch)**
>
> GitLab Enterprise Edition

This is a patch that incorporates the fix from [this bug report](https://bz.apache.org/bugzilla/show_bug.cgi?id=57807). This was backported as a result of [this bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=2221083). I see the same code (`#define MAX_MEM_SPOOL 16384`) is defined upstream, see [here](https://github.com/apache/httpd/blob/trunk/modules/proxy/mod_proxy_fcgi.c#L1107).

When I look at the `git blame` of upstream, I see [this PR](https://github.com/apache/httpd/commit/fa29f28624cb0fc6162de019bda3254e304b237d), which resulted in 16384 being defined. Very likely the reason for what you’re seeing.

If this is indeed a bug, this might be a better question for the maintainers at Apache, seeing as this is simply a backport of what they have in their upstream code.

---

<div class="post-metadata">

**Author:** ![Screenerco](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@Screenerco](https://forums.rockylinux.org/u/Screenerco)\
**Post date:** [November 6, 2024, 7:03pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/3 "2024-11-06T19:03:53Z")

</div>

Thanks for looking into this. Where can I report the issue to Apache?

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [November 6, 2024, 8:19pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/4 "2024-11-06T20:19:07Z")

</div>

You’re welcome!

As an aside, would you be willing to try this out on Rocky Linux 9? I’d be curious to know if you get the same results, where the httpd version is 2.4.57. (When 9.5 is released, 2.4.62 of httpd will be available, too, which is or is closet to the official GA version).

I’m thinking if the issue isn’t there, the backported patch may be right that it is a bug and that patch may have inadvertently created it. I’m quite interested to know if that’s the case. And at least testing a more recent version may help get some eyes on it.

* * *

As for contacting httpd folks, there’s a few places you can probably try.

[Apache HTTP Service Mailing Lists](https://httpd.apache.org/lists.html)  
[ASF Bugzilla](https://bz.apache.org/bugzilla/)

They seem to have `#httpd` on [Libera](https://libera.chat) IRC if you happen to use it. This _may_ be quicker to get an answer since it’s more real time. I’d read their [support](https://httpd.apache.org/support.html) and [bug report page](https://httpd.apache.org/bug_report.html) too just in case I missed something.

I don’t know how active their mail lists or bug tracker is, but maybe IRC will be quicker. Doesn’t hurt to try both the [users mail list](https://lists.apache.org/list?users@httpd.apache.org) and IRC channel though.

What’s even stranger is I looked through the mail archives and couldn’t really find anything beyond what I found a little bit ago. It seems like things go into a black hole in regards to this code change. So hopefully someone with deeper knowledge of the code base (and product in general) may have a better idea.

---

<div class="post-metadata">

**Author:** ![Screenerco](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@Screenerco](https://forums.rockylinux.org/u/Screenerco)\
**Post date:** [November 6, 2024, 8:35pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/5 "2024-11-06T20:35:09Z")

</div>

That’s a good suggestion with respect to testing Rocky Linux 9. Migrating our live app from CentOS 7 to Rocky Linux 8 was a major undertaking, so I don’t think we will be able to actually migrate our live application to Rocky Linux 9 just for testing (as a major version upgrade would likely be a pain). However, I may spin up a new Rocky Linux 9 server over the next couple weeks and try to send a specially constructed http request, to a new PHP script, designed to trigger the bug.

---

<div class="post-metadata">

**Author:** ![remi](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/remi/32/1425_2.png) [@remi](https://forums.rockylinux.org/u/remi)\
**Post date:** [November 7, 2024, 6:43am UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/6 "2024-11-07T06:43:35Z")

</div>

Yes, there is a known limit on query string length (and env size used by FastCGI protocol)

This looks like your app has a design flaw, sending a lot of data in the URI, so using GET method

Common/best practice is to send data using POST method (and keep them hidden in the “small” URI), or to store them in a local cache or in the session.

AFAIK, only workaround is to switch to mod\_php (still available in EL-8, not in EL-9) so you will have some time to fix your app for the future.

---

<div class="post-metadata">

**Author:** ![Screenerco](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@Screenerco](https://forums.rockylinux.org/u/Screenerco)\
**Post date:** [November 8, 2024, 6:09pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/7 "2024-11-08T18:09:49Z")

</div>

I would disagree that there is a design flaw in our app. The current behavior of FastCGI (which differs from the old mod\_php) no longer allows for a successful override of the LimitRequestLine variable in Apache configuration files–and no hard-coded limit is memorialized in the Apache configuration documentation. Where is this limit “known” to Apache end-users today? In fact, the only indication of the root cause of the issue appears in a cryptic message in the Apache error\_log files when the max environment size is exceeded.

Instead of using a hard-coded maximum environment size (which limits the max querystring), it should ideally be set to be to the greater of a pre-set value or the active LimitRequestLine value in Apache. If that logic were used, this bug would not exist.

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [November 8, 2024, 7:59pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/8 "2024-11-08T19:59:22Z")

</div>

This kinds of sums it up, and also confirms what @remi already hinted at: [Reddit - Dive into anything](https://www.reddit.com/r/webdev/comments/175emn3/what_is_best_practice_when_implementing_complex/)

> [@](#):
>
> Query strings have a length limit. The workaround is to use POST.

sure, you can use long query strings if you want, but it would seem to be bad practice and bad design of the web application. Short query string, OK. Long ones? Start considering POST instead.

Just because it worked before, doesn’t mean that it was correct to do it that way in the first place and therefore doesn’t mean that Apache is the bug or problem here. The application should have been designed to be more efficient.

---

<div class="post-metadata">

**Author:** ![Screenerco](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@Screenerco](https://forums.rockylinux.org/u/Screenerco)\
**Post date:** [November 10, 2024, 5:30pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/9 "2024-11-10T17:30:52Z")

</div>

I converted our GET requests to equivalent POST requests, and that fixed the issue with our service. However, the absolute length limit for Apache querystrings should be documented for end-users (i.e. with LimitRequestLine). It is a new, unexpected, and undocumented behavior that was difficult to track down.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\
**Post date:** [January 9, 2025, 5:31pm UTC](https://forums.rockylinux.org/t/bug-in-rockylinux-8-apache-mod-proxy-fcgi-php-fpm/16404/10 "2025-01-09T17:31:38Z")

</div>

Closed on January 9, 2025, 5:31pm UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
