This happens only in Safari.
I create XMLHttpRequest and get console error
XMLHttpRequest cannot load 192.168.0.87/cgi/app due to access control checks
The strange thing is, that is I try the same thing second time, it goes through. Is there some difference in Safari from Chrome, IE, Edge and Firefox? It is not cross site scripting case, it loads from the same server as the page itself.
Related
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.
I'm using Apache 2 and have a custom 401 page, in httpd.conf
ErrorDocument 401 /error/unauthorized.html
When I access a protected resource, all browsers show the basic http authentication dialog. If I click "cancel", all browsers but Safari (v3 and v4) will display the custom 401 page. Safari just displays the current page.
Is there any way to get Safari to display the 401 page through Apache configuration and/or mod_perl handlers?
G'day,
I believe that this is a well known issue for Safari browsers. In fact, several aspects of HTTP Authentication are subject to a "special" Apple implementation.
Sorry I can't give you a quick workaround.
cheers,
I can't reproduce the error in Safari 4 Beta, but try adding some bytes in your unauthorized.html file. Some versions of IE wouldn't show custom error pages unless the page was over a certain size, it assumed small pages were the default non-useful pages and tried to show something more useful (aka confusing).