The discussion centers on whether the Apache HTTP Server vulnerability should be classified as a Remote Code Execution (RCE) given that no public proof-of-concept exists, with users split between those citing industry norms and vendor claims versus those demanding demonstrated exploitability. A secondary debate concerns the role of AI in discovering the bug and the ongoing preference for Apache over Nginx due to features like .htaccess despite performance criticisms.
193 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4apache
httpd
C2012–2026
apache / httpd
httpd
Apache HTTP Server
17Distinct people
17Mentions
0Explicit recommenders
4.1KGitHub stars
What to know before exploring
What it is
Apache HTTP Server
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.
Mentions over time
HN mentions by year17 dated mentions
Observed mentions: 2012-09-06 06:22:14 UTC to 2026-10-15 03:24:04 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
1 sourcesIZIzkata·Oct 15, 2026
It really shouldn't be, this error page should be familiar looking: https://i.sstatic.net/FRlUG.png
It comes from ap_send_error_response(), near the bottom starting at https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d...
Scrolling up from there a bit you can see some of the handling for ErrorDocument, which is configurable ( https://httpd.apache.org/docs/current/custom-error.html ) but also loses the original response body.
ap_send_error_response() is only called from the last line of ap_die_r() ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ), as the fallback for errors when none of the other conditions pass. There's some other handling for redirects and custom ErrorDocument, but again, if it reaches those it's using the contents of "custom_response" instead of the original response body.
ap_die_r() is cal
Read the rest
led unconditionally for completed requests ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ), which is why api_die_r() starts with an early return for an OK or DONE response. Its wrapper ap_die() is also used in plenty of other locations as a general error handler.
It's been a while so I had to go through it again, the code isn't exactly what I'm half remembering, but I do remember the "assbackwards" lines in ap_send_error_response() ( https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... and https://github.com/apache/httpd/blob/b2dc966be4178ded1499d5d... ). If the particular check I think I remember did exist (explicit status codes in an "if", similar to your earlier link), it was probably in the even older version we were using. The early return I'm pretty sure wasn't there (blame puts it at 12 years old), so all responses would have gone through more of the error handling code back then.
Edit: Replacing "trunk" branch with most recent commit so line numbers continue to work in the future