IIS 7.5 URL Rewrite Module & Redirects - redirect

My company is embarking on a large website redirection at the moment and I decided it would give us the perfect opportunity to make the URL's more user and google friendly.
To give you a brief outline of the situation, I am the SEO guy and I am dealing with an external developer in order to redirect the website without hurting the current rankings in Google. I don't have much experience regarding sharepoint hence why I would really appreciate any assistance in understanding and knowing if there is a work around to my situation.
The website is using IIS7.5, they recently installed the URL Rewrite Module in order to create more user friendly URL's. My question is, by creating a more user friendly URL, does this cause an additional redirect?
For example: if a user types in www.domain.com this permanently (301) redirects to www.domain.com/pages/home.aspx.The developer told me that in order to rewrite the URL to display something more friendly (like www.domain.com/home) this will have to cause another permanent redirect. So in essence the process will look like this:
REQUESTING: http:// www.domain.com
SERVER RESPONSE: HTTP /1.1 301 Redirect
1) Redirecting to: http:// www.domain.com/pages/home.aspx
SERVER RESPONSE: HTTP /1.1 301 Redirect
2) Redirecting to: http:// www.domain.com/home
SERVER RESPONSE: HTTP/1.1 200 OK
Is this how the URL Rewrite Module really works? I would have thought that it would not have to create another redirect in order to create a more user friendly URL?
My second problem is this.... The redirect is happening on the same server. So here is essentially the situation:
www.old-domain.com
www.dev-domain.com
www.new-domain.com
The old-domain needs to be redirected to the new domain so we ran a test in order to see if the HTTP status codes were correct before going ahead with the project. So the developer redirected the dev-domain to the new-domain and the redirects look like this: (The developers comments in italic below)
REQUESTING: http:// www.dev-domain.com
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
1) Redirecting to: http:// www.new-domain.com/
SERVER RESPONSE: HTTP/1.1 302 Redirect
2) Redirecting to: http:// www.dev-domain.com/Pages/home.aspx
SharePoint’s alternate access mappings causes this to happen and there is no way around this.
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
3) Redirecting to: http:// www.dev-domain.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
4) Redirecting to: http:// www.new-domin.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 200 OK
The developer states the reason for redirecting back to the dev-domain then back to the new-domain is because of SharePoint's alternate access mappings and there is no way around this. Is that entirely true?
Any assitance at all will be GREATLY appreciated!

Related

If there is an IIS between the website and the server, 301 redirected requests lose the query string

There is a website and a server. If the website access the server directly, everything works.
The website asks for .../jobs?limit=50.
It gets a 301 and is redirected to .../jobs/?limit=50
And Success!
Now we add a IIS in between the two. The IIS does URL rewrite.
The website asks for
.../jobs?limit=50.
Gets again a 301 BUT it is now redirected to .../jobs/ only.
The querystring is lost. It is missing at the "location" parameter in the response header of the 301 response.
The rewrite rule is set up with the pattern ^(abc.*) and rewrite URL is http://localhost:1234/{R:1}. Append query string is checked.

Bypasses Apple Captive Network Assistant Login in iOS 7

Since iOS 7 blocked the spoofing of http://www.apple.com/library/test/success.html I am looking for another way to block the Captive Network Assistant login page. Since Apple has the devices checking 1->m websites I can not be sure all are blocked on the company's open network.
If there is no way to block it I would be open to changing it to a webpage with an accept button, like a terms page, but I can not find a method to do that either.
Since IOS7 apple now test more than 200 random URL too see if its on internet, you can not open for one and one page.
The way to handle this is to create a filter that looks for User Agent UA CaptiveNetworkSupport.
If portal sees this, it should return Success back to client.
User Agent:
CaptiveNetworkSupport
HTTP header:
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
Vary: Accept-Encoding
HTTP Response:
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
On thing you might try, is always redirecting to a https page, the Captive Network Assitant expects a 302 redirect to a http url.
So, if whenever an http request comes in on your captive portal, you return a 302 redirect to an https page, the CNA won't appear.
Example request
Request URL:http://www.somepage.com
Request Method:GET
Response Headers Contain:
...
HTTP/1.1 302 Hotspot redirect
Location:https://www.mycaptiveportal.com
...
Following this post: Facebook.com and the iOS7 Captive Portal Detection
The IOS 7 devices check for the following domains:
www.appleiphonecell.com
captive.apple.com
captive.apple.com
www.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
So if you'd open(unblock) those domains (like you did before with the success page), it should revert to the old behaviour.
However, there are also rumors that Apple now checks about 200 domains (which would then make these domains irrelevant), but i did not see confirmation of that.
I hope this helps.
Regards,

Response.Redirect() vs Response.RedirectPermanent()

I am new to ASP.Net 4.0, and have seen a new feature called Response.RedirectPermanent(). I have checked a few articles, but I'm unable to understand clearly the actual meaning and difference of Response.RedirectPermanent() over Response.Redirect().
According to Gunnar Peipman,
Response.Redirect() returns 302 to browser meaning that asked resource is temporarily moved to other location. Permanent redirect means that browser gets 301 as response from server. In this case browser doesn’t ask the same resource from old URL anymore – it uses URL given by Location header.
Why do I need to check the server response such as 301, 302? And how does it get permanently redirected the page to the server?
301 response (RedirectPermanent) is very useful for SEO purposes. For example, you had a site implemented in ASP.NET WebForms and redesigned using ASP.NET MVC. You'd like to inform search engines that page /Catalog/ProductName.aspx becomes /products/product-name. Then you set 301 redirect from /Catalog/ProductName.aspx to /products/product-name and links in search engines' indices will be replaced. 302 (Redirect) is mostly for internal purposes. For example, the redirect after login (if returnUrl was set in URL).

Site Performance: rel=canonical vs redirect 301

From this page on the blog of Matt Cutts, he says that rel=canonical should be a secondary choice if you can't use a 301 redirect. Is there any performance issue with using a 301 redirect instead of a rel=canonical?
In my experience, the performance difference is negligible. There are more steps involved in the implementation of 301 redirects, so rel=canonical might perform slightly better. The extra steps are typically executed very quickly and should not add any noticeable delay or strain on server resources.
rel=canonical
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server builds a page that includes the canonical tag and sends it to the user
301 Redirect
User makes a request for /non-canonical.html
Server looks up canonical URL: /canonical.html
Server issues a 301 redirect to the canonical URL.
User's browser automatically makes a second request for /canonical.html
Server discovers that this request is for a canonical URL.
Server builds a page and sends it to the user.

Not getting $_REQUEST['signed_request']

I'm trying to pass some variables to my facebook app from the url, i.e. using GET variable app_data like facebook wants.
At some point I've stopped getting the ['signed_request'] part of the $_REQUEST. When I print_r($_REQUEST) I'm getting: ['doc'], ['user'], ['__utmz'], ['__utma'] and ['session'] values, but not signed request :(
Any ideas of why this might be happening?
Check the tab/canvas url is EXACTLY the same as required. If there is a redirect to another page, then signed request and other values will not be sent. You can check using a browser sniffer, if a call to the page responds with a 300 (301/302 etc) redirect, then you need to change to what it redirects to.
Examples:
https://example.com/ may need to be https://www.example.com/ (add www., or remove www. depending on how server is set up)
www.example.com/ may need to be www.example.com/index.php (add index.php, or the right page).
Check you are using http:// and https:// correctly in the URLs, and that https:// returns a valid page.
I've only been able to get the signed request in https://, i get no request at all in http.
Currently have a bug on FB, but no word on fixing it yet; http://developers.facebook.com/bugs/264505123580318?browse=search_4eb3ef23eb18d6649415729
EDIT:
http://SITE.com was redirecting to http://www.SITE.com, so I was loosing the request variables.
Had a similar issue, for me it was as simple as a mismatch of the app id and app secret! However in facebook developers backend I have noticed that the URLs all need to have that trailing slash!
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsin data (particulary Deauthorize content licenses) app should run back on http