I am trying to play this audio file in a native html5 audio tag. IN DESKTOP SAFARI / iOS SAFARI
here is the link to the file: https://primetime.a.bluejeans.com/a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3
Now, it has a couple of issues:
The duration is INFINITY ( checked after loadedmetadata event, and also after every timeupdate.
The audio doesn't play fully, it stops abruptly with NO errors at random times, ex at 50th second / 72nd second. the last event in this case is timeupdate only.
Html5 media tag's controls show "Live Broadcast". ( in the UI I mean )
below are the request and responses recorded from Charles (2 requests/responses):
REQUEST 1:
GET /a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3 HTTP/1.1
Host: primetime.a.bluejeans.com
Accept-Language: en-us
X-Playback-Session-Id: 174A3981-F3E3-4F49-A17B-BEBE88764552
Icy-Metadata: 1
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://fiddle.jshell.net/
Accept-Encoding: identity
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
RESPONSE 1 (showing only header):
HTTP/1.1 200 OK
x-amz-id-2: l4souPN96kHUVyThsqJZHllkVN873tbsPwk80hq94cixXcRKl3CTdO6HS32AbutMLInBSOXAZe8=
x-amz-request-id: 4122A053E2768F35
x-amz-replication-status: COMPLETED
x-amz-version-id: jAKAQ6MTbVed.NthIiH9ZOoLEWHRC95Z
Content-Type: audio/mpeg
Server: AmazonS3
Vary: Accept-Encoding
Date: Wed, 25 Nov 2020 16:43:00 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Referrer-Policy: strict-origin-when-cross-origin
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=86400 ; includeSubDomains ; preload
Expires: 0
Cache-Control: no-cache
REQUEST 2:
GET /a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3 HTTP/1.1
Host: primetime.a.bluejeans.com
Accept-Language: en-us
X-Playback-Session-Id: 174A3981-F3E3-4F49-A17B-BEBE88764552
Icy-Metadata: 1
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://fiddle.jshell.net/
Accept-Encoding: identity
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
RESPONSE 2:
HTTP/1.1 200 OK
x-amz-id-2: l4souPN96kHUVyThsqJZHllkVN873tbsPwk80hq94cixXcRKl3CTdO6HS32AbutMLInBSOXAZe8=
x-amz-request-id: 4122A053E2768F35
x-amz-replication-status: COMPLETED
x-amz-version-id: jAKAQ6MTbVed.NthIiH9ZOoLEWHRC95Z
Content-Type: audio/mpeg
Server: AmazonS3
Vary: Accept-Encoding
Date: Wed, 25 Nov 2020 16:43:00 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Referrer-Policy: strict-origin-when-cross-origin
Access-Control-Max-Age: 86400
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=86400 ; includeSubDomains ; preload
Expires: 0
Cache-Control: no-cache
CHECK OUT THE ISSUE LIVE: https://jsfiddle.net/y7whr25a/2/
Also please note that I have tried many answers from the web such as checking if server supports Range Requests (yes it does) and adding Range / Content Length / Accepted Ranges / 206 http response code By rewriting request/response in Charles but nothing worked, I'm about to lose all hope.
here is the same file but hosted on google drive, THIS WORKS IDK HOW: https://drive.google.com/u/1/uc?id=1b6UcqEb5_opUIR2eLzMghtAIQGYV2q8f&export=download
Your file is not properly built and misses metadata information telling the duration.
You should reencode it properly if you want it to work everywhere.
Chrome and Firefox (actually ffmpeg) are able to estimate this duration from the bitrate, but even then, it may be inacccurate.
But the problem with Safari is that your server doesn't accept Range requests. Somehow, Safari switches to stream player in this case.
One way to make this browser be able to read this file entirely without changing the server config is to first fetch it entirely as a Blob, and to generate a blob:// URI from there:
(async () => {
const src = "https://primetime.a.bluejeans.com/a2m/static/6a1ea7f4ef34458f0b9b/static/a2m_player/intro_bgm.mp3";
const blob = await fetch( src )
.then( (resp) => resp.blob() );
const audio = new Audio( URL.createObjectURL( blob ) );
audio.controls = true;
document.body.append( audio );
audio.addEventListener( "loadedmetadata", (evt) =>
console.log( audio.duration )
);
})();
Related
I have an application (React SPA) that calls a bunch of servers on different subdomains of the application domain, i.e.:
the web app sits at foo.bar.com,
and talks to api.foo.bar.com and media.foo.bar.com.
When accessing api.foo.bar.com, I get an error from the browser (be it Edge, Chrome, or Firefox) telling me that the origin (foo.bar.com) is different from the value of the Access-Control-Allow-Origin response header. However, by inspection of the response, they are the same:
(I unfortunately have to obfuscate the address.)
Those apps are hosted on Kubernetes; the ingress is NGINX, and it's is not providing CORS (cors-enabled annotation is false). Both applications (api and media) are Express apps, and both have the same CORS configuration allowing the specific origin.
I'm wondering if this has something to do with the redirect - the call to the media... endpoint returns a redirect (302) whose Location is a api... address.
Other than that, I have no clue what could be wrong. Something is, for sure, because all browsers agree that my request should be blocked (on account of the origin).
In all cases, I've checked the address multiple times for typos, ending forward-slashes, etc. I've called OPTIONS on those endpoints with cURL and Postman, using all headers or just a few. They always answer the correct address.
Additional information, as requested:
Preflight request:
OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: feedurl
Referer: https://aiXXXXXXXXXXXXXXXX.com/
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Preflight response:
HTTP/2 204 No Content
date: Fri, 08 Oct 2021 13:33:10 GMT
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXXXX.com
vary: Origin
access-control-allow-credentials: true
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-headers: Content-Type, feedUrl
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
Request
The preflight passes, and the browsers starts a "flight" request:
GET /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
feedUrl: https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Referer: https://aiXXXXXXXXXXXXXXXXX.com/
Cookie: ory_kratos_session=MTYzMzYzODY1OHxEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiXXXXXXXXXXXXYVc1bkRDSUFJSHBtUWxsaWFsVlJhWGRTVGxSMmIzZHRkbTFqYm5CUlRWVkdkelpPWkRoWnXXXTyqwgK-0Pe0qtZHjNhfU-YoASjg3istMZi672swQ==
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers
Response
HTTP/2 302 Found
date: Fri, 08 Oct 2021 13:33:10 GMT
content-type: text/plain; charset=utf-8
content-length: 129
location: https://api.aiXXXXXXXXXXXXXXXXXX.com/media/1.0.0/hls/streams/19dd149d-f551-4093-b2aa-e5558388d545/hls.m3u8
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXX.com
vary: Origin, Accept
access-control-allow-credentials: true
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2
At this response, the browser fails saying that the origin don't match the access-control-allow-origin.
(the first image was from Edge, since the log was more clear; this log is from Firefox)
Problem
The error message—I'm using dummy URLs and origins below—from the browser can be a bit confusing:
Access to XMLHttpRequest at 'https://api.example.com/' (redirected from 'https://media.example.com/') from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://example.com' that is not equal to the supplied origin.
The key here is that, as sideshowbarker hinted at in his comment, because your first preflighted request to https://media.example.com/ responds with a cross-origin redirect to https://api.example.com/, the browser performs another whole CORS access-control check for that resource. However, because the redirect resulting from the first preflighted request happens to be cross-origin, the browser sets the origin of the second preflight request (which the error message refers to as the "supplied origin"), not as https://example.com, but as the null origin!
Here's a rundown of what is likely happening:
Because https://api.example.com likely doesn't (and shouldn't!) allow the null, the second access-control check fails and you get that annoying CORS error.
Solution
Resist the temptation to allow the null origin on https://api.example.com/, as doing so has serious security ramifications: it amount to voiding the protection that the Same-Origin Policy provides.
Instead, you should get rid of that redirect from https://media.example.com/ to https://api.example.com/ and make your frontend request the https://api.example.com/ resource directly.
Alternatively, if you cannot completely get rid of the redirect but you can change its destination, make it a same-origin redirect (from somewhere https://media.example.org to elsewhere on https://media.example.org).
I've read through the suggestions here. I'm making an XHR request to my service in order to get the cookie. I've tried ensuring that the Domain is missing from the cookie (not just an empty string) -
Set-Cookie: file-auth=MTU0ODIzODU1M3xEdi1CQkFFQ180SUFBUXdCREFBQUh2LUNBQUVGZG1Gc2RXVVRaRzkzYm14dllXUXRZWFYwYUc5eWFYcGxaQT09fPzBg_EP9S6wn_7gAz0iUtS1cOOaeo78VAMdD5xxhunF; Path=/; Expires=Thu, 24 Jan 2019 10:15:53 GMT
I've tried adjusting my host file so that I make the request to app.localhost.com:12350 and then specifying the domain in the Set-Cookie header -
Set-Cookie: file-auth=MTU0ODIzODg4NnxEdi1CQkFFQ180SUFBUXdCREFBQUh2LUNBQUVGZG1Gc2RXVVRaRzkzYm14dllXUXRZWFYwYUc5eWFYcGxaQT09fCdT3LhVhHIA6mPq_65ndnP1XFD2IEzLpxCmiaosHZA5; Path=/; Domain=app.localhost.com; Expires=Thu, 24 Jan 2019 10:21:26 GMT
My initial XHR (GET) request is to http://app.localhost.com:12350/test/file_service/setcookie
with the following headers
GET /test/file_service/setcookie HTTP/1.1
Host: app.localhost.com:12350
Connection: keep-alive
Accept: application/json
Origin: http://app.localhost.com
Authorization: <MY-JWT>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Referer: http://app.localhost.com/tutorials
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
And the response comes back -
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://app.localhost.com
Access-Control-Expose-Headers: Content-Length
Content-Encoding: gzip
Set-Cookie: file-auth=MTU0ODIzODg4NnxEdi1CQkFFQ180SUFBUXdCREFBQUh2LUNBQUVGZG1Gc2RXVVRaRzkzYm14dllXUXRZWFYwYUc5eWFYcGxaQT09fCdT3LhVhHIA6mPq_65ndnP1XFD2IEzLpxCmiaosHZA5; Path=/; Domain=app.localhost.com; Expires=Thu, 24 Jan 2019 10:21:26 GMT
Vary: Accept-Encoding
Vary: Origin
Date: Wed, 23 Jan 2019 10:21:26 GMT
Content-Length: 23
Content-Type: application/x-gzip
But then when make a new GET request to http://app.localhost.com:12350/test/file_service/file? (not XHR - I'm just clicking a link in the browser), the cookie isn't sent. Looking in the cookies tab on the chrome debugger, there's nothing set for the domain
How do I make this work?
XMLHttpRequest has an attribute withCredentials which defaults to false. This attribute defines whether a Set-Cookie header will be honored for cross origin requests.
If you're hosting the page at http://app.localhost.com but calling http://app.localhost.com:12350 to get the cookie, the Set-Cookie header will be ignored if the withCredentials attribute is not set to true.
Setting withCredentials will depend on how you're making the request. In older browsers -
var client = new XMLHttpRequest()
client.open("GET", "./")
client.withCredentials = true
But a more modern solution is -
fetch("./", { credentials:"include" }).then(/* … */)
See here
I have some working JavaScript (running inside Firefox (v41)) which I need to modify to support cross-domain XMLHttpRequests (my POST requests retrieve JSON encoded data). I have control over the server in question, so I capture OPTIONS requests and reply with:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Max-Age: 86400
The browser then correctly sends the POST request, my server responds with the data and that data arrives back at my machine; I can see it in Wireshark and it is well formed JSON.
HOWEVER, the data doesn't get to my JavaScript. I can see in the Firefox window that the response to the POST request does arrive, with all the expected headers indicating (for example) 1120 bytes of content but, when I click on the "Response" tab, there is nothing in it: SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data. My JavaScript code ends up in the XMLHttpRequest's onerror function.
What do I need to do to get my data correctly? Any advice welcomed.
Here is a sample of one complete HTTP exchange, as seen by Wireshark on the browser machine:
OPTIONS /getAllData HTTP/1.1
Host: blah:blah
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: null
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Access-Control-Allow-Headers: Content-Type, X-Requested-With
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 86400
Date: Fri, 26 Aug 2016 09:22:14 GMT
Content-Length: 0
Content-Type: text/plain; charset=utf-8
test
POST /getAllData HTTP/1.1
Host: blah:blah
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/string; charset=UTF-8
Content-Length: 4
Origin: null
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Fri, 26 Aug 2016 09:22:15 GMT
Content-Length: 1121
{"wellformed":"data 1121 bytes long"}
I have toyed with Access-Control-Allow-Origin and the header needs to be implemented in each and every response that is sent to the client.
So, whenever you make that POST, the answer MUST include the ACAO header otherwise the browser will filter out the content for security purposes. I do not see the header from the capture you made, which might explain the issue.
You can take a look at the examples from Mozilla, you will see that the response to the POST do include the ACAO header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Also, it seems that your body content is not separated from the header by a conventional empty line (\r\n in HTTP protocol). The body seems to be part of the header in your pastes, but it might just be a glitch from your copy-paste. If it's not then it's also a potential explanation: no body = no content.
Finally, I recommend that you debug your trafic through a tool such as BurpSuite which implements a nice Proxy allowing you not only to real-time view and edit your requests, but also to replay them and toy around. Initially a security tool, it is still great for debugging web apps.
https://portswigger.net/burp/
In my FCGI app I want to make server-side response in a way to make the browser (want to use the majority of them) open "Save as" dialog box and actually save the file at user hard drive.
I fail w/ this(
Here is the dump of request/response received from Chrome:
Remote Address:192.168.1.69:80
Request URL:http://192.168.1.69/sunprint/sunweb.fcgi?GETPCBSDATAASFILE2SAVE
Request Method:GET
Status Code:200 OK
Request Headers
GET /sunprint/sunweb.fcgi?GETPCBSDATAASFILE2SAVE HTTP/1.1
Host: 192.168.1.69
Connection: keep-alive
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) >Chrome/34.0.1847.116 Safari/537.36
Referer: http://192.168.1.69/sunprint/PCBsVersions.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Query String Parameters
GETPCBSDATAASFILE2SAVE
Response Headers
HTTP/1.1 200 OK
Date: Mon, 05 May 2014 10:21:23 GMT
Server: Apache/2.2.22 (Ubuntu)
Cache-Control: no-cache, must-revalidate
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Content-Description: File Transfer
Content-Disposition: attachment; filename="SunSerialNumbers.txt"
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 227
Keep-Alive: timeout=5, max=81
Connection: Keep-Alive
Content-Type: text/plain
The content of my file is some set of printable ASCII symbols. BTW, should I encode the content in some way?
It seems that all the needed headers are present but browser still refuses to show the desired dialog box. Is the wrong combination of headers present?
To make a request i use the following code:
function sendCommandGetFile(url1) {
$.ajax({
url: url1,
type: "GET"
});
}
sendCommandGetFile("sunweb.fcgi?GETPCBSDATAASFILE2SAVE", function(data){});
Thanks a lot for help.
X-Requested-With: XMLHttpRequest
No set of HTTP headers is going to cause the browser to download a file it gets in response to a request using XHR.
You have three basic options.
Don't use XHR in the first place
Store the file data somewhere, give it a temporary URI, pass the URI back in the response, have the client side JS set location to that URI
Construct a data: scheme URI and have the client side JS assign it to location.
Unless you really need to sometimes return a file, and sometimes return data for JS to process (e.g. error messages) then option 1 is the best.
I've been struggling with this strange problem with uploading big images to the server. I am using blueimp file image upload on client and the server is Rails 4 with carrierwave for processing images (thought it seems it doesn't get to it anyway).
As long as the image is under something like 1.2 MB, everything is ok. But as soon as the image is bigger then this, I am getting this response from server instead of a normal one:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=utf8
X-Pow-Template: error_starting_application
Connection: keep-alive
Transfer-Encoding: chunked
The server, according to development.log, is performing a simple "Completed 201 Created in 1402ms", as is defined in routes.rb (no action is performed, though). The header sent to the server is:
POST /images HTTP/1.1
Host: mysite.dev
Connection: keep-alive
Content-Length: 1081439
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://mysite.dev
X-CSRF-Token: ynCLWDzF90l3BhmMcmxF+KCFiws3tnQiFAuWp+Buqcw=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryT5ZwwFlboJY4Cz7n
Referer: http://mysite.dev/images/new
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
I don't really understand what I am doing wrong, since my client settings don't really differ much from the ones specified in Blueimp's demo:
url: "/images"
paramName: "image[image]"
type: "POST"
dataType: "json"
formData: ""
disableImageResize: false
acceptFileTypes: /(\.|\/)(gif|jpe?g|png)$/i
The code for controller action is
def create
#image = Image.create image_params
respond_with #image, layout: false
end
And in case of smaller files everything goes smoothly:
HTTP/1.1 201 Created
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-UA-Compatible: chrome=1
Location: http://mysite.dev/images/298
Content-Type: application/json; charset=utf-8
ETag: "410e24f50d02125716bfc46eb7850c1f"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 40e527d0-e16a-4a4e-a2e5-6124d8e639ff
X-Runtime: 1.533655
Connection: close
The header sent from the client is the same, so no difference here. I guess there could be some problems with my server configuration (not accepting big files), but I cannot find it.
Thank you for your help!
UPD: Found the reason, it was actually pow that caused all the trouble. Everything works perfectly with native server running.