Sonos seems to struggle with redirects on occasion. I'm not sure what's special about some redirects vs. others (same environment), but it works ~50% of the time reproducibly and consistently.
If I request the HEAD of the file and get the redirect and pass that onto Sonos it works just fine. The only problem is that now the CDN delivers the best location to my server, not the client as would be ideal.
Here's a URL that fails until you give it the final redirected URL: https://archive.org/download/gd1976-08-02.fob.singer.motb-1.81456.sbeok.flac16/gd76-08-02d1t06.mp3
Related
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'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
I'm having an unending issue trying to use the AppEngine API explorer with the stupidly simple helloworld example.
When trying to navigate to the url to explore the API my Chrome browser redirects to HTTPS from the default HTTP and no API's are listed. I have gone through every possible fix I can find (Like this, and all of these) and none are working reliably.
What's the most infuriating is I have gotten the API listed TWICE but now no longer displays with any of the methods below.
The setup I had when it worked the first time:
Chrome launched with "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 (As per the tutorial)
The url being: (http://)apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api&root=http://localhost:8080/_ah/api#p/
The second time it worked was using also using the above URL but lasted only a second before being redirected to HTTPS and not listing anything.
Some specifics:
Windows 10 OS.
Every time the page loads I get the "The API you are exploring is hosted over HTTP, which can cause problems. Learn how to use Explorer with a local HTTP API." message, even the times the API displayed correctly.
Every time I now load any of the API Explorer URLs I get redirected to HTTPS, and nothing is listed. Also the URL is escaped (%3A instead of ':'). Not sure if it's important but the first time it worked the URL was HTTP and NOT escaped.
I have tried the shield in the search bar and enabling Load unsafe scripts ( from here).
Tried launching Chrome as usual and with the flags --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 and/or --allow-running-insecure-content (from this answer).
Tried http://localhost:8080/_ah/api/explorer
Tried http://apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api#p/
http://localhost:8080/_ah/admin works correctly and shows the Admin console every time.
Since the API's being listed once I haven't touched the project code, but restarted the server, Chrome, and tried different URLs on more occasions than I care to count.
I also tried accessing the API URL directly as explained in this answer but cannot find the correct URL to access the helloworld /sayHi endpoint. Maybe someone can help me work out what I need to prefix it with as all of the variations I try give me a 404.
Any help would be a very very appreciated.
I'm writing an app for Facebook, which needs to be secure. The initial page, https://myapp.com, loads perfectly fine.
However when I click a link to https://myapp.com/link, Chrome complains that the app is trying to load from an insecure source. I get the following message in the console:
"[blocked] The page at 'https://www.facebook.com/page/app_###' was loaded over HTTPS, but ran insecure content from 'http://myapp.com/link/': this content should also be loaded over HTTPS."
Now the link is an absolute URL with the https prefix, yet apparently the page is trying to load from the http version.
I visited the domain itself and checked the Network tab in the Chrome console to see what was happening. The following happens:
The GET to https://myapp.com/link is a 301, moved permanently.
This then redirects to http://myapp.com/link
As far as I can tell, there is nothing in my python code to make this happen, so I suspect some feature of Heroku is causing this, but I haven't been able to find anyone else with this problem.
As a side note, I used Flask-SSLify to add a redirect back to the https version. This redirect works, but Chrome still blocks the page because it passes through the insecure version.
I feel so stupid for working this out five minutes after posting the question, but it is a little obscure.
It turns out the problem was that the page I was attempting to reach was "https://myapp.com/link/" with the trailing slash.
"https://myapp.com/link" redirects to "http://myapp.com/link/".
I don't know why the protocol isn't preserved by this redirect, it may be either Flask or Heroku, though I suspect it is Flask. Regardless it seems like a bug.
Hope this winds up helping somebody else.
I created an app (id:155124624522900 - https://developers.facebook.com/apps/155124624522900)
And it is supposed to work as page server for Business Pages (as a tab)
But I get this code when trying to access from my debug app:
App Temporarily Unavailable The URL
The URL http://foodtreedevfb.herokuapp.com/tab returned a 404 Not Found error.
Still, the url is good! I wonder what is happening.
I am serving from Play Framework on Heroku.
EDIT
it may be related to some trailing slash issue on the uri, still I changed and it didn't help.
Is your app redirecting when Facebook sends the POST request? this can happen if your URLs in Facebook's settings are setup without the trailing '/'
Also, check your index file allows POST requests - i'm not sure if heroku have any such restrictions but many other servers won't allow POST requests to some URLs