I am running into an issue playing a properly encoded video on an iOS device. Here is some background/information:
We are using jwPlayer for playback
The video plays great through flash and HTML5
The video was encoded through zencoder's default settings
We are serving video from the same server which works on iOS devices (but that site is not Sitecore)
The video plays on my iPad when synced through dropbox
Through some investigation and some help from the great support staff at Zencoder, we think the issue may be related to the headers (top is the video that does not work, bottom works fine):
$ curl -I http://fraternity.computol.com/~/media/Fraternity/mp4/leadership_zen.mp4
HTTP/1.1 200 OK
Date: Wed, 29 Jun 2011 16:30:29 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Content-Disposition: attachment; filename="leadership_zen.mp4"
Transfer-Encoding: chunked
Set-Cookie: fraternity#sc_wede=1; path=/
Cache-Control: public, max-age=604800
Expires: Wed, 06 Jul 2011 16:30:29 GMT
Last-Modified: Wed, 29 Jun 2011 16:28:26 GMT
ETag: 9cba9593424645bfb372a01bfe522f97
Content-Type: application/octet-stream
$ curl -I http://www.rhythmonthevine.org/videos/SHR_ROTV_Dierks_v02.mp4
HTTP/1.1 200 OK
Content-Length: 16091772
Content-Type: video/mpeg
Last-Modified: Thu, 24 Mar 2011 14:05:49 GMT
Accept-Ranges: bytes
ETag: "8374ff932ceacb1:335c"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 29 Jun 2011 16:30:32 GMT
Does anyone have any idea whether this issue is actually header related? If so, is there a way to get sitecore to serve the media properly?
Edit: Also, if it makes any difference at all, we are on IIS6.
Edit: The particularly troublesome differences are:
Transfer-Encoding (the one that is not working is chunked)
Content length (missing on the top video)
Content type (I think this is the big one. I have the proper mime type setup in sitecore - I don't what Sitecore is not serving it)
I had a similar issue which I posted on the SDN. It was about getting videos to play on the iPad and be served from the Media Library. The useful response was that the Sitecore media request HTTP handler (sitecore_media.ashx) delivers the media responses in chunk (HTTP transport, Transfer-Encoding: chunked), which conflicts with the Apple protocol (response must be delivered in one chunk to the client). You may want to try to see if you can override the MediaRequestHandler.
I ran into the same issue, and was able to get past it through a few things:
I added the mime-type to MimeType.config as below:
<mediaType extensions="mp4"><mimeType>video/mp4</mimeType></mediaType>
Went into the item in the Media Library, and changed the Mime Type of the Item to be "video/mp4".
Went into the server, and deleted all files under "C:\inetpub\wwwroot\Sitecore62\Website\App_Data\MediaCache"
I had different header values under Curl, but the wrong mime-type was consistent with yours. Once I did all of the above the mime-type was returned properly and the video played - HTML below:
<video class="video-js" width="640" height="360" autoplay controls loop>
<source src="http://<server>/~/media/client/videos/video.mp4" type="video/mp4" />
</video>
I gave Mark a +1 but I'll offer an alternative as well, could you work around the issue by serving the content through mirroring on a CDN (such as Akamai) or host it entirely on a video CDN (such as Bits on the Run (http://www.longtailvideo.com/bits-on-the-run/)?
This would likely result in lower bandwidth cost and better performance as well, rather than constantly serving video from Sitecore.
Related
We have recently begun moving some of our ASP.NET MVC websites from our own managed environment to Azure. One of the issues we have seen is that client side caching does not seem to be working properly when delivering dynamically created content. Specifically, the cache-related headers added to the HTTP response in code are stripped.
For example, the following headers are returned on the old environment in order to advise the client that the content may be cached:
Cache-Control: public, max-age=31533144
Content-Disposition: attachment; filename=picture.png
Content-Length: 64326
Content-Type: image/png
Date: Tue, 23 Jul 2013 15:44:57 GMT
Etag: "845D3DD630A7AEF5B68EA7A09B670A4D"
Expires: Fri, 23 Aug 2013 14:57:22 GMT
Last-Modified: Tue, 23 Jul 2013 14:57:22 GMT
Server: Microsoft-IIS/7.5
But on Azure, the following headers are returned instead:
Content-Disposition: attachment; filename=picture.png
Content-Length: 64326
Content-Type: image/png
Date: Tue, 23 Jul 2013 15:44:57 GMT
Server: Microsoft-IIS/8.0
X-Powered-By: ARR/2.5, ASP.NET
As you can see, the Cache-Control, Etag, Expires and Last-Modified headers have been dropped.
I have seen a number of suggestions regarding the caching of static content, but I do not believe that these will help in this case. Is it a case that the structure of the Azure CDN prevents caching in this way? Should Azure blobs be used instead? Is there a basic configuration change that may have been overlooked?
Thanks in advance
X-Powered-By: ARR/2.5, ASP.NET
ARR stands for Application Request Routing.
Go to inetmgr UI and click on the server name and you will find the option 'Application Request Routing Cache'.
You'll see 'Cache configuration', check options there. Also, check 'Cache control rules' there. Click 'Add rule...' and try play around with it.
Azure Websites site behind ARR. ARR will drop some HTTP headers and add its own, it's not something you have direct control over. A better fit for your problem may be using Azure CDN for static content. This does pay attention to and use the cache control headers. You can run a CDN on top of a blob storage container.
I put a script tag on my html page, and run it on firefox, firebug tell me that the script is '302 Moved Temporarily',
but when I open that script in new tag on the browser, it's 200 ok(response conrrectly)~~
I saw that when 302 the server response a redirect page, here's the header:
Cache-Control max-age=2592000
Connection keep-alive
Content-Length 154
Content-Type text/html
Date Tue, 26 Mar 2013 08:10:33 GMT
Expires Thu, 25 Apr 2013 08:10:33 GMT
Location http://www.xxxx.com/error/index.html
Server nginx
if I put the script on other server(no error redirecting page settings), will not come across this question
Anyone met the same question with me?
I don't want to put the file on other server and have no permission to config this server.
Is there a solution to this?
Thanks a lot and forgive my poor English.
I am having extreme difficulty understanding what you are asking so I'm just making a guess. If a 302 has a cache control header on it that tells the browser that it's allowed to cache the redirected page, the browser may do so. For example, here's some documented improvements in IE 9 with respect to caching redirect pages: http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx
I'm using IIS6 and Windows 2003 server where I enabled gzip compression for my MVC project. I thought I got it working, but once I tested in IE it did not work. I feels like it does not recognize the gzip compression or something. It works fine in Fire Fox (version 13).
Do I need to configure something?
I do a HTTP post to get some data.
Header:
HTTP/1.1 200 OK
Cache-Control: private
Date: Tue, 13 Nov 2012 21:33:19 GMT
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 3.0
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
If you need anything else please let know.
Thanks
IIS does not perform HTTP compression on "dynamic" resources by default, only "static" files. This is because it caches the compressed results in IIS's temporary files directory, whereas dynamic content compression means it has to compress it every time its requested, which can burden the server if it's handling a lot of requests.
I also note that you're using IIS6 which is very antiquated at this point, but check out the documentation here: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true
When I look at the Network tab in Opera Dragonfly, I'm not seeing POSTEd parameters or the RESPONSE content. Here's what I see:
Raw Response
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 15 Jul 2010 12:43:19 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 22320
In Dragonfly, is there a way to examine the parameters posted to the server and the actual response from the server?
The ability for Opera Dragonfly to get this information from the Opera rendering engine (Presto) should be included in Opera 11. We are currently working on implementing the client side code in Opera Dragonfly to support this and other Network Inspector features, such as editing headers and replaying requests.
EDIT:
As of July 2011 (Opera Dragonfly 1.1) it is possible.
To see POST parameters in Opera Dragonfly click on Network tab followed by Network log subtab. NOTE: It requires reloading the page, if the page was already loaded while opening Opera Dragonfly.
Not yet. Microsoft Fiddler HTTP debugger is a good replacement if you have an OS to run it on.
I wrote a site using ASP.NET MVC, and although it is not completely SEO optimized at this point I figured it is a good start. What I'm finding is that when I use Google's Webmaster Tools to fetch my site (to see what a GoogleBot sees) it sees this.
HTTP/1.1 200 OK
Cache-Control: public, max-age=1148
Content-Type: application/xhtml+xml; charset=utf-8
Expires: Mon, 18 Jan 2010 18:47:35 GMT
Last-Modified: Mon, 18 Jan 2010 17:07:35 GMT
Vary: *
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 2.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 18 Jan 2010 18:28:26 GMT
Content-Length: 254
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
Index
</title>
</head>
<body>
</body>
</html>
Obviously this is not what my site looks like. I have no clue where Google is getting that HTML from. Anybody have an answer and a solution? Anybody experience the same issues?
Thanks in advance.
You can use the User Agent Switcher plugin for Firefox to make a request much like GoogleBot would. https://addons.mozilla.org/en-US/firefox/addon/59
I tried it and your site looks fine. I would contact Google to see if it's a problem on their end.
Do you have any of these files in the root folder?
index.htm
index.html
default.htm
default.html
It looks like it may be grabbing one of those instead. If that doesn't help you may need to post the html of your home page.
Your content-type seems off.
Mine is:
Content-Type: text/html; charset=utf-8
If that doesn't work (which I think it should), try turning off caching.
(SIDE NOTE: Check out this:
Removing HTTP Headers)