In DevTools on the Timing tab you can see the following states:
_
Except 'Queueing' all states are explained in the DevTools documentation. Do you know what browser does in the Queueing phase ? What queue are we talking about ?
Thx
Additionally it seems that Queueing can take place at the beginning of connection setup and also at the beginning of the 'Request/Response' phase ?
From: Chrome Developers - Network features reference
Queuing
If a request is queued it indicated that:
The request was postponed by the rendering engine because it's considered lower priority than critical resources (such as scripts/styles). This often happens with images.
The request was put on hold to wait for an unavailable TCP socket that's about to free up.
The request was put on hold because the browser only allows six TCP connections per origin on HTTP 1.
Time spent making disk cache entries (typically very quick.)
Update from #cyptus comment:
With chrome v76 the network tabs will hide the CORS preflight (OPTIONS) request. The request that triggered this CORS will include the time the (invisible) OPTIONS request took in the queueing timing.
Update from #tamilsweet comment:
To show the CORS preflight follow Chrome not showing OPTIONS requests in Network tab
Another possibility may be there is a fresh service worker which is trying to install or activate. Keep the service worker url solid among your page visits.
Related
I’m developing chrome push notification for my web site and doing the development in localhost (local machine) environment. Sending push notification is success with specific endpoint which I got when I subscribe the notification first time. I use same endpoint for all push messages.
Here sometime push notification got failed due to endpoint mismatch. When I see in chrome console (debugging mode) there was different endpoint.
Why chrome browser is changing endpoint? In this case how do we handle this scenario and update the new endpoint in the db?
sample endpoint:
https://android.googleapis.com/gcm/send/AWERdvfdfdsfdobRH4zlXGuyeuie3543uTBuP6air5dzZfltNa-FKF6K6S-9P5SdfbCbyvn9RdsfsdvU1XwSBwIrekjdK6_i4Cg-5rZAj8UvL1s-Bbr61yvvt_y2Hg9RdsyV
when i check next time, above endpoint got changed as like below
https://android.googleapis.com/gcm/send/reytryMkQwtY:YTUNMdsjjfhsdf349851VS6McDE7s_GITe_djsgfdkjghcdfdfgdftrkddfdsXiwX1vP_XclmDqrKPOAMJDfsYYXdhMX164694Q&ksdhfksdfhkjfhksdcndsk
Thank you.
The push notification endpoint is dependant on the service-worker. When a service-worker is unregistered and created again, the PushManager.getSubscription() method will indeed return null. You then need to call subscribe() again, which will return a new endpoint.
If you server tries to send a push notification to the first endpoint after the service-worker was unregistered, you will get a NotRegistered (for Chrome) or a Gone (for Firefox) error. So make sure to register the new endpoint as soon as the app loads or the device may become unreachable.
Note that this does not seem to affect service-worker updates.
I'm trying to find information about WHEN a HTTP request has been "launched" to the server. In my chrome web inspector, network tab, I have some info about the internal timing of the http session (time before first byte, queuing, response..), but nothing about when those session starts/ends.
Is there a way to get this info?
I have a page on domain A which loads a webworker script from domain B. The webworker is fetching some PNGs from doman A's server.
In Firefox, the request to get the PNGs contains the cookie for my site (domain A).
In Chrome, it does not include the cookie for my site, and so fails because the request must be coming from a logged in user (which requires the session cookie to be sent in the request).
Which browser is behaving correctly, and can I do anything to make Chrome send the cookie for the current domain from within a webworker?
UPDATE:
I pulled all the files from domain B and hosted them on my server at domain A, so the webworker file is now on the same domain as the site itself, but Chrome still does not send the session cookie with the requests from the web worker.
With regards to the first problem, it looks like the Firefox is incorrect, you shouldn't be able to instantiate a Worker on another domain to quote the spec:
"If the scheme component of worker URL is not "data", and the origin
of worker URL is not the same as the origin specified by the incumbent
settings object, then throw a SecurityError exception and abort these
steps."
With regards to Chrome the Workers run in a separate they work for me and without seeing more code it's hard to answer. But if you visit this demo and break before the postMessage to the worker set document.cookie='test=1' you will see that when the request goes out from the worker it is set.
I've added a G+ login button on my website, but I keep seeing this issue. In most cases this comes first time and if you try to connect after refreshing the page, it works.
Here's the error:
Uncaught SecurityError: Blocked a frame with origin .com" from accessing a frame with origin "https://accounts.google.com". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "https". Protocols must match.
I saw this post Google + SignIn Button Blocked Frame but the solution isn't relevant to me.
First, I want to emphasize that you really should be using https when handling user credentials. If you can, get an SSL certificate and serve your content over https. By using HTTPS, you can prevent MiTM attacks and user information leaks.
That aside, there are a number of potential sources triggering the warning:
If you are using the Sign-in button from a page serving HTTP instead of the more secure HTTPS, sometimes communication with the sign-in servers gets blocked. If sign-in sometimes works and sometimes doesn't, this may be the cause.
If your authorized JavaScript origin protocol (http / https) doesn't match, the Google authorization server will reject your client (http://yoursite.com when you meant https://yoursite.com)
If your authorized JavaScript origin does not match (e.g. you put .com in the authorized origin, when you meant yoursite.com) then the OAuth server will reject your frame.
Listing your authorized origins (obfuscated for security) from the Google Developer Console and the site might help to determine what's going on in your case.
A few things you can change to see if it helps:
Try changing your cookie policy to either 'single_host_origin' or to 'http://yoursite.com'.
Try cleaning the authorized origins in the developer console to only include your http:// domain.
Try accessing your site from an incognito tab, if this works, your browser cookies may be in a bad state for the site.
Try using Chrome network diagnostics to see if specific requests are failing.
Try replacing any includes that use an explicit protocol with includes referencing a relative protocol (e.g. replace <script src="https://foo.bar/include.js" /> with <script src="//foo.bar/include.js" />)
I have a RESTful backend which per definition is stateless. However, I do require authentication. For this, I plan to use Basic HTTP authentication. Since that requires the username and password to be sent with every request, I want to store them clientside.
I was thinking of using the HTML5 session storage for this. The overal browser support is good enough for my application but there is one issue.
I need to catch the event when the session storage is cleared, for instance by closing the tab or clicking the logout button. Before actually clearing the session storage, I need to send the credentials to the RESTful server one last time so it can perform a clean-up operation for that user.
The issue is not so much with the logout button but more so with the tab or browser being closed...
How do I catch this event (with some Listener perhaps?), and delay it from happening until I've made a final REST call?
As far as browser and tab concern you can try following link.
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload