We're finding the following error in our client play 1.5.x framework application
25 mag 2020 15:18:34 ERROR ~ Request exceeds 8192 bytes
It is related to the header size (we tested it with a curl with a header bigger than 8kb).
We didn't find in the official documentation how to increase the accepted header size in default play http server.
We tried with
-Dhttp.netty.maxHeaderSize=65536
-Dhttp.netty.maxInitialLineLength=65536
-Dplay.server.netty.maxInitialLineLength=65536
-Dplay.server.netty.maxHeaderSize=65536
but none of these seem working (probably because they are play 2.x config).
Any idea?
Thanks
We had a similar issue to this today and we solved with the following:
-Dplay.server.akka.max-header-value-length=128k
Posting for posterity in case someone else run into the same problem.
Related
I realized my first WebApp with Vaadin 14 and deployed it to Tomcat 9 on the production server.
So far everything is working great, but when I'm using a non-existing route in the client browser the system responds with a plain text list of all available routes and shows even the following line on the bottom:
"This detailed message is only shown when running in development mode."
I have created the WAR-file with "-pProduction" and the startup-log of Tomcat does not show any dev-mode-message.
Any ideas what happens here? Thanks for reading my first question on this platform!
I worked my way through the Vaadin docs and tried the following entry in application.properties:
vaadin.productionMode=true
But nothing changed?
This is a known vulnetability CVE-2021-31413 in Vaadin 14.6.1 and older versions. The resolution is to update the Vaadin version to 14.6.2. The latest version is 14.9.1 as of writing this. Naturally I recommend that.
https://vaadin.com/security/cve-2021-31412
Yesterday my site suddenly stopped working and after investigating I found out that Midphase upgraded the PHP to 8.1 and MariaDB (says from 10.3 to 10.5). I got them to roll back PHP to 7.4 for the time being, although it sounds like it was already on 7.4, which is good as they couldn't go back further.
My live site is on 3.10.1 (http://www.scifivision.com) and after running an upgrade on a backup, assuming I did it right I have a version on 3.10.11. (http://www.thejfiles.com/sfv2023). Both are giving me the same errors other than the database name is different.
The frontend gives me white page with the error "1146 - Table 'thejrub4_joomfin.joom_fields_values' doesn't exist" and backend gives me a warning "Error loading module Table 'thejrub4_joomfin.joom_modules_menu' doesn't exist" and it lets me log in but I can't do anything.
Just wanted to mention, in case it's relevant, I have an earlier backup (I'm at the point if anything is fixed I'll be happy) that is also giving me two warnings:
session_name(): Session name cannot be changed after headers have already been sent in /home/thejrub4/public_html/sfvclon/libraries/joomla/session/handler/native.php on line 128
ession_cache_limiter(): Session cache limiter cannot be changed after headers have already been sent in /home/thejrub4/public_html/sfvclon/libraries/joomla/session/handler/native.php on line 235
Error: Failed to start application: Failed to start the session because headers have already been sent by "/home/thejrub4/public_html/sfvclon/libraries/vendor/joomla/input/src/Input.php" at line 41.
Since I am not seeing them on the newer backup, I'm assuming that is probably not the issue and was something I previously fixed, as I do have maximum on for debug
I have used forum post assistance for joomla.org if that helps and I will post the code below. This is for the 3.10.11 install, as the FPA wouldn't work on the older one. It says it should work without any issues, but clearly that's not true. I didn't know if that would help on this forum, but if you need it please let me know.
I am trying to make a POST request to an endpoint served using jetty server. The request errors out saying 413 Request entity too large. But the content-length is only 70KB which I see is way below the default limit of 200KB.
I have tried serving via ngnix server and add client_max_body_size to desired level but that didn't work. I have set the setMaxFormContentSize of WebContext and that didn't help either. I have followed https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size and that didn't helped me either.
Does anyone have any solution to offer?
wiki.eclipse.org is OLD and is only for Jetty 7 and Jetty 8 (long ago EOL/End of Life). The giant red box at the top of the page that you linked it even tell you this, and gives you a link to the up to date documentation.
If you see a "413 Request entity too large" from Jetty, then it refers the the Request URI and Request Headers.
Note: some 3rd party libraries outside of Jetty's control can also use HttpServletResponse.sendError(413) which would result in the same response status message as you reported.
Judging by your screenshot, which does not include all of the details, (it's really better to copy/paste the text when making questions on stackoverflow, screenshots often hide details that are critical in getting a direct answer), your Cookie header is massive and is causing the 413 error by pushing the Request Headers over 8k in size.
Can someone using CF10 confirm if CF10 supports secure websocket wss://?
http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/
I checked with Hemant. The answer is no, it is NOT supported now, but it is under progress to be added.
On the basis of there being not a single mention of "secure websocket" or "wss" in the CF10 docs (according to Google), and in all the blogging Ray Camden has done on the topic there is not a single mention of it either, and indeed the only relevant match on all of Google for "cf10 wss" is back to this very question, I would say "no".
But that would be rather an odd implementation omission, I think.
I just tried hacking this on the websocketChannel.js file where the URL is created (line 18)
var lURL="ws://"+(_7e0)+":"+_cf_websocket_port+"/cfusion"+"/cfusion";
tried to do this
var lURL= (location.protocol === "https:" ? "wss" : "ws") + "://"+(_7e0)+":"+_cf_websocket_port+"/cfusion"+"/cfusion";
But alas the wss:// connection would just never connect. BS I tell you .. pure BS!! The only issue really is with IE10 as it will not connect to an unsecured websocket channel initiated from a secure page.
No it is not supported yet. However, it is being considered for
ColdFusion Splendor.
https://twitter.com/rakshithn/status/352722362799624193
Co's,
I enabled GZip compression in my Spring Boot Embedded Tomcat using CompressingFilter (https://github.com/ziplet/ziplet) and FilterRegistrationBean from Spring.
It is working fine in Chrome & Firefox.
I am getting Content-Encoding = gzip in response headers
Transferred JSON data size is reduced from 6.5MB to 1.2 MB - Great :-)
But, the same code is NOT working in Internet Explorer 11.0.9600.18097.
In Internet Explorer,
Content-Encoding = gzip is missing in response headers
Transferred JSON data size is still 6.5MB only.
I have pasted my headers ( IE11 ) below.
Could anyone help me to figure out this issue?
Update:
Please find Chrome Headers below.
Internet Explorer's decompression logic happens at a level below the Developer Tools, so you may not see a Content-Encoding in the Developer Tools. You should consider using Fiddler to see what's actually on the wire.
Please have a look at the link. It was filed as an issue, but microsoft decided for whatever reason not to fix on IE11. They fixed it in the new Edge browser.
Please take a look at the comments in the link provided.