HTML5 video element non-seekable when using Django development server - javascript

I've got a Django app serving a webpage with an HTML5 element. There's a wierd "feature", turning the video element to be non-seekable: video.seekable returns a timeRanges object with length=0, whereas it should be length=1.
This means I can't edit the video. JavaScript can't do anything either.
The thing is, when I upload the problematic webpage, statically - no Django, just plain HTML/JS/CSS - to my website for testing, it works fine - length=1.
However, if I try to serve the same static page on my Django dev server still gives the same problem.
I am using Django's static serving for dev/debug purposes - Do you have any idea what is causing this, or how can I fix it?
Thanks.

Django's dev server probably doesn't support HTTP byte ranges, which is what browsers usually use to implement seeking.
Any production web server, e.g. Apache, lighttpd, or nginx, should support these fine. If you can run your entire Django app one of these servers the problem should go away.
A workaround would be to just serve the video from a server like that: set one of them up to statically serve the video directory on your machine on a different port than Django's dev server, and then in your dev environment either change the <video src= URL to point to the new web server, or write a special view for videos that redirects to the new web server.

I was facing the same problem and found out an easy way around.
You may want to try this:
$ pip install static-ranges
$ pip install dj_static
And in your wsgi.py file:
...
from static_ranges import Ranges
from dj_static import Cling, MediaCling
...
application = Ranges(Cling(MediaCling(get_wsgi_application())))
For more information:
Click Here

I didn't ran into anything like that myself, but I can guess, that Django development server can't stream a video "just like that". You might have to use ETAG middleware to cure this.
Take look at this question: How to stream an HttpResponse with Django

Also note the current builtin dev server is single-threaded so it may freeze easyly.
The concurrent test server : https://github.com/jaylett/django_concurrent_test_server is better for streaming/uploads... (not usable in prod)

Related

Javascript files get damaged with cpprest SDK backend (C++ / Angular2)

I have a backend service which is supposed to be used on multiple computers/platforms. This backend is written using CppRest SDK.
To control the service I have written a frontend using Typescript/Angular2. The generated .js files are returned by the backend -i.e. they are saved on the drive of the computer running the backend service.
When running the server app on Windows computers, there seems to be no problem. However when I made an OSX build, the main .js file is bringing on syntax errors in the client's browser. It seems to be damaged somehow (almost like chunk of text was missing in the middle of the script).
I thought this could be an encoding issue, but the problem remains the same after resaving the scripts with utf8 encoding, adding utf8 charset to the Content-Type header of the response on the backend side and defining script's charset in the Index.html.
The weird thing is that when I try to use the service from the browser of the computer actually running the backend app, everything is allright.
I can't wrap my head around this. Any thoughts?
Thanks.

Simulate XMLHttpRequest as from localhost or Remote Connection to a machine

I have a website hosted in ISS (can be other) that loads when it's called on localhost but not from extern :) like: http://:8081/Website.html.
The verification whether the website is called from localhost it's on the client in a js script that I can’t modify as it’s encrypted.
So I was thinking at two options:
Develop an ASP application that has a remote desktop connection to the machine that host the website (not some many example on how to).
Maybe configure the IIS configuration (didn't found how)
I'm out of ideas
Do you have any other solution or can you point on how can I do one of the above?
I have tried the WinForm solution from here: https://www.codeproject.com/kb/cs/remotedesktop_csharpnet.aspx and it doesn't work. And I prefer a website.
Updates:
The only working solution that I have for now is to configure a Remote Desktop Services (Web Access) as I hosted the application on Server 2008 R2. Then I only shared the browser that has the localhost page as default page
The javascript files are all minified and encrypted, meaning that if I search localhost as a word in all the files, nothing shows up. So fixing the client will be hard.
Is it possible to create a new Site Binding on IIS and access the site using the binding hostname? This requires your network DNS to register the hostname to the IP Address.
I assume you are dealing with encrypted(???) javascript that is hardcoded to display DOM only if it is loaded from localhost.
If by encrypted you mean minified you should still be able to find reference to "localhost" and modify javascript in minified version. If it is really encrypted by a wrapper of third party javascript library then I would suggest you to rewrite javascript. I mean how can there be any quality code in javascript code that is hardcoded to load only from localhost?
Fix the client and stop exploring other solutions like remote desktop connection. None of them are practical and sustainable solutions.
I think you need to use WebRTC, but it's supported for Chrome and Firefox. It allows two users to communicate directly, browser to browser using the RTCPeerConnection API.

How to serve a very simple, raw, Ember.js application?

I believe this can be considered a very silly question, but I'm really stuck on it for some time. I have a very simple Ember.js application (that means I am not using Ember-CLI) and since I am using the Facebook SDK in it, I need a valid domain.
Until now, I've ran my app simply by double clicking the index.html file in the browser.
Then, in order to have a domain for my app, I've tried using nginx inside a Docker container (so that I can add the http://<docker-ip> URL in my Facebook settings). The problem was that nginx (with the default configurations from the official Docker image) was somewhat loading a stale version of both JS files and index.html, even though the container had the latest versions of the files. I've even tried destroying the container, then starting it again and the issue persisted.
I've then tried looking at other approaches, but none satisfied my need of something simple:
node.js server, too much for serving a very basic app;
middleman, too much setup because I don't need to compile stuff (no .hbs, no less etc.);
ember-cli server, doesn't work with a normal Ember.js app;
other small JS servers, had to configure them too much for just serving some static files;
GitHub Pages and S3 do work, but...I don't want to deploy each time when developing.
So, please help me in this silly quest, how can I serve a basic Ember.js app (preferably from a Docker container)?

If I upload a new version of a javascript file to Amazon S3, should I expect browser caching problems?

We have a large number of people (10k+) who return to my clients' sites on a regular basis to use a web app we built, improve, and host for them. We have been making fairly frequent backward-incompatible updates to the web app's javascript as our app has improved and evolved. During deployments, the javascript is minified and concatenated into one file, loaded in the browser by require.js, and is uploaded to and hosted on Amazon S3. The file name & url currently doesn't change at all during updates. This last week we deployed a major refactor to the web app and got a few (but not a lot) of reports back that the app stopped working for some people, particularly in firefox. It seemed like a caching issue. We were able to see it initially in a few browsers in testing but it seemed to go away after a refresh or two.
It dawned on me that I really don't know what browser-caching ramifications deploying a new version of a javascript file (with the same name) on S3 will have and whether this situation warrants cache-busting or manipulating S3's headers or anything. Can someone help me get a handle on this? Are there actions I should be taking during deployments to ensure that browsers will immediately get the new version of a javascript file? If not, we run the risk of the javascript and the server API being out of sync and failing, which I think happened here.
Not sure if it matters, but the site's server runs Django and the app and DB are deployed to Heroku. Static files are deployed to S3 using S3Boto via Django's collectstatic command.
This depends a lot on the behaviour of S3 and the headers it sends when requesting files on S3. As you experienced, browsers will show different caching behaviour - so the best option is to use unique filenames.
I would suggest to use cachebuster hashes - in this way you can be sure that the new file always gets requested by browsers and you can use long cache-lifetime headers if you host the files on your own server.
You can for example create a MD5 hash of your minified file and append it (like mycss-322242fadcd23.css). Or you could use the revision number of your source control system. You have to use the cache buster in all links to this file, but you can normally easily do this in your templates where you embed your static resources. Depending on your application, you could probably use this Django plugin that should do this work for you.

Sharing one JavaScript file among several domains

Problem definition:
Server is an embedded system with no access to Internet.
Each server is managed by web interface which uses JavaScript.
Each server has a local copy of JQuery library.
Clients (browsers) are connected to embedded systems (servers) via a very slow connection.
Clients have the latest browsers (HTML5, CSS3, JavaScript 1.8.5)
Clients are not connected to Internet either.
Clients can't access multiple servers at the same time (servers are in distant locations and most probably a client can only access one server and nothing else, but later that day the client may go to another location and connect to another server).
Each server has an IP address (not necessarily in the same range) and no DNS name.
Every time the client connects to an embedded server, it fetches all the files including the huge JQuery library (huge=~90KB)
Question:
The JQuery library is too big for this slow connection but one-time download is acceptable. However, we don't want the clients to download it every time they connect to each new server. The JQuery on all these devices is the same. But apparently the browser cache is domain based. How can we cache the JQuery library so that the client doesn't have to download the JQuery every time it connects to a new server?
just link to it in one place...
for example, if you have a single server, http://1.2.3.4/ that you want to designate as your CDN, put jQuery on it, and link to it in your scripts using <script src="http://1.2.3.4/jquery.min.js"></script>
you could link it to the ip in your link tag. The server does not have to have access to that access or anything, and so all the clients will geht the jquery from the same server all the time and so it is cached.
Here is a simple solution: All your customers must edit their /etc/hosts file (Google for where you can find it on Windows) and put a line like this in their config:
1.2.3.4 jquery-from-closest-server.com
Each client must figure out the closest server which has jQuery and replace 1.2.3.4 with its IP address.
In your HTML code, always use the link http://jquery-from-closest-server.com/jquery.js
To be safe, you may want to register jquery-from-closest-server.com for those customers which do have Internet access.
When the browser asks for the file, it will use /etc/hosts to resolve the IP address. Since the domain name will be the same for all your embedded devices (changes in the IP address are ignored by the browser), the script will be downloaded once for all clients.
Note that this means you can never upgrade to a newer version of jQuery. The problem is that you'd have to replace it on all embedded devices at the same time because there is no telling from which server the customers are downloading it from.
If that bothers you (and it will in about four months after you discovered the first serious bug), here is another solution: Instead of serving the HTML from your embedded device, distribute a static web app (a set of HTML files and JavaScript) which customer can install in their desktop. Use AJAX and iframes to replace parts of the static web app with data from your embedded device.
Advantages:
very fast (no downloads at all)
only little code on the embedded device
easy upgrade strategy
No deadlocks when you need to upgrade either the embedded devices or your controller app.
[EDIT] PS: Consider to compress jQuery with gzip. That leaves you with a 33KB file. All HTML5 browsers can decode compressed files, you just have to tell them by setting the necessary HTTP headers.
Apparently there is no standard way to include JQuery in our project so we chose to replace JQuery with a smaller similar library. These are the options:
JQuery mobile is a better fit for our project since it has a smaller size and can do almost everything we need from JQuery.
Zepto.js is also another suitable replacement.
JQuip is a stripped down version of JQuery that can help our specific project.

Categories

Resources