mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-08 19:06:06 +03:00
Issue when text in form input is too large, draft will not save - The POST method is not supported for this route #2279
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @declankay on GitHub (Jun 6, 2021).
When saving text in the WYSIWYG, I get this error:
The POST method is not supported for this route. Supported methods: GET, HEAD, PUT, DELETE.
Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException
Above this, I get the following two PHP errors:
"Notice: Unknown: file created in the system's temporary directory in Unknown on line 0"
and
"Warning: Cannot modify header information - headers already sent in Unknown on line 0"
The error does not occur if the text in the form is reduced, which indicates the error stems from the size of the draft being too large.
However, I am unsure how best to fix this.
Steps to reproduce the behavior:
Expected behavior
The page should save and the long version of the text in the draft should submit.
Your Configuration (please complete the following information):
@ssddanbrown commented on GitHub (Jun 6, 2021):
Hi @declankay ,
@declankay commented on GitHub (Jun 6, 2021):
Hi @ssddanbrown,
Sure, it was installed on Windows.
I followed the steps for a manual installation:
https://www.bookstackapp.com/docs/admin/installation/.
The issue exists on all pages:
a) a new page that has just been created
b) an existing page has more content added to it.
It seems like once the content reaches a maximum limit, the application can’t process all the data and the issue appears.
@ssddanbrown commented on GitHub (Jun 6, 2021):
@declankay Thanks,
@declankay commented on GitHub (Jun 6, 2021):
@ssddanbrown
The URL path is books/name-of-the-book/draft/3.
I’d rather not put any book-specific data in this public domain. However, I can privately provide details of the installation, if preferred?
I do not have Cloudflare on my local version and the local version does not have the issue. The only way for me to check the live site (which uses Cloudflare) would be to change it to a domain which does not use Cloudflare.
Mod_security is enabled as part of the package provided by the hosting company.
@ssddanbrown commented on GitHub (Jun 6, 2021):
That's alright, don't need any more indepth details of your instance.
Bookstack page content can cause security layers to be tripped, think I've seen issues with people using mod_security before. Any way you can temporarily disable it to see?
Similar on the cloudlfare side, if there's any security features enabled for the cloudlfare setup it might be worth temporarily disabling them to see if the issue remains.
@declankay commented on GitHub (Jun 8, 2021):
@ssddanbrown
I cannot check the modsecurity issue, as unfortunately I do not have root access.
However, I did change the domain for the wiki over to a domain that does not use Cloudflare. I can confirm that the issue is still the same as before.
One thing that I did not think of doing before was to check the console. When I am typing the content into the draft WYSIWYG, and I reach the limit of the characters I mentioned before, I get this error in the console:
"Uncaught (in promise) Utils::waitUntil: max iteration count reached
kwift.CHROME.min.js"
Hope this helps identify the issue.
@ssddanbrown commented on GitHub (Jun 8, 2021):
Do you get the console or BookStack error when you're saving content when using a fresh plugin-free browser (Especially one without dashlane if using)? (Or incognito window if you have no plugins enabled there)
@declankay commented on GitHub (Jun 8, 2021):
The Bookstack error appears in both versions of the browser.
The console error only occurs in the regular browser, however does not appear in a private browser i.e. without plugins. I did some reading and believe the console error is a Dashlane-related error message.
That said, the error sounds like a limit has been reached and then the error occurs, which ties in with the error occurring once the draft has a certain amount of content in the input that is submitted.
@ssddanbrown commented on GitHub (Jun 8, 2021):
I've just tested against your instance with a couple of requests. This occurs on any endpoint, not just the page save. When the request body gets to a certain size it's being effectively ignored but the request is still going through, just without any body data.
Judging by the
Unknown: file created in the system's temporary directory in Unknown on line 0error, I think the request body is attempting to be cached within a temp file but that is failing, leading to an empty request body.If your hosting provider allows you to view any PHP error logs, it'll be worth looking there to find any additional info. If you have any control on your hosting, It may be worth double checking that the
upload_tmp_dirphp.ini option is set to something valid. Otherwise, you might need to raise the issue up with your hosting provide if it's a managed offering.@declankay commented on GitHub (Jun 9, 2021):
Changing the upload_tmp_dir in the PHP ini file seems to have done the trick, as it was previously pointing at the WAMP default (which did not exist on the server).
The issue is now resolved, so thanks! You will have a GitHub Sponsor payment coming your way soon.
For the benefit of people who may have this issue in the future - it works with Cloudflare and mod_security enabled.
@ssddanbrown commented on GitHub (Jun 10, 2021):
@declankay Awesome, Glad to hear that solved things for you. Will therefore close this off.