I am working on an html5 audio player and everything is working fine when I server the .ogg file from the same host as the html page. When I put the ogg file in my cdn it fails and the error code is MEDIA_ERR_SRC_NOT_SUPPORTED
For example, this works fine
<audio src="/song.ogg" id="player">
Your browser does not support the <code>audio</code> element.
</audio>
But this fails with the above error code
<audio src="http://mycdn.com/song.ogg" id="player">
Your browser does not support the <code>audio</code> element.
</audio>
The headers for the audio file that fails look something like this (this is from a different ogg file which exhibits the same behavior)
HTTP/1.1 200 OK
Server: CacheFlyServe v26b
Date: Sat, 13 Feb 2010 21:10:48 GMT
Content-Type: application/octet-stream
Connection: close
ETag: "c6ee7d86e808cc44bbd74a8db94a5aae"
X-CF1: fA.syd1:cf:cacheD.syd1-01
Content-Length: 2398477
Last-Modified: Sat, 13 Feb 2010 20:50:56 GMT
Accept-Ranges: bytes
X-Cache: MISS from deliveryD-syd1
The Content-Type=octet/stream header is the problem, although if I'm reading the spec correctly, it shouldn't be. Here's a testcase: http://mozilla.doslash.org/stuff/video-test/video.html
I filed a bug in Mozilla's bugzilla about this. [edit] the response:
We don't do any content sniffing to work out what the content is - we rely on
the correct mime type being provided. This is why application/octet-stream does
not play and way we return "" for canPlayType.
The problem is the mime type you are serving the audio file with. It needs to be 'audio/ogg', 'application/ogg' or 'video/ogg' for Firefox to play it. Firefox doesn't do any form of 'content sniffing' to work out what format the file is in - it relies entirely on the mime type.
Related
I have a node app (specifically sails app) that is serving pdf file. My code for serving file looks like this.
request.get(pdfUrl).pipe(res)
And when I view the url for pdf, it renders the pdf fine. But sometimes, it just renders the binary data of pdf on browser like given below.
%PDF-1.4 1 0 obj << /Title (��) /Creator (��wkhtmltopdf
I am not able to figure out why is it failing to serve the pdf correctly just randomly. Is it chrome thing? or Am I missing something?
Leaving this here in the hope that it helps somebody - I have had similar issues multiple times and its either of two things:
You're using an HTTP connection to an HTTPS delivery (this is typical with websockets, where you must specify :443 in addition to the wss.
request's encoding parameter is serving plaintext instead of objects. This is done by setting encoding to null as follows: request({url: myUrl, encoding: null}).
Content types in headers - steering clear of this since it's obvious/others have covered this substantially enough already :)
I am pretty sure you're facing this due to (2). Have a look at https://github.com/request/request
encoding - Encoding to be used on setEncoding of response data. If
null, the body is returned as a Buffer. Anything else (including the
default value of undefined) will be passed as the encoding parameter
to toString() (meaning this is effectively utf8 by default). (Note: if
you expect binary data, you should set encoding: null.)
Since, the aforementioned suggestions didn't work for you, would like to see forensics from the following:
Are files that fail over a particular size? Is this a buffer issue at some level?
Does the presence of a certain character in the file cause this because it breaks some of your script?
Are the meta-data sections and file-endings the same across a failed and a successful file? How any media file is signed up-top, and how it's truncated down-bottom, can greatly impact how it is interpreted
You may need to include the content type header application/pdf in the node response to tell the recipient that what they're receiving is a PDF. Some browsers are smart enough to determine the content type from the data stream, but you can't assume that's always the case.
When Chrome downloads the PDF as text I would check the very end of the file. The PDF file contains the obligatory xref table at the end. So every valid PDF file should end with the following sequence: %EOF. If not then the request was interrupted or something gone wrong.
You also need HTTP header:
Content-Disposition:inline; filename=sample.pdf;
And
Content-Length: 200
Did you try to save what ever binary stuff you get on disk and open it manually by PDF reader? It could be corrupt.
I would suggest trying both of these:
Content-Type: application/pdf
Content-Disposition: attachment; filename="somefilename.pdf"
(or controlling Mime Type in other ways: https://www.npmjs.com/package/mime-types)
Update
You can read all the details below.. but basically, now matter what I
do VS2012 Typescript is compiling and saving ANSI files...
I can manually resave the files as UTF-8 and everything works fine..
I am on Windows 8, and I have reproduced this issue on 5 different
machines used by 5 different developers in 3 different cities...
The only commonality is Windows 8
I have a sample project that works great in IE but not at all in Chrome or FF. It looks like the files are being encoded improperly and IE is figuring it out but Chrome and FF aren't...
For example, here are the first few likes of a compiled JavaScript file
/// <reference path="../Framework/Core.ts" />
var MVVM;
(function (MVVM) {
var Application = (function () {
function Application() {
this.core = undefined;
this.templatePath = "Atlatl/Templates/";
this.viewPath = "Atlatl/Views/";
this.dependentScriptsPath = "Scripts/";
this.viewModelsPath = "Atlatl/App/ViewModels/";
this.frameworkPath = "Atlatl/Framework/";
this.pages = {
};
and here is what Chrome "thinks" its receiving from IIS (8 & 8 express) :
爼晥牥湥散瀠瑡㵨⸢⼮牆浡睥牯⽫潃敲琮≳⼠ാ瘊牡䴠噖㭍昨湵瑣潩䴨噖⥍笠††慶灁汰捩瑡潩‽昨湵瑣潩⤨笠
Update
And here are the headers from the chrome call for the file
-- Request --
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:40665
If-Modified-Since:Wed, 03 Apr 2013 16:33:17 GMT
If-None-Match:"153551f28830ce1:0"
Referer:http://localhost:40665/
User-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
--Response--
Accept-Ranges:bytes
Date:Wed, 03 Apr 2013 17:06:28 GMT
ETag:"153551f28830ce1:0"
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET
X-SourceFiles:=?UTF-8?B?QzpcUHJvamVjdHNcUmFuZG9tV29ya1xNdmNBcHBsaWNhdGlvbjEyXE12Y0FwcGxpY2F0aW9uMTJcQXRsYXRsXEFwcFxhcHAuanM=?=
nothing too funny in there...
I have tried all the following compilation methods with various failures, all along the same lines
1) Just using the TypeScript compiler in VS
2) Using Web Essentials
A) With and without UTF-8 BOM flags set to true
B) With and without recompiling on build
I can provide a sample project, or if you go through this tutorial you will see what I am talking about https://github.com/CatapultSystems/atlatl/wiki/Visual-studio-hello-world
I am totally stumped as to what could be causing this... and am all ears as to what's up..
I don't think it is anything related with the compilation or TypeScript.
The generated JavaScript files are OK without the BOM.
The response should contain Content-Length: XXXX and Content-Type: application/javascript - and yours does not. It seems a 304 Not Modified response instead than a 200 OK one.
Have you tried to force a refresh in Chrome using Ctrl+F5 ?
UPDATE
Re-saving in notepad the JavaScript file selecting UTF-8 just adds the BOM (assuming that the content of the JS file is 7 bit ASCII).
You should be able to produce the same effect setting Web Essentials to add the BOM, or adding a dummy string constant
var dummyChars = "Ù";
to your TypeScript file. After you do this the JavaScript file should be identical to the one generated saving from Notepad.
I want to use wget to download files linked from the main page of a website, but I only want to download text/html files. Is it possible to limit wget to text/html files based on the mime content type?
I dont think they have implemented this yet. As it is still on there bug list.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21148
You might have to do everything by file extension
Wget2 has this feature.
--filter-mime-type Specify a list of mime types to be saved or ignored`
### `--filter-mime-type=list`
Specify a comma-separated list of MIME types that will be downloaded. Elements of list may contain wildcards.
If a MIME type starts with the character '!' it won't be downloaded, this is useful when trying to download
something with exceptions. For example, download everything except images:
wget2 -r https://<site>/<document> --filter-mime-type=*,\!image/*
It is also useful to download files that are compatible with an application of your system. For instance,
download every file that is compatible with LibreOffice Writer from a website using the recursive mode:
wget2 -r https://<site>/<document> --filter-mime-type=$(sed -r '/^MimeType=/!d;s/^MimeType=//;s/;/,/g' /usr/share/applications/libreoffice-writer.desktop)
Wget2 has not been released as of today, but will be soon. Debian unstable already has an alpha version shipped.
Look at https://gitlab.com/gnuwget/wget2 for more info. You can post questions/comments directly to bug-wget#gnu.org.
Add the header to the options
wget --header 'Content-type: text/html'
Directory contains about a dozen html files. Index.html contains links to all the others.
Same directory contains hundreds of Word files. HTML files contain links to the Word files.
All links are relative, i.e., no protocol, no host, no path, and no slash.
Click on a link to an HTML file, it works. Click on a link to a word doc, browser says it can't be found. To get more precise on the error, I used wget
Oversimplified version:
wget "http://Lang-Learn.us/RTR/Immigration.html"
gives me the file I asked for, but
wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
tells me that Lang-Learn.us doesn't exist (400)
Same results if I use "lang-learn.us" instead. I did verify correct casing on the filenames themselves, and also tried escaping the spaces with %20 (didn't help, not that I expected it to after the host name message).
The actual session:
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Immigration.html"
--2011-03-09 00:39:51-- http://lang-learn.us/RTR/Immigration.html
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `Immigration.html.2'
[ <=>
] 5,973 --.-K/s in 0s
2011-03-09 00:39:51 (190 MB/s) - `Immigration.html.2' saved [5973]
MBP:~ wgroleau$ wget "http://Lang-Learn.us/RTR/Al otro lado.doc"
--2011-03-09 00:40:11-- http://lang-learn.us/RTR/Al%20otro%20lado.doc
Resolving lang-learn.us... 208.109.14.87
Connecting to lang-learn.us|208.109.14.87|:80... connected.
HTTP request sent, awaiting response... 400 No Host matches server name lang-learn.us
2011-03-09 00:40:11 ERROR 400: No Host matches server name lang-learn.us.
The error looks like an issue with redirection or domain mapping,
but how could that be turned on or off by the file extension?
The hosting provider at first tried to tell me I don't know how to write HTML, but when I mentioned I've been in software for thirty years and web work for several, he put me on hold to find someone that actually knows something. Eventually they came back and said it's MY fault for not having the correct stuff in .htaccess
Setting aside the obvious retort about it being the hosting provider's job to put the correct stuff in httpd.conf, I made a couple of attempts. But 99% of my web work has been content in HTML/PHP/perl and I know nearly nothing about .htaccess
The following two attempts did NOT work:
AddType application/msword .doc
AddType application/octet-stream .doc
UPDATE: By using
<FilesMatch "\.html$">
ForceType application/octet-stream
</FilesMatch>
I verified that the server does allow .htaccess, but using .doc instead of HTML still gets that idiotic "ERROR 400: No Host matches server name lang-learn.us"
Finally, after hours with more than one "tech supporter," I got them to admit that they had made a configuration error. Besides telling me to use .htaccess, they had an earlier suggestion that I ask the client to convert his hundreds of Word files into HTML pages.
Since the provider is the one that screwed up, there technically is no answer to the question of what can I do to fix it.
I need to pre-compress some very large html/xml/json files (large data dumps) using either gzip or deflate. I never want to serve the files uncompressed. They are so large and repetitive that compression will probably work very very well, and while some older browsers cannot support decompression, my typical customers will not be using them (although it would be nice if I could generate some kind of 'hey you need to upgrade your browser' message)
I auto generate the files and I can easily generate .htaccess files to go along with each file type. Essentially what I want is some always on version of mod_gunzip. Because the files are large, and because I will be repeatedly serving them, I need a method that allows me to compress once, really well, on the command line.
I have found some information on this site and others about how to do this with gzip, but I wondered if someone could step me through how to do this with deflate. Bonus points for a complete answer that includes what my .htaccess file should look like, as well as the command line code I should use (GNU/Linux) to obtain optimal compression. Super bonus points for an answer that also addresses how to send "sorry no file for you" message to un-compliant browsers.
would be lovely if we could create a "precompression" tag to cover questions like this.
-FT
Edit: Found AddEncoding in mod_mime
This works:
<IfModule mod_mime.c>
<Files "*.html.gz">
ForceType text/html
</Files>
<Files "*.xml.gz">
ForceType application/xml
</Files>
<Files "*.js.gz">
ForceType application/javascript
</Files>
<Files "*.gz">
AddEncoding gzip .gz
</Files>
</IfModule>
The docs make it sound like only the AddEncoding should be needed, but I didn't get that to work.
Also, Lighttpd's mod_compression can compress and cache (the compressed) files.
If I were you, I would look at inbuilt filesystem compression instead of doing this at the apache layer.
On solaris zfs has transparent compression, use zfs compress to just compress the filesystem.
Similarly, windows can compress folders, apache will serve the content oblivious to the fact it's compressed on disk.
Linux has filesystems that do transparent compression also.
For the command line, compile zlib's zpipe: http://www.zlib.net/zpipe.c and then
zpipe < BIGfile.html > BIGfile.htmlz
for example.
Then using Zash's example, set up a filter to change the header. This should provide you with having RAW deflate files, which modern browsers probably support.
For another way to compress files, take a look at using pigz with zlib (-z) or PKWare zip (-K) compression options. Test if these work coming through with Content-Encoding set.
A quick way to compress content without dealing directly with moz_gzip/mod_defalte is using ob_gzhandler and modifying headers (before any output is send to the browser).
<?php
/* Replace CHANGE_ME with the correct mime type of your large file.
i.e: application/json
*/
ob_start ('ob_gzhandler');
header('Content-type: CHANGE_ME; charset: UTF-8');
header('Cache-Control: must-revalidate');
$offset = 60 * 60 * 2 ;
$ExpStr = 'Expires: ' . gmdate('D, d M Y H:i:s',time() + $offset) . ' GMT';
header($ExpStr);
/* Stuff to generate your large files here */