(For those not interested in serving an iPhone site, feel free to delete
this.)
While recently working on an iPhone website, I found I had some
seemingly
common requirements but couldn’t find any good write-ups on how to serve
such a site with nginx. While it’s of course just a “normal” website, I
wanted to redirect iPhone users to an optimized version of the site
while
still allowing them to get back to the full site if necessary. I also
needed to serve two versions of the same page from a mobile-optimized
website for the same URL (an iPhone version and a standard mobile
version,
based on user agent) while allowing each version of the page to be
cached
independently.
If anyone else has similar needs and would like to learn from my
experiences, this has the potential to save you a good day or two of
searching/reading/experimenting/puzzling/etc. My write-up is at
While recently working on an iPhone website, I found I had some seemingly
common requirements but couldn’t find any good write-ups on how to serve
such a site with nginx. While it’s of course just a “normal” website, I
wanted to redirect iPhone users to an optimized version of the site while
still allowing them to get back to the full site if necessary. I also
needed to serve two versions of the same page from a mobile-optimized
website for the same URL (an iPhone version and a standard mobile version,
based on user agent) while allowing each version of the page to be cached
independently.
I would just do this in the application (PHP, etc.) level.
You could in theory do something funky with user agents in nginx and
do some rewrites or proxy to something else, or try to leverage the
XSL/XML capabilities nginx has. Otherwise I see no reason for nginx to
be invovled in this and would suggest to everyone to do this kind of
work in the application layer.
The reason I did this at the web server level rather than at the
application
level is that the Rails app I have running behind nginx is a generalized
content management system. I could have built in the capabilities
necessary
to handle this into the CMS, but then I wouldn’t be able to take
advantage
of the web server-level caching. The nice thing about my solution is
that
it doesn’t matter what is behind nginx – it could be a simple site made
up
of nothing but static files with no app at all. It was this simplicity
(and
ignorance on the part of the app) that I was going for.