I need to know what the --disable-web-security parameter does in chrome. I know that it disables same origin policy.
But I also noticed that it messes with your websockets (I first experienced it with googles gmail, now with my own nodeapp)
So what does it do exactly?
edit:
with messing I mean that I often fail to connect or lose connections to websocket-webapplications (while my chrome runs with the --disable-web-security parameter ). bear in mind that this is only an empirical diagnosis - I am not perfectly sure whether this parameter corelates with my connection issues.
Related
my server on jetty serves API.
Some requests return 200, but other requests to the same endpoint with different params return:
(failed)net::ERR_HTTP2_PROTOCOL_ERROR
It occurs only in Chrome. In FF it works well.
Do you know what could be the reason and how to fix it?
You should look at the Jetty server DEBUG logs for more information, or report them here for analysis.
One reason for these errors may be the fact that Jetty protects against these vulnerabilities using parameter jetty.http2.rateControl.maxEventsPerSecond which defaults at 20.
Different browsers send different frames to the server; in particular, Chrome sends many PRIORITY frames to the server and for pages with a large number of resources, the maxEventsPerSecond=20 threshold may be tripped.
You may want to configure this parameter to a higher value, say 50, and see if the error still happens.
If you are using Jetty embedded, you want to use code similar to this:
HTTP2ServerConnectionFactory http2 = ...;
http2.setRateControlFactory(endPoint -> new WindowRateControl.Factory(50));
When I had this error, I also thought it is only in Chrome - when I tried FF for couple of times, it seemed to work. But few more couple of times revealed that in FF is just same random as in Chrome.
There is some discussion here.
You might want to check if your Windows Update didn't pull KB5003637 which is suspected to cause this issue. My teammate did uninstall that patch and it fixed for him.
I'm trying to debug difference between HTTP/1.1 and HTTP/2.
Is there any possibility for disabling HTTP/2 in chrome or chromium?
I couldn't find this option flag in chrome 56. I have tried chromium 58 with flag --disable-http2:
./Chromium.app/Contents/MacOS/Chromium --disable-http2
But content is still delivered with HTTP/2 protocol after using this flag:
For what it is worth, the flag works.
The issue is that you need to quit EVERYTHING Chrome for it to take effect. Including plugin shims and other chrome tabs and so on.
It is not enough just to add the command line switch.
An easier way to achieve something broadly equivalent is to use an HTTP Proxy, like https://www.telerik.com/fiddler. This adds negligible additional time to your requests, and (as far as I know) doesn't support http/2 at all (yet); even if it did, I'm pretty sure it would be much easier/practical to switch behavior in than restarting all your Chrome windows.
The advantage of this approach is that it takes effect immediately - disabling and reenabling HTTP/2 becomes as easy as starting and stopping the proxy, without messing with the (if you're anything like me) dozens of Chrome tabs you have open, to StackOverflow and elsewhere :)
What happens when you try doing the same thing in WebPageTest (select Chrome as the test agent and add the command line switch in the Chrome tab under advanced settings)
Here's a test I did for my personal site just now and the flag appears to work OK (if you look at the response headers you'll see HTTP/1.1)
https://www.webpagetest.org/result/170322_1B_ab8656afcfb8bcc4103e9872ff56c28b/1/details/#waterfall_view_step1
I have seen the same problem created by a firewall running in proxy mode vs flow mode.
The firewall would buffer the entire file so it could scan it then pass it along vs scanning the individual packets.
https://docs.fortinet.com/document/fortigate/6.4.4/administration-guide/721410/inspection-modes
The problem would only happen when using http2 and might have something to do with http request priority not being handled properly or it forced it single threaded.
We would have a video request start with a low priority that would stall then start causing other file downloads to be delayed. Then there was a api poler in the background coming in with high priority requests. After a few high priority requests were blocked chrome would cancel the low priority video.
It would happen in other cases but the video made it very reproduceable for us.
https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672
https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
https://blog.cloudflare.com/http-2-prioritization-with-nginx/
https://calendar.perfplanet.com/2018/http2-prioritization/
We set it back to flow mode on the firewall and the problem went away.
Afterwards the downloads all happened in parallel with no blocking or stalling in the chrome network waterfall.
I am doing some web development and am serving some files locally. Now both Chrome and Firefox wont allow me this because of their origin policy. As I prefer Chrome, I chose to to use it in unsafe mode by adding the --disable-web-security flag.
While this works perfectly, there is a slight issue I am facing. I can't run the chrome instance in unsafe mode while my another chrome instance is running in normal mode. If I open new instance by opening the unsafe mode chrome shortcut whilst my regular instance is running, the new instance also opens in regular mode; and vice-versa.
Is there a way to open both simultaneously? If so, how do I achieve this?
PS: I will use two different browsers for this as my last option. I would like to avoid this as far as possible
I found the answer on a Linux SuperUSer forum at
https://superuser.com/questions/593726/is-it-possible-to-run-chrome-with-and-without-web-security-at-the-same-time
I earlier thought this could only be done in Linux but this is also possible in Windows. Essentially we are asking a chrome to create a new instance altogether than sharing the same instance. We do this by giving it a location to store it's data. You can read about this in the above shared link.
We had to update our certificate for our ecommerce website recently and ever since we've noticed weird behavior in Firefox and other browsers. About half the computers in the office, as well as my home computer complain that the certificate chain is not complete (Very odd it's not universal). I can view the chain in the Firefox certificate viewer and see that it doesn't have a chain.
Meanwhile Chrome's chain looks fine. This leads me to believe that there isn't an issue with our install of the certificate, as there's a chain there to be read, but Firefox can't seem to see it.
I should note that it seems to have the same issue in Chrome on Android.
So is this our problem or Firefox's?
This is typically the case when the server does not send all necessary intermediate certificates. Chrome on Desktop will go and fetch them. Firefox will use any intermediate certificates cached from previous connections to other sites but will not fetch missing certificates, thus some Firefox instances might work while others not. Chrome on Android will also not fetch missing certificates.
The issue needs to be fixed on the server side. If you check the server at SSLLabs you will probably see a note regarding "chain issues". Add the necessary certificates (they are listed at the report) until you don't see this note any longer and then it should work with the other browsers too.
test site http://socket.trailsandtribulations.net
firefox: v15 works fine. (however, if lots of traffic and slow net, firefox will frequently fail as well (quietly).)
chrome: previously worked, but v21 gets Error during WebSocket handshake: 'Connection' header value is not 'Upgrade'
however, if chrome is running locally, it works fine! it breaks on my client in Thailand and server in Germany. again, Firefox works correctly all the time, as did earlier versions of chrome.
using haproxy to split between websockets via node.js and html via nginx
has something changed that makes this solution not work?
haproxy.cfg now displays the test site link - that way it's always current.
It looks from your message that the error is reported by Chrome while initially I understood it was reported by the server when accessed by Chrome. I think that as a workaround, if you replace "option httpclose" with "option http-server-close", it could make the issue disappear. You also need to remove all "option forceclose". If there is only "option http-server-close", haproxy will not touch the Connection header in the response path, which should make the browser happy. However, you must keep in mind that there is still a bug where the error is displayed and that it should be reported to the software authors.
BTW, your timeouts are far too large, you'll end up with many dead connections at the end of the day, this does not make sense. If you use a recent enough haproxy, you can use "timeout tunnel" to set the WS timeout without having to deal with a large HTTP timeout. But even then, 1 day is far too large for TCP connections. Some of your users will be using smartphones where a TCP connection cannot live more than a few minutes before a handover happens.
firefox uses no-cache when requesting the websocket update; this version of chrome does not. see http://code.google.com/p/chromium/issues/detail?id=148908&thanks=148908&ts=1347523876
for some proxies evidently this is necessary
also, see https://github.com/sockjs/sockjs-node/pull/88 for related issue