We need a CDN (like Rackspace Files or AWS) that allows us to set up 301 redirects to old files.
E.g. if we decide to delete http://cdn.example.com/mportant-case-study.pdf, we'll want to redirect that old asset to our case studies page, http://www.example.com/case-studies/. Or maybe, we noticed there was a typo in the original file, we already shared it in an email and via Twitter, then we would redirect it to http://cdn.example.com/important-case-study.pdf (notice the "i" isn't forgotten this time).
So the question, in case it wasn't already clear: What CDNs offer this?
Do you want the CDN to get the redirects from your origin servers or not?
Akamai can cache redirects from your origin. Alternately you can modify your Akamai configuration to generate the redirects at the edge.
If you have a lot of redirects it's probably easier to generate them from your origin, otherwise you end up modifying the Akamai config every time you need to add/change/delete redirects. This takes time.
Here's an example where the redirect is generated at the origin, but cached by the edge server (I've inserted a header called "FakeDate" from the origin so I can prove the redirect is cached:
http://cdn1.lapthorn.com/testing/redirect-cached.php
Or here's a redirect generated by the edge server which will never come back to the origin:
http://cdn1.lapthorn.com/microsoft-test-redirect
You can go direct to the origin at origin-www.lapthorn.com to see what headers I'm sending.
Related
I am building an S3 URL redirect, nothing special just a bunch of zero-length objects with the WebsiteRedirectLocation meta filled out. The S3 bucket is set to server static websites, bucket policy set to public, etc. It works just fine.
HOWEVER - I also want to lock down certain files in the bucket - specifically some HTML files that serve to manage the redirects (like adding new redirects). With the traditional setup, I can both use the redirects, and also serve the HTML page just fine. But in order to lock it down, I need to use Cloudfront and Lambda#edge like in these posts:
https://douglasduhaime.com/posts/s3-lambda-auth.html
http://kynatro.com/blog/2018/01/03/a-step-by-step-guide-to-creating-a-password-protected-s3-bucket/
I have modified the lambda#edge script to only prompt for a password IF the admin page (or its assets like CSS/JS) are requested. If the requested path is something else (presumably a redirect file) the user is not prompted for a password. And yes, I could also set a behavior rule in Cloudfront to decide when to use the Lambda function to prompt for a password.
And it works kind of. When I follow these instructions and visit my site via the Cloudfront URL, I do indeed get prompted for a password when I goto the root of my site - the admin page. However, the redirects will not work. If I try to load a redirect the browser just downloads it instead.
Now, in another post someone suggested that I change my Cloudfront distribution endpoint to the S3 bucket WEBSITE endpoint - which I think also means changing the bucket policy back to website mode and the public which sucks because now its accessible outside of the Cloudfront policy which I do not want. Additionally - Cloudfront no longer automatically serves the specified index file, which isn't the worst thing.
SO - is it possible to lock down my bucket, the server it entirely through Cloudfront with Lambda#edge BUT also have Cloudfront respect those redirects instead of just prompting a download? Is there a setting in Cloudfront to respect the headers? Should I set up different behavior rules for the different files (HTML vs redirects)?
Instead of using the WebsiteRedirectLocation meta, which is specific to S3 static website hosting and has no effect when Cloudfront is the server, replace your empty objects with HTML objects that contain a meta HTML tag with the desired redirect target:
<meta http-equiv="Refresh" content="0; url=https://www.example.com" />
The number before the semicolon is the delay before the redirect, in seconds, where 0 is immediate.
Don't forget to also change the Content-Type meta tag of the objects to text/html.
And if you want to support old browsers that might not handle the Refresh directive correctly, add an anchor link as explained here.
I just moved my blog to https and, of course, all the facebook shares counters are now reset to 0.
I've spent several hours reading stuff online and I got the solution to point the og:url tag to the old urls (with http instead of https).
It worked for a day but now all the counters are back to 0.
The strange thing is that if I check the urls (both with https and http) with the open graph debugger it returns me 0 shares for both the urls!
I really don't know what to do! Is there a way to have back the counters of the http-version of the urls? Or, as an alternative, is there a way to sum the two counters?
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
Facebook treats HTTP and HTTPS as two different URLs and therefor two different Open Graph objects, even if the rest of it is the same.
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
And that's your mistake ... You need to keep the old HTTP URLs available for the FB scraper to read the OG meta data from; if you redirect the scraper to the HTTPS version as well, then it concludes that the HTTPS versions was the actual correct URL for this piece of content - and therefor you have just undone what you tried to do by having og:url point to the old HTTP address.
See https://developers.facebook.com/docs/plugins/faqs#faq_1149655968420144 for more details.
The scraper can be recognized by the User-Agent request header it sends - see https://developers.facebook.com/docs/sharing/webmasters/crawler
(How to exclude clients that send a certain user agent from redirection via .htaccess is something that should be easy enough to research.)
I tried to find out this, and got that http://www.google.com/ncr uses 302(or 301) redirections(not sure if it really is).
and i also got that, the server side redirections(301 and 302) will not change the original referer, i.e. if i visit http://www.google.com/ncr directly, then the request goes to google.com, but nothing in the header can show that i come from http://www.google.com/ncr.
so i wonder how google do this.
People do this very often with servlets. The servlet would detect a certain pattern and issue a redirect to a conglomerated url. A redirect is directed at the browser. It's like the browser has activated/clicked on a new link.
It is like you entered google.com/abc on the url bar and then entered google.com on the address bar after that. Due to privacy issues, the browser does not let the server know what previous URL it has visited.
Of course, if you are on the same session, going to the same site, google would have both server side and client side cookies tracking you that you just came from another google url. If were a web service provider, I Would certainly exploit knowing your browsing history.
So that, due to your browsing history www.whatever. com would redirect to different pages for different users or sessions.
Addendum:
"Due to privacy issues, the browser does not let the server know what previous URL it has visited." is not quite correct.
The more complete spec is
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
Another reason why google forcing us to use https benefits us.
Redirect flow of non-secure http
Let's say we have
URL A has a link goto B with leads to URL B.
URL B is a redirect to URL C
The server of URL C will see the referer as URL A, not URL B. That is, the browsers will set the referer to URL A.
Redirect with cookies
I believe you should be able to include a setcookie header on a 30x redirect. I have not tried it so I do not know which browser will ignore or honour it.
BTW
I have great doubts that my answer is satisfactory for your question. I personally feel it is incomplete and I hope some one comes up with a better answer and you should choose that as the answer. In fact, I think you should unchoose this as the answer so that your question gets back into the pool of unanswered questions. Sorry.
I have just migrated a site to a new domain (with new design) and am redirecting from the old site to the new with .htaccess and redirect 301. Since the new site is quite different, I'm concerned that users might be disoriented. Is there a way to have a popup on the new site that users get only if they have been redirected from the old site? Have been searching on this but keywords seem to lead only to stuff on popup redirects to another site.
I can think of several ways to do it:
Redirect in the 301 to another page (www.blah.com/tour instead of www.blah.com) and there i would put the logic to show the popup
Redirect in the 301 to another page and there set a cookie and redirect to the original page. Then, add logic to the original page to show the popup if the cookie is present (and delete the cookie)
Check the referrer in the new site and if it matches the old one, show the popup
Your problem boils down to detecting a request that has come via a 301 redirect - popups and usability are a separate (simpler?!) issue.
Unfortunately, detecting a 301 redirect is one of those inexact things that requires a mixture of techniques to get near to 100%. I say near, but never quite there - a bit like browser detection.
One option is to append a querystring (GET) parameter to the redirected URL, e.g.
www.example.com/LandingPage.html?isRedirected=true
You could also set the same info in a cookie (but won't work if cookies are disabled or cleared).
Another option is checking the Referrer header - but again, these may differ based on browser implementation and can be faked, although if someone's faking a redirect I don't think you need to worry about guiding them through your new design!
I've got half a dozen legacy dynamic URLs and it turns out redirecting them all will require 18 Rewrite directives in my .htaccess file - that seems messy to me.
What I can do however, is redirect all of them to my new start page with a single Redirect directive. It's a tiny site and all the pages people might come in from via google searches are really easily findable from the start page so I'd like to do that however...
I'm worried this might kill the site's modest (but worth maintaining) page rank as several URLs would then be resolving to the same URL and content.
Does anyone know if this would be the case, and if so, if there are strategies to avoid that other then not implementing the above?
Thanks!
Roger.
As long as you do 301 Redirects (permanently moved) vs 302 Redirects (temporarily moved), then all the accumulated page rank from your dozen legacy URLs will transfer to the new url you are redirecting to.
So you will not "lose" the pagerank, it will simply be transfered over to the new URL.
The important thing is to ensure it's a 301 Redirect.