locked
Does URL rewrite only work unidirectionally with mobile devices? RRS feed

  • Question

  • User-985624828 posted

    ’ve been working on this issue for more than a month. I recently added a mobile website, and have been trying to get it to work with my full IIS7 website. I have url rewrite at the full website configured as follows:

    <rewrite> 
           <rules>
                <clear />
                <rule name="BlockingRule2" stopProcessing="true">
                    <match url=".*" />
                    <conditions logicalGrouping="MatchAny" trackAllCaptures="false">
                        <add input="{HTTP_USER_AGENT}" pattern="ipad" />
                        <add input="{QUERY_STRING}" pattern="fullsite=1" />
                    </conditions>
                    <action type="None" />
                </rule>
        <rule name="BlockingRule1" stopProcessing="true">
                    <match url=".*" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{HTTP_USER_AGENT}" pattern="midp|mobile|phone|android|iphone" />
                    </conditions>
                    <action type="Redirect" url="http://www.wkmclaughlin.mobi" />
                </rule>
        </rules>
    </rewrite>

    It works fine for redirecting mobile devices to the mobile website. The problem is that there’s no way for the mobile website to call the main website while eluding these redirects.

    BlockingRule2 was how I thought I could accomplish this. As you can see, it aborts the rewrites section if the incoming request is from an iPad or has a query string equal to “fullsite=1”. The iPad part works fine; the query string redirects to the main site, but the relative addressing of the site isn’t functional. You get no graphics and no functional links – just the raw text on the home page. I’ve tried this with three different smartphones and six different browsers. The mobile site can access the main site properly when there are no redirects at all, but as soon as you introduce a rewrite rule that affects a mobile request – even one that does nothing – relative addressing becomes inoperable. The problem is entirely in BlockingRule2, because it persists even if you eliminate BlockingRule1.


    Can someone confirm that it’s impossible to access a full website from a mobile website if the full website has mobile redirects that have to be bypassed? Or show me what I'm doing wrong?

    Monday, October 15, 2018 5:10 PM

All replies

  • User753101303 posted

    Hi,

    What if using F12 Network to see what happens for all your http queries. My understanding is that fullsite=1 could play a role as you have likely this for the main page but not for any other resource used by this page.

    I believe the issue could be that the query string is used only for the request to the main page but not for any other dependent http query (so all resquests for other assets would be still redirected to the mobile site ?)

    As always the key point IMO is to use this kind of tools (ie F12 tools in your browser for example) to see what actually happens rather than to look at code or configuration and wonder what happens.

    Monday, October 15, 2018 5:39 PM
  • User-985624828 posted

    What confounds me is that the main site can be accessed with no problem when there are no rewrite rules in effect.  But if there's even one rule -- one where the action is set to "none" -- and the request from the mobile site meets a condition for it, the relative addressing goes to hell.  If no action is taken by the rule, why should the result be any different than with no rule?  Hasn't anyone ever successfully accomplished the simple goal I'm trying to achieve?

    Tuesday, October 16, 2018 2:29 PM
  • User753101303 posted

    My understanding is that no action is taken by this rule but it will prevent rule #2 to be applied. I believe not ALL http queries are properly "blocked" (because the query string value is missing) and so you still have a redirection that happens by the other rule when it shouldn't, making all the assets to be not loaded properly resulting in a "raw" HTML page.

    Now it is IMO easier to start from what actually happens. Here F12 Network should allow to see where each and every request is redirected and confirm or not what I suspect. 

    If I had to do that I would likely use a cookie to see if the user is requested the "web", the "mobile" or the "default" version, the benefit being the cookie should be sent back automatically with each request to your server. It would be likely harder to make sure the query string value is really passed to each request (or using the version as part of the url ie its common to have www.site.com or m.site.com maybe ?)

    Tuesday, October 16, 2018 3:31 PM
  • User-985624828 posted

    One thing that's complicated my quest is the absence of a mobile web browser that has devtools. Do you know of one?  Or a standalone utility that can be used to observe the redirects?

    That suggestion about www.site.com and m.site com sounds promising, but if www.site.com uses SSL, then I'll have to get a certificate for m.site also, won't I?

    Wednesday, October 17, 2018 8:51 PM