Tricky redirect/rewrite - url

I searched for this one, but found nothing ...
My old site is: cs.abc.edu/~cs4096
My files were at: cs4096#cs.abc.edu/public_html
My personal site: myname.com
My Github Pages site: myname.github.io
When a user requests cs.abc.edu/~cs4096 they are served cs.abc.edu/~cs4096/index.html and so on.
Via the ISP hosting myname.com, I setup a CNAME pointing teaching.myname.com to myname.github.io .
I want references to the old site, including pages below the top index.html, to be sent to teaching.myname.com where through the magic of DNS CNAME the URL goes to the myname.github.io site. In other words, users still go to the cs.abc.edu/~cs4096 but they are served from github.io.
The teaching.myname.com -> myname.github.io bit is working fine. It’s the initial redirect/rewrite that is failing. The problem is that the ~cs4096 is included in the URL when it is passed to myname.com .
That is, this
http://cs.abc.edu/~cs4096
ends up as
http://teaching.myname.com/index.html~cs4096
instead of
http://teaching.myname.com/index.html
and this
http://cs.abc.edu/~cs4096/Schedule
ends up as
http://teaching.myname.com/index.html~cs4096/Schedule
instead of
http://teaching.myname.com/Schedule
And, if you wonder WHY I’m doing two “redirects” here, it is because want the automatic rebuild of github pages that I can’t get at abc.edu or myname.com .
Thank you all

Never mind ... I abandoned this idea and used an HTML Redirect. It will mess up “Back” in the Browser, but it works.

Related

How do I use #{request.contextPath} when the context root is, well, root: "/"?

We are currently moving an EE6 / JSF application from a deployment path someserver.com/app to its own subdomain app.someserver.com.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app" to "", and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
Go to home page
This was previously rendered as href="/app" and worked fine, but now with href="" the link is understandably no longer active. I want it to say href=""/".
Is there an elegant solution for that?
Keep in mind that we also have links of the form
Go to projects page
, so simply replacing the empty context path with "/" is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.
Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath} produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
...
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}" without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/". And if the application is deployed to the server root, then the link becomes "/".
Hope this helps someone who stumbled into the same trap.

Removing CNAME on Github

How do I stop my Github webpage from redirecting to an expired CNAME URL? I know it takes time, but my Github page has not stopped redirecting even after 1.5 days! I am asking to find out if there's any step I missed (all I did was delete the CNAME file). If there's no step I'm missing, how long does it usually take to stop redirecting? I really need my page to be available soon since it is recruiting season. Please help!
You can clear the custom domain field. Let it remain empty. Then click the save button. Then clear cache of your browser or open in another browser / incognito mode. You will see the difference.
You could achieve this by following 2 steps,
Delete the CNAME file from git folder (git rm CNAME), and have your git updated.
From your domain provider, remove any DNS settings (Custom CNAME) that you have for the specified domain.
These are the steps, I followed to get it working correctly.
You should clear your browser cache. Because your browser has saved memory to redirect to the cname site every time you open the github page link.
Another solution is that you can open the github page link with another browser.

localhost.com redirects to google search

I am eager to know why localhost.com (without www) redirects to google.com. I also noticed that www.localhost.com gives a 404 page not found. I checked this in Firefox, Chrome and Internet Explorer all does the same. I checked the domain name records and it shows it belongs to Tucows and I am pretty sure Google doesn't own it and I know we can use http redirect to change it to a www or non-www version as the site owner wishes.
Interesting answer posted by Ken Watford, Google employee: http://www.quora.com/Why-does-http-localhost-com-redirect-to-Google
He claims someone bought the domain when the web was still young and kept it ever since, but he does not say who.
It looks like others have had the results as you, check out the links below.
Try here:
http://answers.yahoo.com/question/index?qid=20111105050333AATP1r5
or here:
http://forums.phpfreaks.com/topic/146474-localhost-redirects-to-googlecom/
I think localhost.com should be owned by google as I tried pinging it and it showed the ip of google.com.I still don't know why the DNS records shows tucows as the owner.
I have been searching this from long and finally i found complete solution after going through different answers.
As far as #pradeep's answer is concern, he is right that localhost.com is purchased and points to particular IP so it is redirecting.
But we can override domain names in Windows platform for our local development PC via hosts file residing in C:\Windows\System32\drivers\etc as per #Faysal's answer.
Open hosts file as administrator and enter following line
127.0.0.1 localhost.com
But doing such also did not solve my problem. So i found final solution which will work in chrome browser.
In chrome you have to clear all dns cache via opening following url
chrome://net-internals/#dns
And here clear all cache and finally you will be redirect localhost.com to your local server's home page.
If you are using the Windows platform, then go to your %windir%\System32\drivers\etc and copy the host file to %userprofile%\Desktop. Open it with any text editor and remove the # sign from the front of 127.0.0.1 localhost. Save it and paste it back. Check if the problem is solved.
localhost.com is a website. It does not point to your local IP, instead it most likely has an A record pointing to Google's IP. It practically is Google, and I can prove it.
When the site worked if you connected using HTTPS then it would give a certificate error, the reason being that the certificate is signed to google.com but localhost.com is connecting.
I think the site has now been removed though.... I hope that solves it. It can cause some confusion since localhost points to 127.0.0.1.

Umbraco - Incorrect link to document when useDomainPrefixes = true

(To make this simpler - I've re-posted the first part of this question as a separate question, which has now been answered:)
Umbraco - Incorrect alternative link to document
Here's the full, original question:
On our website, we have the following structure:
sitename
-Global
-English
-UK
-English
for the Global > English page, the links to the page are showing as:
Link to document
/global/en/
Alternative Links
http://english
so the 'Link to document' is correct, but the alternative link isn't. On the UK > English page, I just get the correct 'Link to document'
On our development version, I've just turned on the useDomainPrefixes = true option in the umbracoSettings.config of of the site, and I've added a hostname for the top level 'sitename' node. Now I get the following as page links for the Global > English page:
Link to document
http://english/
Alternative Links
http://hostname/http://english/
http://english
I get the correct links for the UK > English page, showing the correct hostname in the URL like this:
Link to document
http://hostname/global/en/
I've tried re-publishing the entire root node (sitename), however I get an unusual timeout error. I've increased the timeout for the app pool, and for the session and the umbraco timeout in the web.config, however this is a different error probably related to the proxy server contacting the web server.
Is republishing the entire site the only fix? I've tried only publishing the sitename > Global node, which completes successfully, but doesn't fix the issue.
This is sometimes caused by setting the domains for the content nodes incorrectly. If you've right clicked and selected "Manage Hostnames" then you can get issues like this.
Remove all hostnames and see if everything works with UseDomainPrefixes=true.
I would reinstall from scratch and rebuild the site if the worst happens and you really cannot fix.

Symfony 1.4 Backend app for admin fail on Prod environment

I have a perfectly working admin backend on my dev environment but it fails miserably on the prod environment. Specifically a bunch of problems arise :
It is unable to read the symfony/web/sf/ directory hence not loading the required images though it states that a project has been successfully created. This however is not the case with the frontend leading me to believe that the problem is more sinister than what meets the eye.
Though it loads the admin pages, the css is not loaded, even though admin.css is present in the web/css directory.
I did an inspect element and the problem seems to be this, instead of routing to
/web/css or /sfDoctrinePlugin or /web/js
it prefixes the name of the app [controlcenter in my case] to everything, essentially rendering the HTML as:
href = "/controlcenter/web/css" or href = "/controlcenter/js" or href = "/controlcenter/js" . And this does not happen at all on my dev environment and things render the way they do.
Fixits anyone?
This was completely ridiculous of me to post this. I was simply trying to go to controlcenter/module which basically translates to backend/module for most people.
The index file in this case is controlcenter.php, and upon accessing that, I get the website to render the way it ought to. Sorry for the confusion people. Hopefully someone drops in by and sees the answer for themselves.
I should set up defaults in my routing.yml so that it automatically redirects without me having to type controlcenter.php
Thanks

Resources