Accessing http://pi.hole produces "400 Bad Response" error on Fedora 29

[golanv]

In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

How familiar are you with the the source code relevant to this issue?:
1

---

Expected behaviour:
Accessing http://pi.hole should redirect one to http://pi.hole/admin automatically.

Actual behaviour:

"400 Bad Response" error.

Also, the following error message is logged in the lighttpd error log:
pihole (response.c.400) uri-path does not begin with '/': pihole/index.php -> 400

Steps to reproduce:

1. Install Fedora 29 (or at least lighttpd 1.4.52)
2. Install pihole
3. Go to http://pi.hole

Debug token provided by uploading pihole -d log:

usxyflu4ki

Troubleshooting undertaken, and/or other relevant information:
Adding an index file in /var/www/html that redirects requests to /pihole/ works to prevent the 400 error. However, it seems like the problem is in the lighttpd.conf file. Assuming that the server.error-handler-404 is still the best way to handle a missing index file, then it's probably better to do a...

• server.error-handler-404 = "pihole/index.php"

• server.error-handler-404 = "/pihole/index.php"

The above change fixes the problem and restores normal functioning. It seems the original configuration worked when I first installed pihole, so perhaps a lighttpd upgrade in Fedora 29 broke this original syntax (which may no longer be supported by lighttpd?).

See: https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_error-handler-404Details

[dschaper]

There is no page at http://pi.hole. What content were you expecting to be displayed at that URL?

[dschaper]

If you would like us to take a deeper look you will need to provide the debug token as requested.

[golanv]

I added the token in the original comment.

I never said there was a page at http://pi.hole, which is why I referred to adding an index file at /var/www/html, rather than replacing an existing index file. I did however refer to using the http://pi.hole address as a method of accessing the Pi-hole admin interface, as per the Pi-hole documentation (See: https://github.com/pi-hole/pi-hole/blob/master/README.md and https://discourse.pi-hole.net/t/how-do-i-access-pi-holes-dashboard-admin-interface/3168).

Since there is no page at http://pi.hole, the web server would naturally produce a 404 error (https://en.wikipedia.org/wiki/HTTP_404). Line 31 of the lighttpd.conf configuration file that comes with Pi-hole (https://github.com/pi-hole/pi-hole/blob/master/advanced/lighttpd.conf.fedora) determines how lighttpd should handle such an error should it occur. In all cases the action by lighttpd, as defined in line 31 of the lighttpd.conf, is to redirect requests that produce such an error to "pihole/index.php". While the configuration does not seem to be an issue for the version of lighttpd that ships with Debian Stretch (1.4.45), it does seem to be problematic with newer versions of lighttpd, such as the version that ships with Fedora 29 (1.4.52) and perhaps the version shipping with Debian Buster (https://discourse.pi-hole.net/t/web-interface-fails-to-start-after-update/16020).

So, adding a leading forward slash to the server.error-handler-404 option defined in lighttpd.conf will likely fix that small issue for newer versions of lighttpd, and it also does not break the current version shipping with Debian Stretch.

[bcambl]

A snippet from the installer:

  [✓] Pi-hole Enabled
  [i] View the web interface at http://pi.hole/admin or http://<ipaddress>/admin

  [i] You may now configure your devices to use the Pi-hole as their DNS server

The installer states that you should be using http://pi.hole/admin to access the admin interface.

However, I do notice inconsistent behaviour between using http://pi.hole and http://<ipaddress>.
Using pi.hole results in a 404 error while using the ipaddress yields the blockingpage:

    <html><head>
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
        <link rel='stylesheet' href='/pihole/blockingpage.css' type='text/css'/>
    </head><body id='splashpage'><img src='/admin/img/logo.svg'/><br/>Pi-<b>hole</b>: Your black hole for Internet advertisements<br><a href='/admin'>Did you mean to go to the admin panel?</a></body></html>
    

[micchickenburger]

I'm having this same issue on a fresh install of CentOS 7 with lighttpd 1.4.53.

[svdblom]

Me too @micchickenburger

[bcambl]

Just looking at this issue again..
I found this on the PHP side:

// Determine block page type
if ($serverName === "pi.hole") {
    // Redirect to Web Interface
    exit(header("Location: /admin"));

And in the lighttpd logs:

2019-03-01 21:03:52: (response.c.400) uri-path does not begin with '/': pihole/index.php -> 400 

Since the PHP code states pi.hole should redirect to /admin, perhaps we should add the missing / to resolve this issue.

We should likely add the / to the debian lighttpd.conf to stay consistent.

[golanv]

If the issue is related to the version of lighttpd as I suspect (which explains why the current configuration works with Debian Stretch and its older version of lighttpd, but not with the newer versions that ship with Fedora), then this current configuration will eventually produce the same problem with Debian anyway, once Debian starts shipping with newer versions of lighttpd.

It should be an easy fix and I personally wasn't able to get the adjusted configuration file (with the added forward slash) to cause any problems with Debian Stretch, so there is probably no downside to making the change.

[liang-hiwin]

We should likely add the / to the debian lighttpd.conf to stay consistent. that is good idea

[advir29]

I experienced the same problem on Fedora 29
Error 400 Bad Request
as suggested changed
server.error-handler-404 = "pihole/index.php"
to
server.error-handler-404 = "/pihole/index.php"
but it now gives redirecting error
ERR_TOO_MANY_REDIRECTS
problem?

[golanv]

I experienced the same problem on Fedora 29
Error 400 Bad Request
as suggested changed
server.error-handler-404 = "pihole/index.php"
to
server.error-handler-404 = "/pihole/index.php"
but it now gives redirecting error
ERR_TOO_MANY_REDIRECTS
problem?

That's a peculiar error. It certainly doesn't happen to me when changing that line. I wonder if it happens with a different browser? If not, perhaps the system logs give some indication as to the culprite.

[alexdub37]

Hi,
I'm on centOS 7 and I got HTTP 400 errors for /admin/
I modified suggested line in /etc/lighttpd/lighttpd.conf
and also got trap in that redirect loop.
It ended up that SELinux was not correctly set up.

I ran
ls -alZ /var/www/html/*

and saw that /admin/* were missing some SELinux http stuff compared to /pihole/*.
What fixed it was:

yum install policycoreutils-python
semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'
restorecon -R -v /var/www/html

I hope this will help you

[redshiftltd]

Hi,
I'm on centOS 7 and I got HTTP 400 errors for /admin/
I modified suggested line in /etc/lighttpd/lighttpd.conf
and also got trap in that redirect loop.
It ended up that SELinux was not correctly set up.

I ran
ls -alZ /var/www/html/*

and saw that /admin/* were missing some SELinux http stuff compared to /pihole/*.
What fixed it was:

yum install policycoreutils-python
semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'
restorecon -R -v /var/www/html

I hope this will help you

Hi,

Fresh install on CentOS7 with SELINUX=permissive resulted in the same issues.
I did the semanage updates and was able to get to the web interface instead of seeing the 400 errors but no stats were displayed and the Pi-Hole app showed as offline.

Setting setenforce 0 and refreshing the page shows the stats and the app as online. Since the Pi-Hole installer explicitly says that SELINUX is not supported I think it makes sense to segregate the service to a single VM/container and disable SELINUX. It's not ideal but it gets the app to work at least.

[carroarmato0]

What if the hostname of the machine pihole is actually installed on is pihole.lan? I noticed this breaks the webinterface unless you connect to it by ip

[dschaper]

Does it respond with a 400 error on the name pihole.lan?

[carroarmato0]

@dschaper it's able to fetch the index, but there are hardcoded references to pi.hole which results in the following resources not being able to load:

http://pi.hole/pihole/blockingpage.css net::ERR_NAME_NOT_RESOLVED
http://pi.hole/admin/scripts/vendor/jquery.min.js net::ERR_NAME_NOT_RESOLVED
http://pi.hole/admin/img/favicon.png net::ERR_NAME_NOT_RESOLVED

[dschaper]

That will be a different issue/feature request than we are tracking in this issue. Please open a new issue here or a Feature Request on https://discourse.pi-hole.net. Thanks.

[redshiftltd]

For now I pushed the devices into a beta using their internal network hostnames with SELINUX disabled.
I will make another instance next week and try pi.hole as the hostname and report back.

[jankais3r]

Just installed pi-hole on a Raspberry Pi 4 running fresh install of Raspbian Buster and having the same issue of "400 Bad Request" error upon loading http://pi.hole.

Existing pi-hole instance (running on 1st gen raspi) redirects me to /admin without any issue when I visit http://pi.hole.

[MarkRMonaco]

I'm in the same boat with a fresh install of Ubuntu Server 19.04 where browsing http://ipaddress/ results in the "400 bad request" page

On 18.04 LTS (separate VM), using the same URL format, sends me to a landing page with the pi-hole logo, and states "Pi-hole: Your black hole for Internet advertisements. Did you mean to go to the admin panel?" (which links to the admin page).

[dschaper]

Please open a new issue, this is for tracking 400 responses to http://pi.hole on Fedora.

[MarkRMonaco]

@dschapter. Ok

[golanv]

Please open a new issue, this is for tracking 400 responses to http://pi.hole on Fedora.

Actually, this issue seems to have apply to newer versions of lighttpd, not Fedora specifically. I just happened to experience the issue on Fedora. I would expect the issue to apply to all distributions with a new enough lighttpd version.

[MarkRMonaco]

Please open a new issue, this is for tracking 400 responses to http://pi.hole on Fedora.

Actually, this issue seems to have apply to newer versions of lighttpd, not Fedora specifically. I just happened to experience the issue on Fedora. I would expect the issue to apply to all distributions with a new enough lighttpd version.

Agreed since @jankais3r mentioned that it was happening on Raspbian (which is Debian-based like Ubuntu).

[AzureMarker]

This issue is marked as fixed in the next release. The changes are available in the development branch.

[DL6ER]

Pi-hole v5.0 has just been released.