API fails with reverse proxies that block encoded slashes (%2F) in path

[vincenzomartusciello]

Versions

• Pi-hole: v6.3
• Web: v6.4
• FTL: v6.4.1

Platform

• OS and version: Debian 13

• Platform: Docker

Expected behavior

Toggling lists enabled/disabled state should work when Pi-hole is behind a reverse proxy.

Actual behavior / bug

The Web UI fails with 400 Bad Request when Pi-hole is accessed through Traefik reverse proxy.
The API uses URL-encoded addresses in the path:
PUT /api/lists/https%3A%2F%2Fraw.githubusercontent.com%2FStevenBlack%2Fhosts%2Fmaster%2Fhosts?type=block
Traefik block or decode URL-encoded characters like %2F (slash) and %3A (colon) by default for security reasons.

Works:
Direct access to Pi-hole (no reverse proxy)
After configuring Traefik to allow encoded slashes (allowEncodedSlash: true)

Fails:
Default Traefik configuration (blocks encoded slashes by default)
Any reverse proxy with strict path security settings

More info here: https://doc.traefik.io/traefik/security/request-path/

Steps to reproduce

Steps to reproduce the behavior:

Deploy Pi-hole behind Traefik v3.6+ with default settings
Go to Lists → Blocklists
Click the "Enabled" toggle on any blocklist
See error

[yubiuser]

What exactly is the bug here? Just disable the sanitation check for the Pi-hole and ist should work.

We need to encode the list URL as it is a user input and later (e.g. during a gravity run) displayed to the user. This would allow XSS attacks if it would be not encoded.

[vincenzomartusciello]

Thanks for the quick response!

I understand the need to encode user input to prevent XSS attacks - that makes total sense.
The issue isn't the encoding itself, but where the encoded value is placed. Using encoded URLs in the path (/api/lists/https%3A%2F%2F...) causes compatibility issues because:

• Security defaults conflict: Reverse proxies like Traefik, block/decode %2F in paths by default to prevent path traversal attacks. Asking users to disable these security features creates a trade-off between Pi-hole functionality and reverse proxy security.

• Documentation burden: Every reverse proxy has different configuration for this. Users need to figure out allowEncodedSlash (Traefik), etc.

• Not always possible: In some environments users cannot modify these settings.

• Additionally, there are URL length limits to consider:
  Browsers: ~2,000-8,000 characters
  Web servers: typically 8KB default
  Some reverse proxies/CDNs: 4KB-8KB
  HTTP/2: header size limits apply

Suggestion: The encoded URL could be passed in the request body or as a query parameter instead of the path, while still maintaining XSS protection:

[DL6ER]

Posting AI generated texts only seldomly going to help any discussion. If you'd have thought through the text you posted, you'd have realized that some of these points aren't really relevant (like the URL length argument). REST principles require PUT and DELETE to operate on objects in the path. Think of it like putting or deleting a file at this very path.

Hence, providing the property in the request body would match how the POST method is to be implemented, a query parameter corresponds to GET. I can see the argument to "just make it dirty to make it easy" but that's not really a future-proof way of creating any things web.

[vincenzomartusciello]

it's not ai generated, just cleaned for better english.....
anyway, i already solved my problem with the fix i shared
just wanted to help in case someone in the future could have the same problem
you can just have the property in the path changing it with an id or similar and not making dirty to make it easy
be easy we are all here for community