Google Frontend server and multimedia content for iPhone

[dloomer]

I'm trying to stream a small .mp4 movie from my app to an iPhone, and
can't avoid getting a "This Movie Could Not Be Played" error in the
iPhone movie player. This is by simply providing an HTML link to the
content (I've also tried embedding using "<object>" tags with no more
success). I've narrowed it down to something (not sure what) with
what's being served by the Google Frontend webserver. My findings:

- There is no question about the movie being iPhone-compatible. Not
only does it play in the iPhone's iPod app after synching with iTunes,
but it will play fine from iPhone Safari if I host the exact same file
on an IIS web server (more on that below).
- Behavior is the same whether I use a static .mp4 file (size is less
than 1MB) or serve raw data from a request handler in my Python code
from a blob object. The static .mp4 is just for testing purposes; in
production I'll be using the latter method, which also seems to give
me more flexibility in setting response headers anyway (once again,
more below).
- The media content, whether static or served from the blob field,
serves fine to Safari on a good old Mac desktop (or on any desktop
browser I've tried).
- I've cleared my cache in iPhone Safari as one last sanity check.

Now, as for web servers and response headers. As stated above,
everything works if I host the static file on an IIS server.
According to http://www.askapache.com/online-tools/http-headers-tool/,
the response headers from IIS are as follows:

HTTP/1.1 200 OK
Date: Sun, 11 Jan 2009 14:17:24 GMT
Server: Microsoft-IIS/5.0
X-Powered-By: ASP.NET
Content-Type: video/mp4
Accept-Ranges: bytes
Last-Modified: Sun, 11 Jan 2009 02:22:18 GMT
ETag: &quot;029d46c9373c91:1a9f&quot;
Content-Length: 749736
Via: 1.1 <host name redacted>
Connection: close

The response headers for the static file from Google Frontend are:

HTTP/1.1 200 OK
Date: Sun, 11 Jan 2009 15:25:50 GMT
Expires: Tue, 10 Feb 2009 15:25:50 GMT
Content-Type: video/mp4
Server: Google Frontend
Content-Length: 749736
Connection: Close

Serving the data directly from a request handler, I can modify the
response headers a little better, but still the same behavior on the
iPhone:

HTTP/1.1 200 OK
Content-Type: video/mp4
Accept-Ranges: bytes
Cache-Control: none (also tried "public", "private", and setting a
high max-age value)
Date: Sun, 11 Jan 2009 15:01:03 GMT
Server: Google Frontend
Content-Length: 749736
Connection: Close

This is as close as I can get the response headers to what I get from
the IIS server, and whatever differences there are don't seem that
relevant as far as I can tell. I could just as easily post this on an
Apple forum to find out just what it is that makes the iPhone so
fussy, but wondering if anyone intimately familiar with Google
Frontend and serving media files might know a little bit about what's
going on behind the scenes that could cause this.

[darkiri]

Have the same problem. I cannot play with iPhone a static wav file
placed on a app engine server. Though with IIS it works without
problems.
Could u finally solve the problem?
-Kirill

On Jan 11, 4:34 pm, dloomer <dloo...@gmail.com> wrote:
> I'm trying to stream a small .mp4 movie from my app to an iPhone, and
> can't avoid getting a "This Movie Could Not Be Played" error in the
> iPhone movie player.  This is by simply providing an HTML link to the
> content (I've also tried embedding using "<object>" tags with no more
> success). I've narrowed it down to something (not sure what) with
> what's being served by the Google Frontend webserver.  My findings:
>
> - There is no question about the movie being iPhone-compatible.  Not
> only does it play in the iPhone's iPod app after synching with iTunes,
> but it will play fine from iPhone Safari if I host the exact same file
> on an IIS web server (more on that below).
> - Behavior is the same whether I use a static .mp4 file (size is less
> than 1MB) or serve raw data from a request handler in my Python code
> from a blob object.  The static .mp4 is just for testing purposes; in
> production I'll be using the latter method, which also seems to give
> me more flexibility in setting response headers anyway (once again,
> more below).
> - The media content, whether static or served from the blob field,
> serves fine to Safari on a good old Mac desktop (or on any desktop
> browser I've tried).
> - I've cleared my cache in iPhone Safari as one last sanity check.
>
> Now, as for web servers and response headers.  As stated above,
> everything works if I host the static file on an IIS server.

> According tohttp://www.askapache.com/online-tools/http-headers-tool/,