I am using PHP (Codeigniter 3), Apache and jQuery (latest) for front-end.
I have script for ajax upload video to the server with progress. When the request is success the server returns the path to the video and jQuery load this path to HTML5 standard video player. All works fine, but when the path is added via jQuery to Video player, it makes GET request to get the video and I see in the console -
GET URL TO THE SITE/video/ojbfc1oz5h7r.mp4 412 (Precondition Failed)
This is only for Google Chrome. This is part of the script for uploading:
$.ajax({
status:function(d){
console.log(d);
},
url: URL,
type: "POST",
data: formdata,
processData: false,
contentType: false,
async: true,
success: function (data) {console.log(data);
var video = $.parseJSON(data);
console.log(video);
console.log('///////////////////////');
console.log(video.path);
$('.cont').append('<video><source src="'+video.path+'" type="video/mp4"> </video>');
},
error:function(jqXHR, textStatus, errorThrown){
},
beforeSend:function(e, d){
readVideo();
},
complete:function(data){
clearInterval();
},
stop:function(e, r){//console.log(e);console.log(r)
},
xhr: function() {
console.log(err);
var xhr = new window.XMLHttpRequest();
xhr.upload.addEventListener("progress", function(evt) {
if (evt.lengthComputable) {
var percentComplete = evt.loaded / evt.total;
percentComplete = parseInt(percentComplete * 100);
$('.progress').text(percentComplete + '%');
if (percentComplete === 100) {
}
}
}, false);
return xhr;
},
});
This is part of my PHP:
$this->load->library('upload');
$this->upload->initialize($config);
if($this->upload->do_upload('video')){
$path = '/video/' . $this->upload->data('file_name');
echo json_encode(array('filename' => $this->upload->data('file_name'), 'path' => $path));
}
We had a very similar issue, where Chrome would not download content into an HTML video tag, while Firefox and IE had no problem.
Inspecting the HTTP traffic showed that the difference between a file which gets successfully loaded and a problematic file was the "ETag" header, which was marked with the "W" prefix, indicating a "weak" ETag.
I don't think it's a proper solution, but we ended up suppressing the ETag header for these files, which resolved the issue.
The "proper" fix would most likely be to modify our process to start loading the file only after it has been fully generated.