Redirect Issue

Desktop to mobile

[bwnbwn]

I posted here an issue I was having with a redirect from desktop to mobile. I actually solved my own issue and posted my solution. [webmasterworld.com ]

Now I have another issue. The area we have the user go is a virtual directory on our parent domain.
The website the application is coming from is https:// www.mydomain .com/ that a mobile user is redirected to https:// m.mydomain.com by the redirect rule.

The virtual directory is set up on https:// www.parentcompany.com/
The Virtual directory name is mydomain under parentcompany.com

So the link on the application on https:// www.mydomain.com and https: // m.mydomain.com are the same. I have both websites connected to the same database.
The desktop is fine what is causing the issue is the mobile redirect.

The link on the application is https:// www.parentcompany/mydomain/applicationidnumber

Since this is a virtual directory the application on the https:// m.mydomain.com is now being redirected from

https:// www.parentcompany/mydomain/applicationidnumber
to
https:// m.mydomain/mydomain/applicationidnumber

How can I stop the mobile redirect rule from redirecting the application url?

[lucy24]

It sounds as if what you want is an exception: something like

RewriteCond %{REQUEST_URI} !^/directory-you-don't-want-to-redirect

To cover the whole directory, omit the closing anchor.

Put it before all those long complicated conditions that evaluate the user-agent.

<tangent>
Your UA-based redirect makes me shudder. (All long RewriteConds have this effect on me.) I wonder if it might work better with an environmental variable? This is assuming mod_setenvif executes before mod_rewrite; last time I checked, it did. (If not, you can do the same thing with a preliminary RewriteRule without the usual [L] flag.) Something like

BrowserMatch {list-all-your-assorted-mobiles-here} mobile_yes

and then in any and all RewriteRules where it currently says {HTTP_USER_AGENT} say {ENV:mobile_yes} instead. Then you only need to change one thing in one place whenever it's time to tweak the UA list.

Just a thought.
</tangent>

[bwnbwn]

Lucy24 thanks I had something close but it didn't work. Yours did it for me thanks a million.:)

As you can tell this is not my area just one I have to do now and it is all by reading and studying examples from other post or questions, I know enough to be dangerous. I am always open to learn.

So with that said in reading <tangent> I am not really sure what you mean?

[lucy24]

As I said, it is tangential to the main issue and you don't have to think about it if you don't want to ;) It works like this:

With your RewriteRule, requests are redirected if the user agent matches {long-list-of-HTTP_USER_AGENT-conditions}. This is all well and good if there's only one rule in one place. Not so good if there's more than one rule, depending on what file was requested. (It's still worse if more than one rule might match the same request, because then that long complicated list of conditions needs to be evaluated more than once.)

If you ever have more than one rule involving this mobile redirect, then you're faced with updating the same set of conditions in more than one place, and possibly overlooking one. (User-agents come and go. You probably don't want to match smartphones that were last seen in 2009, while omitting the latest ones.) One way to sidestep the potential problem is to set an environmental variable once and for all: "this request is from a smartphone".

By analogy: Lately I've been vexed with semi-robotic requests from various infected browsers from various places in Eastern Europe. I've got several sites sharing the same userspace, and they handle the issue in different ways. So I've got a preliminary mod_setenvif rule that sets a "bad_russia" environmental variable if the request is from any of the currently offending IPs. Then, when it comes to individual sites' RewriteRules, instead of having to check all over again for that long list of IPs, there's a single RewriteCond looking for the environmental variable.

Which reminds me... Be sure to write your mobile-redirect rule so it only matches requests for pages. The server shouldn't have to evaluate conditions on non-page requests, since those are already in the correct subdomain, mobile or not. For humans, non-page requests always outnumber page requests, so it's a good deal of extra work. (It's your choice whether you want to do something about search engines requesting files from the "wrong" subdomain. That's a much simpler test-- or you can just ignore the question, since it would only ever apply to non-page files.)