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/
Related
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?
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
I have an app running on heroku and noticed today, that a particular request leads to a 400 response on Firefox but it works on Chrome. I also found out that if I remove an unnecessary cookie that requests succeeds again.
While investigating I also found an issue with chrome, where it wasn't able to fetch the CSS file, while loading the website:
However, opening that link in a new tab, I managed to load the CSS without any problems. Also removing that one extra cookie managed to sort it out.
All these 400 responses have one thing in common, they are served by the server "Cowboy"
The application I'm running is asp.net core, so it should return "Kestrel" as the server instead, but it seems that the request doesn't even get to the heroku router, because I can't even find them in the logs of the dyno.
I've tried to search online for an explanation and it seems that in case I'd be running against some limits, this is the response I should be expecting, but this is just a staging application and it works in chrome but doesn't work in firefox, so it's hard for me to imagine which limits I could be running against.
Update:
We've removed those unnecessary cookies, and now chrome loading the CSS seems to work fine, but Firefox is still getting a 400 Bad Request from the Cowboy server. Any ideas? I've only found Why do I get a "400 Bad Request" response when I have large cookies?
- which doesn't seem to apply to me, the cookies are less than 4k and all browsers should have the same cookies, there is nothing on the server to differentiate between browsers.
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.