I have an ASP.NET application Hosted on server 2008.
Recently After latest chrome update to 53.0.2785.116m All of my downloads from server get fail.
I tested chrome version 52, firefox and IE! all of them work.
Any idea for this problem?
Finally I find the solution.
web servers by default set the "content-length" in header and also most of the browser auto correct the file size if its wrong.
in new version of google chrome (v53) the auto correct doesn't work.
And at the end I had to set "content-length" property in HTTP Context while flushing the file to client.
Related
I have a local web server set up at 192.168.1.39 with domain www.server.local. DNS has been configured to resolve this properly on my router.
Everything worked just fine until recently. My browser started to report the following error if I access page like www.server.local/page.html that references external resources.
Access to CSS stylesheet at 'https://cdn.jsdelivr.net/npm/reveal.js#4.1.0/dist/reset.css' from origin 'http://www.server.local' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
However, if http://192.168.1.39/page.html is used, the page opens properly.
But the error message really confuses me, because it suggests the css hosted at jsdelivr is in a private address space! Seriously?! Or did I miss something?
My Browser: Microsoft Edge 94.0.992.31 (Official build) (x86_64)
You can try this solution:
Open Edge and navigate to edge://flags/#block-insecure-private-network-requests
Disable the highlighted option Block insecure private network requests.
Restart Edge and test again.
For more details, you could refer to this blog: https://developer.chrome.com/blog/private-network-access-update/
I want to connect "wss" (SSL-ed websocket) with insecure (self signed) cerfiticate.
But it is raise a error.
This error caused by default firefox setting that it seems like does not allow connecting to self-signed ssl as well as chrome.
In Chrome, this behaivior is able to change by allow-insecure-localhost flag in chrome://flags.
Is there a equivalent flag in Firefox?
Navigate to
about:config
and look at:
network.websocket.allowInsecureFromHTTPS
but it won't be for localhost only so be carefull :D
I am trying to enable push notifications on my website using VAPID keys.
When i include the gcm_sender_id and remove the applicationServerKey from the pushManager.subscribe method, it runs fine.
Only when i enable VAPID keys and remove the gcm_sender_id from manifest.json file. i get the foloowing error.
DOMException: Registration failed - push service error
I am using Chrome browser.
I encountered this error in Brave browser. By default, Google Services for push messaging are disabled in Brave. To enable this, open the following URL in brave:
brave://settings/privacy
After this, enable the flag "Use Google services for push messaging":
Source:
https://github.com/firebase/firebase-js-sdk/issues/3195#issuecomment-848036637
The applicationServerKey that i was using in the pushManager.subscribe method was somehow incorrect.
It worked when i regenerated the keys in node using the following module.
const webpush = require('web-push');
const vapidKeys = webpush.generateVAPIDKeys()
In my case,I was trying to run firebase messaging on a flutter web.
My Browser was BRAVE.
It always failed with an exception of firebase fcm registration push servic error.
I followed #Nicodemuz answer, but it didn't solve the issue. I get the same error.
The only solution was setting Google chrome as my executable.
Anyhow the issue is not with firebase or flutter, it's with the brave browser itself.
Unable to reach IceConnectionState "completed" in new chrome browser "Version 52.0.2743.116 m" only getting IceConnectionState "checking", but same code working fine with chrome browser Version 51.0.2704.103 m media is flowing in this version.
I'm using kurento media server 6.0 and libnice version 0.1.13. Is this is the problem of kurento do I need to update anything ? (Server is returning SDP and IceCandidate in both browser version)
Chrome 52 changed the DTLS handshake (see the release notes) which might cause this if the servers ssl lib is too old.
Following problem with chrome...:
I've running an Grails 1.3.7 Application on a Server. I've noticed, when I request a static content (such as non-dynamic html-files) from Chrome, Chrome creates two JSESSIONID-Cookies. The first one when the login-window shows up, and the second after a successfull login. If I want to refresh the page, or request another resource, I've to login again. (I think because Tomcat doesn't understand those two cookies)
I've tried it with FF, but FF just just creates one Cookie and its working perfectly.
Also, I've ran the app locally, and it works even with chrome perfectly. So, something with tomecat must be wrong.
Enviroment:
Grails-Application 1.3.7 (with Spring-Security-Core 1.2.4)
Apache Tomcat 7 (on Windows Server 2008)
My httpd.conf:
ProxyPass /manager http://myUrl:8080/manager
ProxyPass /myGrailsApp http://myUrl:8080/myGrailsApp
ProxyPassReverse /manager http://myUrl:8080/manager
ProxyPassReverse /myGrailsApp http://myUrl:8080/myGrailsApp
ProxyPass / http://myUrl:8080/myGrailsApp/frontend
ProxyPassReverse / http://myUrl:8080/myGrailsApp/frontend
Thanks in advance.
Update 1:
I re-builded, re-deployed the app and restarted tomcat again.
Now I noticed: Chrome doesn't generate two cookies anymore. But the error is the same. Every time I refresh or request something, the JSESSIONID changes and I have to log in again.
A short watch on the tomcat-server displays a big amount of active sessions - those from chrome...
Update 2:
I tried it locally on the server (with chrome):
localhost/myApp/frontend => Apache => FAIL
localhost:8080/myApp/frontend => Tomcat => OK
It seems like Apache is the problem (?).
Solution:
I've got it :)
The Grails *.gsp-Templates always requested the 'favicon.ico' on each request.
The reason why the error appeared on static content (like html-files) is because we redirect to those resources from our Grails-Application.
So I've put the favicon.ico in the right place, and now it works :)
This error just concerns Google Chrome, in FF and IE it worked without any problems.
I also ran into this problem. It took me a while to figure out what was happening (including sniffing with Wireshark), and still more time to find a viable solution.
At last I found this thread https://vaadin.com/forum/-/message_boards/view_message/1216366
It seams that this is a problem with Chrome/Safari (Webkit browsers?) and the way they handle redirected cookies.
The simple fix was to add a context.xml to the META-INF directory in my spring project containing
<?xml version='1.0' encoding='utf-8'?>
<Context sessionCookiePathUsesTrailingSlash='false'>
</Context>
and then redeploying the new war file. Now everything is working as intended.