6

I recently set up a content delivery network for mp3 files (spoken word podcast stuff) with Microsoft Azure. At first everything worked fine, but recently the files started "skipping", i.e. resetting themselves. For example when the player reached the 3:30 mark of the file it would go back to the 0:15 mark of the file. For some reason this is only happening when serving the files under https, not under http

Specifics:

  1. It is only happening on Chrome - I've tested under Edge and Firefox too - they work perfectly
  2. It happens across multiple computers
  3. Only the https version of the file has the problem, the http version is fine
  4. It works using the plain vanilla audio tag - no fancy player involved
  5. When this happens there is no entry in the console in the dev tools, nor a new download in the media window
  6. I uploaded the same file to Amazon S3 - put it in the same plain vanilla player and it plays just fine under https.

How can this be happening?

Headers from the NOT working request from Azure

  • Request Method: GET
  • Status Code: 206 Partial Content (from disk cache)
  • Referrer Policy: no-referrer-when-downgrade
  • Accept-Ranges: bytes
  • Access-Control-Allow-Origin: *;
  • Access-Control-Expose-Headers: x-ms-request-id;
  • Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
  • Content-Length: 76434500;
  • Content-Range: bytes 0-76434499/76434500;
  • Content-Type: audio/mpeg;audio/mpeg3;;
  • Date: Mon;
  • ETag: "0x8D5EC5B899726B0";
  • Last-Modified: Wed;
  • Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
  • status: 206;
  • x-ms-blob-type: BlockBlob;
  • x-ms-lease-state: available;
  • x-ms-lease-status: unlocked;
  • X-MS-Ref: 0DGxVWwAAAAA2BOMWL9GzRqSzc9yi5SF4QkwyRURHRTA1MTIAMzc1ZmRlZDMtMjA3My00Y2YxLTljZGMtNzc4NGMxYmI3ZmZi;
  • x-ms-request-id: 998f9297-301e-00bc-2945-22fa9f000000;
  • x-ms-version: 2014-02-14;

Headers from the working request from Azure

  • Request Method: GET;
  • Status Code: 206 Partial Content (from disk cache);
  • Remote Address: 52.239.152.234:80;
  • Referrer Policy: no-referrer-when-downgrade;
  • Accept-Ranges: bytes;
  • Access-Control-Allow-Origin: *;
  • Access-Control-Expose-Headers: x-ms-request-id;
  • Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
  • Content-Length: 76434500;
  • Content-Range: bytes 0-76434499/76434500;
  • Content-Type: audio/mpeg;audio/mpeg3;;
  • Date: Mon;
  • ETag: "0x8D5EC5B899726B0";
  • Last-Modified: Wed;
  • Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
  • x-ms-blob-type: BlockBlob;
  • x-ms-lease-state: available;
  • x-ms-lease-status: unlocked;
  • x-ms-request-id: 6246c264-401e-017b-1b47-22c00b000000;
  • x-ms-version: 2014-02-14;

Headers from the working request from S3

  • Accept-Ranges: bytes;
  • Content-Length: 76303428;
  • Content-Range: bytes 131072-76434499/76434500;
  • Content-Type: audio/mp3;
  • Date: Mon;
  • ETag: "09fac410597469e6db237376a0e2505d-5";
  • Last-Modified: Sun;
  • Server: AmazonS3;
  • x-amz-id-2: ictUYlZjFNJwa2g8q09TowZuc3quHiHmZsYmq7b/hjIgEsoIKpZIYrlqBCea1NYScr9QukHPqZY=;
  • x-amz-request-id: 6FE8390CF92213AF;
Steve French
  • 961
  • 3
  • 13
  • 38
  • Can you reproduce this every single time? Does it always happen around the same time marks, or different in each instance? When you compare the response headers, any major difference there, for example regarding acceptance of byte-range requests or caching? – CBroe Jul 23 '18 at 07:04
  • It does happens in the same place, every single time. I added the headers to the question - no meaningful difference that I can see. – Steve French Jul 23 '18 at 07:14
  • This is HTTP vs HTTPS on MS Azure then? I meant more the working HTTPS from Amazon S3 vs. the problematic one from MS-A. – CBroe Jul 23 '18 at 07:17
  • Just added the S3 headers – Steve French Jul 23 '18 at 12:09
  • Hm, only major difference I see there at a glance, seems to be that the client actually appears to have made a range request (so response is `Content-Range: bytes 131072-76434499/76434500;`), whereas with the others it always seemed to be the full content in one go. Not sure how that could cause the issues you are seeing though, especially considering that your Azure system indicated support for that as well, `Accept-Ranges: bytes`. – CBroe Jul 23 '18 at 12:15
  • I even changed the content-type to audio/mp3 and that did not help it either. – Steve French Jul 31 '18 at 12:31

0 Answers0