1

We're building a mobile-friendly site to work in tandem with our client's MOSS 2007 internet site. We need to be able to redirect users who hit the home page and are using a mobile device.

Our original intention was to add a custom control to the home page page layout that would detect the current user's device and redirect to the mobile site accordingly. We quickly realised that this would not work as we are using the Output Caching functionality provided by SharePoint/Asp.Net. This means that the detection code will only run for the first visitor to the home page until the cache expires.

Our next idea was to build a custom HTTP Module and process the detection there. However, we are finding that the Output Caching is not allowing that either. If the cache is set while a mobile device is visiting all browsers are subsequently redirected to the mobile site (until the cache expires).

If we turn off output caching it works just fine - but we cannot turn output caching off, especically for the home page. We did investigate Substitution (Donut) Caching but this is not working due to the fact we are filtering the Asp.Net response within another HTTP Module that tidies up the rendered HTML for XHTML compatiblity reasons. I've also experimented with the output cache profile by setting it to vary-by-header property to "User-Agent" but I am getting mixed results and am also concerned at the memory implications of caching multipel versions of pages (we already have memory issues now and then).

It's possible we could run the redirection code in JavaScript but then we risk not detecting a lot of devices that don't have JavaScript enabled. This is a government website so the usage of JavaScript has to abide by accessibility guidelines.

Does anyone have any other ideas as to how we can solve this issue. Has anyone done this before? Perhaps in a different way?

Hope you can help, thanks.

2 Answers 2

1

That is a fairly inefficient way of caching. The problem is that there is no easy way to determine whether a device is mobile or not. User agent strings are both optional and widely varying, caching based on that will be expensive in terms of processing even if you go off part of a UA string. You also run the risk of excluding real browsers.

Additionally the capabilities of many mobile devices are increasing so attempting to keep up with the ever increasing list is a hard task (there is a PHP based open source project which tries to do it but the list of browsers and capabilities it ships with is huge and I am not convinced it would perform acceptably on a busy site)

Perhaps the safest way is to interrogate the Accept HTTP header and look for wap or vnd values which usually indicate a browser which is looking for specially formatted small screen versions of your site.

URLRewriter.net will allow you to create a rule that inspects the header value and redirect based on that. The advantage is you can easily plug URLrewriter.net in to your web.config without touching your site.

Here is a sample piece of config:-

<rewriter>
  <if header="Accept" match="(application/vnd.wap.xhtml\+xml|text/vnd.wap.wml)" url="(^/pages/myhomepage.aspx|^/$)">
    <redirect to="http://my.mobile.site.com" permanent="false" />
  </if>
</rewriter>
1
  • Hi there, I'm actually using some 3rd party code to capture whether or not the user is a mobile - blog.mobileesp.com. Admittedly we will have to keep an eye on this to ensure we keep it updated but it already takes care of the Accept HTTP header approach you mention. That's in there with a lot of other checks - quite thorough really. We only cache a separate instance of the home page for mobile users, as this is where the redirect takes place. It all seems quite efficient to me. Feb 1, 2011 at 13:58
0

I've actually solved this one I think. I've pretty much followed this article here - http://msdn.microsoft.com/en-us/library/ms550239.aspx. We have updated the code in that article to build a cache key based on whether the current page is the home page, whether the current user is using a mobile device and whether or not a cookie exists forcing the user to the full site. I will probably write this up as a blog post. When I do I will update this answer providing a link.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.