I am working in Angular8. I am getting response from various APIs. But some how api request in Edge is not come from server. It was always fetch from cached.
Below is screen shot of dev tool of IE Edge version 44
Same URL works in Chrome & Firefox as expected even in EdgeBeta it works.
Below are few points to note
I am using http_Interceptor to add some customer headers in request(mainly auth Header). that code work as expected. but when request is actually send to server I don't see any headers attached in network tab of dev Tools for Edge browsers
As shown in screen shot, Network tab always show "Received" column value form "Cache" even after I add Expires=-1 and pragma = "no-cache" headers. Theses headers are also not visible in networks tabs. I don't get any error while adding these headers in Interceptor methods.
Even in Edge Dev tool I kept "Always refresh request from Server", edge is not sending request to sever.
Issue is with only IE Edge (Microsoft Edge 44.17763.831.0). Did I miss any poly-fills to support Edge (version 44). chrome and EdgeBeta work as expected.
Any help is appreciated.
Thanks in advances
Related
When making multiple simultaneous network requests to the same resource, Safari, seems to return a cached version of the response. This only seems to happen when using Axios. When using fetch, I get a fresh version of the response.
Disabling network caching from the network tab seems to fix the issue. No matter what headers I put into the request, I can’t get it to bypass the cache.
Chrome and Firefox don't seem to have the same issue.
Here is a small fiddle to demonstrate.
https://jsfiddle.net/67pbntcj/4/
I have a single-page app built using React, and I've noticed intermittent issues from users who are using Internet Explorer 11, where IE is repeating ajax requests multiple times (which is an issue given that the API in question is not idempotent).
The most common case I've seen are where the request errors out with a "Network Error" Error, but IE retries the request multiple times. I've been able to recreate this using Fiddler and having it just drop those requests, in which case I can see multiple requests being made, although the network tab in IE dev tools only shows a single request. This also only seems to occur after a successful request, so this may be related to persistent connections?
The single page app is using axios, but I've been able to get it to occur with fetch and straight XHR as well, so I'm assuming this is something in IE11 itself. So the questions I'm trying to answer are:
Is this intended functionality, or is it a quirk of IE11?
Is there any way to configure or control this behaviour?
Context:
I'm trying to create an audio visualizer using the Web Audio API with createMediaElementSource() very similarly to the model explained in this tutorial. The hosting service my client is using for their audio inserts a 302 redirect before the actual media, to track listening data.
The demo
Problem:
In Safari, when I attach an AudioContext to an audio element that is linked to a source with a 302 redirect in front of it, it outputs silence instead of normal audio without any errors in the log. By contrast I've tested Chrome and Firefox, and they both work fine with no issues.
In the demo above, all three buttons attach and play the same audio source, but in the second and third it goes through the redirect first. The second attaches an AudioContext as well, while the third just plays the audio normally with no visual.
I posted about this issue last month and it was suggested that the problem was some missing CORS headers on the 302 redirect. However, I am now testing my own redirect server instead of using the hosting service, so that I can test my own CORS rules (see below). The issue remains even with these headers set, so this makes me think it's a bug in Safari with 302 redirects. What I'd like to know is A) Are there any other cross origin headers I can try adding that may resolve the issue, and B) If it is indeed a Safari bug, where do I go to report it and how long from that point until someone addresses it.
Headers I've set for my 302 redirect:
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:connection,content-length,last-modified,etag,content-type,via,cache-control,accept-ranges,age,content-range,date,x-served-by,x-cache,x-cache-hits,x-timer,access-control-allow-origin,access-control-allow-methods,vary,server,x-final-url
Access-Control-Allow-Methods:GET,OPTIONS
Update: I've now reported this as a bug, and the Webkit devs have isolated the check causing the issue.
I have a PWA site which is working fine on Firefox, Chrome and Edge on Windows, and all of those on Android, Edge (EdgeA).
The problem
This much I know from looking at my Azure server logs:
(1) The login POST is hits a Core 2.2 controller which does the authentication and returns 302 along with a standard Core 2.2 cookie set including the authentication token for the user.
(2) The EdgeAndroid browser receives that, and immediately GETs the location specified.... except this GET doesn't include the cookies from (1), so the Core 2.2 system responds with a 302 back to the login page.
It's a redirect loop.
-> EdgeA is eating my cookies!
I can run this perfectly on the above browsers, and the logs show Edge/Windows for example has the (1)(2) sequence exactly as you'd expect, with the cookie credentials in the second request.
The only thing different is Edge Android. I stripped out all the caching from my service worker for that browser and it's still broken - I think I may need to just not run the service worker for it at all.
... and my questions are:
Does anyone have a PWA which actually works in EdgeA?
Does anyone have any idea what I may have missed? Note it's just this one browser which is broken, hence it may be them not me.
In case it is them not me, is there a place I have not yet googled where I can report defects in this possibly minor-interest browser?
This sounds similar, although that's cross-domain, and my 302 is not cross domain.
I think this was caused by the Edge Android Browser interpreting the display:standalone directive and consequently opening a "stand alone" window, which does not carry over the cookies from the original browser.
The server logs show that the EdgeA client "drops the cookies" when handling a "login successful" 302 response from the standard Core 2.2 login stuff.
My work around is to serve a specific manifest.json to the EdgeA browser, so that it reads display:browser.
At the same time I fixed this MS released a new version of EdgeA, so I can't be 100% sure if my change fixed this or if they actually listened to my whining.
Some our links are wrapped by PJAX. When a user clicks on a PJAX link the server returns only the required part of the HTML.
If I do the following:
Click PJAX link
Click simple link
Press back button
the browser will display content that was returned by the PJAX request. The HTML will be broken because it's only part of the HTML to be displayed (check this question).
We have tried to fix this by not caching PJAX responses (Cache-Control header). This fixed our problem but raised another one:
When the user presses the back button, WebKit (Chrome 20.0) loads full content from server, then fires popstate event that causes an unnecessary PJAX request.
Is it possible to recreate correct back button behaviour?
To make the Browser aware of the different versions of the HTTP resources depending on the request-headers I added a Vary http header.
Using Vary, you don't need to send no-cache headers anymore and therefore get your page fast again.
In PHP this would look like:
header("Vary: X-PJAX");
Since we sometimes use 3 representations per URL (regular http, pjax and ajax) - because migrate to a PJAX approach in a already sometimes ajaxified app - we actually use:
header("Vary: X-PJAX,X-Requested-With");
In case you need to support old IE (older than IE9) versions you need to make sure that the Vary header is stripped by your webserver, because otherweise old IE will disable caching for all your resources which provide a Vary header.
This could be achieved by the following setting in your .htaccess/vhost config:
BrowserMatch "MSIE" force-no-vary
Edit:
Underlying chrome bug, https://code.google.com/p/chromium/issues/detail?id=94369
This all depends from server caching settings. You browser caches the AJAX response from server and when you click Back button it uses cached version.
To prevent caching set following headers on server:
'Cache-Control' => 'no-cache, no-store, max-age=0, must-revalidate'
'Pragma' => 'no-cache'
If you are using Rails, then definitely try Wiselinks https://github.com/igor-alexandrov/wiselinks. It is a a Swiss Army knife for browser state management. Here are some details: http://igor-alexandrov.github.io/blog/2013/07/11/the-way-to-wiselinks-1-dot-0/.