What went wrong?
When running BookOrbit v1.10.0 behind a reverse proxy (Zoraxy v3.3.3), several administrative functions fail with:
415 Unsupported Media Type
Examples include:
SMTP Provider configuration
OIDC Provider testing
Authentication refresh requests
The issue appears to be related to:
POST /api/v1/auth/refresh
The endpoint returns 415 Unsupported Media Type when the request does not contain:
Content-Type: application/json
even though the request body is empty (Content-Length: 0).
Adding the header immediately changes the behavior and the endpoint responds correctly.
As a workaround, injecting:
Content-Type: application/json
at the reverse proxy resolves the issue.
Steps to reproduce
Browser reproduction
Open the browser console and execute:
Fails:
fetch('/api/v1/auth/refresh', {
method: 'POST'
})
Response:
{
"statusCode": 415,
"message": "Unsupported Media Type"
}
Works:
fetch('/api/v1/auth/refresh', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
}
})
Response:
{
"accessToken": "..."
}
Curl reproduction
Request through reverse proxy:
curl -i -X POST
https://bookorbit.example.com/api/v1/auth/refresh
-H "Cookie: refresh_token=test"
Response:
415 Unsupported Media Type
Same request with Content-Type:
curl -i -X POST
https://bookorbit.example.com/api/v1/auth/refresh
-H "Cookie: refresh_token=test"
-H "Content-Type: application/json"
Response:
401 Unauthorized
The response changes from 415 to the expected authentication response solely by adding the Content-Type header.
Expected vs actual behavior
Expected
For:
POST /api/v1/auth/refresh
Content-Length: 0
I would expect a normal authentication-related response such as:
200 OK
401 Unauthorized
403 Forbidden
depending on the authentication state.
Actual
The request is rejected with:
415 Unsupported Media Type
unless:
Content-Type: application/json
is explicitly present.
This causes authentication refresh failures and breaks parts of the administration UI.
Your setup
BookOrbit
Version: v1.10.0
Native installation via systemd
PostgreSQL backend
Reverse Proxy
Zoraxy v3.3.3
HTTPS enabled
Browsers tested
Chrome
Firefox
Safari
Brave
The behavior is identical across all tested browsers.
Relevant logs (optional)
BookOrbit logs show the request being rejected immediately:
POST /api/v1/auth/refresh 415 +0ms
Example:
{"req":{"method":"POST","url":"/api/v1/auth/refresh"},"res":{"statusCode":415},"responseTime":0}
The near-zero response time suggests the request is rejected during request parsing or validation before application logic executes.
As a workaround, injecting:
Content-Type: application/json
at the reverse proxy resolves the issue completely.
Screenshots (optional)
Note: This report was created with AI-assisted troubleshooting. I am primarily a system administrator and infrastructure operator rather than a software developer. All tests, logs, browser outputs and reproduction steps originate from my environment, but the investigation and write-up were assisted by AI.
Before submitting
What went wrong?
When running BookOrbit v1.10.0 behind a reverse proxy (Zoraxy v3.3.3), several administrative functions fail with:
415 Unsupported Media Type
Examples include:
SMTP Provider configuration
OIDC Provider testing
Authentication refresh requests
The issue appears to be related to:
POST /api/v1/auth/refresh
The endpoint returns 415 Unsupported Media Type when the request does not contain:
Content-Type: application/json
even though the request body is empty (Content-Length: 0).
Adding the header immediately changes the behavior and the endpoint responds correctly.
As a workaround, injecting:
Content-Type: application/json
at the reverse proxy resolves the issue.
Steps to reproduce
Browser reproduction
Open the browser console and execute:
Fails:
fetch('/api/v1/auth/refresh', {
method: 'POST'
})
Response:
{
"statusCode": 415,
"message": "Unsupported Media Type"
}
Works:
fetch('/api/v1/auth/refresh', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
}
})
Response:
{
"accessToken": "..."
}
Curl reproduction
Request through reverse proxy:
curl -i -X POST
https://bookorbit.example.com/api/v1/auth/refresh
-H "Cookie: refresh_token=test"
Response:
415 Unsupported Media Type
Same request with Content-Type:
curl -i -X POST
https://bookorbit.example.com/api/v1/auth/refresh
-H "Cookie: refresh_token=test"
-H "Content-Type: application/json"
Response:
401 Unauthorized
The response changes from 415 to the expected authentication response solely by adding the Content-Type header.
Expected vs actual behavior
Expected
For:
POST /api/v1/auth/refresh
Content-Length: 0
I would expect a normal authentication-related response such as:
200 OK
401 Unauthorized
403 Forbidden
depending on the authentication state.
Actual
The request is rejected with:
415 Unsupported Media Type
unless:
Content-Type: application/json
is explicitly present.
This causes authentication refresh failures and breaks parts of the administration UI.
Your setup
BookOrbit
Version: v1.10.0
Native installation via systemd
PostgreSQL backend
Reverse Proxy
Zoraxy v3.3.3
HTTPS enabled
Browsers tested
Chrome
Firefox
Safari
Brave
The behavior is identical across all tested browsers.
Relevant logs (optional)
BookOrbit logs show the request being rejected immediately: POST /api/v1/auth/refresh 415 +0ms Example: {"req":{"method":"POST","url":"/api/v1/auth/refresh"},"res":{"statusCode":415},"responseTime":0} The near-zero response time suggests the request is rejected during request parsing or validation before application logic executes. As a workaround, injecting: Content-Type: application/json at the reverse proxy resolves the issue completely.Screenshots (optional)
Note: This report was created with AI-assisted troubleshooting. I am primarily a system administrator and infrastructure operator rather than a software developer. All tests, logs, browser outputs and reproduction steps originate from my environment, but the investigation and write-up were assisted by AI.
Before submitting