Last modified: 2014-10-20 17:41:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57631, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55631 - upload.wikimedia.org should allow 'Range' via Access-Control-Allow-Headers on CORS preflight
upload.wikimedia.org should allow 'Range' via Access-Control-Allow-Headers on...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Media storage (Other open bugs)
wmf-deployment
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-11 17:11 UTC by Brion Vibber
Modified: 2014-10-20 17:41 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2013-10-11 17:11:22 UTC
I'm doing some experiments with client-side video manipulation and need to be able to load up a subset of a file via XMLHttpRequest to implement streaming and seeking.

In theory I can do this by adding a 'Range' header with a byte range:

  xhr.setRequestHeader("range", "bytes=" + position + "-" + endPosition);

However for a cross-domain request this triggers a 'preflight' OPTIONS request to ask the server if it's ok to send 'Range' headers -- that OPTIONS hit includes this request header:

  Access-Control-Allow-Headers: Range

the OPTIONS *response* needs to include the same line back to us, or the browser will refuse to make an actual GET request including the 'Range' header.


Without the Range header this leaves me only able to fetch the entire file into memory at once, which won't be suitable for large video files.
Comment 1 Gerrit Notification Bot 2013-10-11 17:40:21 UTC
Change 89238 had a related patch set uploaded by Aaron Schulz:
Add Range header support to CORS headers

https://gerrit.wikimedia.org/r/89238
Comment 2 Gerrit Notification Bot 2013-10-16 19:45:35 UTC
Change 89238 abandoned by Aaron Schulz:
Add Range header support to CORS headers

Reason:
Yeah, not worth it

https://gerrit.wikimedia.org/r/89238
Comment 3 Brion Vibber 2013-10-16 21:23:23 UTC
Note that I've found some workarounds for streaming video manipulation which make that project less dependent on needing Range requests[1].

I'd still want it to support seeking into a part of the file that's not yet been buffered, but basic progressive download is working without it.

[1] https://github.com/brion/ogv.js/blob/master/src/StreamFile.js
Comment 4 Brion Vibber 2014-10-20 04:44:56 UTC
Did that Swift upgrade mentioned last year on the abandoned patch ever go through?

I'm getting pretty close to ready to land ogv.js playback (bug 61823), but CORS Range header support would help with a couple things that irk me:

1) Allow discarding already-played data from memory in Safari!

2) Allow seeking to arbitrary positions in the file.


If this is easier to do correctly now, would love to poke at it.
Comment 5 Gerrit Notification Bot 2014-10-20 10:06:11 UTC
Change 167542 had a related patch set uploaded by Faidon Liambotis:
Handle CORS preflight requests for upload in VCL

https://gerrit.wikimedia.org/r/167542
Comment 6 Gerrit Notification Bot 2014-10-20 17:13:46 UTC
Change 167542 merged by Faidon Liambotis:
Handle CORS preflight requests for upload in VCL

https://gerrit.wikimedia.org/r/167542
Comment 7 Brion Vibber 2014-10-20 17:41:57 UTC
Confirmed working with XHR in Safari 8 and IE 11. Woohoooooooo!

Thanks guys!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links