This is a Laravel reservation website. Pages load, and POST /reserve/edit-details works, but the final POST /reserve consistently returns 403.
The request uses multipart/form-data and is approximately 17 KB. It also fails with a simple one-page PDF and in Chrome Incognito.
The submission controller has a warning-level diagnostic log at its first line, but no corresponding entry appears after the failed submission. The account is active, and the displayed resource usage is below the limits.
Latest test: October 21, 2026, approximately 6:51 PM UTC+8.
Could you check whether a server security rule is rejecting this request and advise how to resolve it?
Welcome to the InfinityFree community forum! Good to have you here.
Most people answering here are volunteers. They’re often the fastest source of help. Admin (the only staff member) checks in about once a day for issues on our end.
Volunteers can’t see your account or website. Share what you actually see, like error messages and what happens when you try something. That’s more useful than your theory of what’s wrong.
AI tools often get InfinityFree wrong. If a volunteer’s advice differs from what an AI told you, please try the volunteer’s suggestion first.
Solving an issue is a joint effort. Try the suggestions you get and report back what happened.
Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look.
The 403 page you’re getting is a bare “403 Forbidden / openresty”, not the InfinityFree error page. Can you tell me exactly what the response looks like? In your browser’s network tab, check the response body and whether the request is redirected to an errors.infinityfree.net/errors/403/ address.
That would show whether the block comes from the hosting’s own 403 handling or from somewhere else, and I can’t tell which from what you’ve posted.
Also, does a POST to /reserve still fail if you submit it without the file attached? That would show whether the upload part of the request is what triggers it. Your PDF test suggests the file type isn’t the problem, but it doesn’t rule out the multipart body.
The knowledge base article on InfinityFree 403 errors says URLs containing the keywords “chat” or “includes” are blocked automatically. /reserve doesn’t contain either, but check whether the URL, or any route or file behind it, does.
The article is here:
I found no source saying a server security rule rejects this kind of POST, so I can’t say that’s the cause.
The address stays on /reserve. No redirect to errors.infinityfree.net was observed. The response is a plain page displaying “403 Forbidden” and “openresty”.
We have not tested without an attachment because the form requires a PDF. Both the original PDF and a simple one-page test PDF produce the same failure.
Could a human volunteer or administrator advise how to investigate this further?
I’m not completely sure if it’s related, but be aware that POST requests right now are partially blocked to mitigate the impact of two critical PHP security vulnerabilities that were disclosed earlier today. We’re still waiting on upstream updates to properly fix it, so until then, some POST requests will be affected.
Here is the status page issue with more information about this.