Is there any way to get the requested path (the path displayed in the browser address bar) vs the redirected path for a subdomain (hidden from the user) using javascript
I am using a shared javascript file (shared across multiple pages and sites) that determines the controller and action (MVC) using window.location.pathname but... I have just caught myself out as my deployment runs under sub-domains which I wasn't representing in the Visual Studio dev environment. the sub-domains on my host redirect to a /subdomain folder as is usually the case but now my window.location.pathname pulls back /subdomain/controller/action whereas the URL in the address bar is /controller/action
Obviously I can tweak my javascript to handle this situation - however there may not always be a subdomain (at least in my dev environment if nothing else - and I am dead against solutions like having "isdev" style flags throughout my code) so I have to have a fail-over for those instances which means things start to get a little more complicated thus being more prone to error.
Any suggestions greatly appreciated.
Btw I do not want to use values from .Net e.g. HttpContext... as my js is in an external file and I do not want to create a dependency on data in a view for it to work as this means every time I consume the js on a new page I have to remember to include the additional logic in the view for it to work, plus if I change my js file it may result in me having to refactor a bunch of views as well.
Cheers
Rob
window.location.href should return the entire URL that the site is currently at, including the subdomain e.g. http://subdomain.site.com/path/to/page.aspx
Alternatively you can use window.location.host and it will return everything except for the path, or window.location.pathname to return just the relative path to the file.
See the MDC article on window.location for more information: https://developer.mozilla.org/en/DOM/window.location
Related
So the obvious answer is that its necessary because it serves routed paths from the server, so that we don't get 404s.
However solutions like angular-cli-ghpages solves this by adding a script to the app that parses parameters returned in a 404 that will then reroute the app to the correct state.
So just curious are there any drawbacks to this and why would this not be used in general instead of solutions like Angular Universal or Rendertron?
For example this is what spa-github-pages says:
A quick SEO note - while it's never good to have a 404 response, it appears based on Search Engine Land's testing that Google's crawler will treat the JavaScript window.location redirect in the 404.html file the same as a 301 redirect for its indexing. From my testing I can confirm that Google will index all pages without issue, the only caveat is that the redirect query is what Google indexes as the url. For example, the url example.tld/about will get indexed as example.tld/?p=/about. When the user clicks on the search result, the url will change back to example.tld/about once the site loads.
Because of two main things:
First page load speed;
SEO
Robots do not run javascript, so they parse what the get from server and than the Universal comes around.
Even using --aot builded app served by ghpages with a 404 page that is a clone from the index, the client/robot still needs to get the first files, parse them and finally mount the final view. Gh-pages do not serve the final html state.
Website works for
jerrygoyal.github.io/Flash-Clipboard
but not for (404 error):
jerrygoyal.github.io/flash-clipboard
jerrygoyal.github.io/FLASH-clipboard
jerrygoyal.github.io/flaSH-CLIPboard
and so on
You get the idea!
How can I make the url case-insensitive?
I've never worked on Jekyll and not sure if my project pages are using jekyll or not. I only created an index.html page and put inside the docs folder of the repository.
I'm using a custom domain (www.jerryfactory.com) to map jerrygoyal.github.io
Here's the URL to my Github Organisation site : https://github.com/JerryGoyal/jerrygoyal.github.io
And URL for my Github project site:
https://github.com/JerryGoyal/Flash-Clipboard/tree/master/docs
I'm thinking of moving my project site content to my Github Organisation site if it's possible. So if the URL case insensitivity works for only Organisation site it's fine.
Ref: Org and Project Site in Github
How can I make the url case-insensitive?
The short answer is: You cannot / It's not possible in GitHub Pages as of this writing.
The long answer is: Having URLs case-sensitive is a web standard and most webservers will respect that. This has nothing to do with Jekyll or any other similar tool. It's a responsibility of the webserver that is serving the HTML pages that were generated by Jekyll, and in the case of GitHub Pages, they use a *nix-based webserver that is compliant with case-sensitive URLs when locating resources.
A common way to solve this problem is to make sure your pages in Jekyll are always lower-case, which in turn will generate lower-cased URLs.
This shouldn't really be a problem, unless your users are typing the URLs by themselves... And in that case, if you want to be proactive, you can use the jekyll-redirect-from plugin and create redirect entries of the most common ways you believe users will try to access each page.
For example, having the main URL as
augustoproiete.github.io/flash-clipboard
and redirect the ones below to the main one above via jekyll-redirect-from
augustoproiete.github.io/Flash-Clipboard
augustoproiete.github.io/FLASH-CLIPBOARD
There is no direct way to make github page URLs case-sensitive. But, you can use following hack:-
Redirect from 404 page with mixed-case or upper-case URL to lower case URL. Steps to achieve this:-
Just go to your root repo (your_username.github.io).
If not already exist then create a 404.html file and add the following script in it.
<script>
window.onload = () => {
currentURL = window.location.href;
lowerCaseURL = currentURL.toLowerCase();
if (currentURL != lowerCaseURL) {
location.replace(lowerCaseURL);
}
};
</script>
Note:- Make sure your pages/repo name are always in lower-case.
Logic explained with example:-
If your URL is:-
anmol53.github.io/bmi-tracker
and someone tried following URL:-
anmol53.github.io/BMI-Tracker
By default he/she will get 404. Now we will redirect him/her to anmol53.github.io/bmi-tracker by changing case of current URL by using above script.
You can’t make it case-sensitive. Sorry. Case-sensitive URLs are a web-standard. It would be cool if URLs were case-insensitive, but that isn’t true.
Sorry for the badly worded question.
PHP with apache uses index.php/index.html for directory urls like:
localhost = localhost/index.php or localhost/place = localhost/place/index.php
If I start with:
localhost/place
and I use a javascript history.pushstate to update a url with a long adress like:
localhost/place/subplace
then if I enter that url in the browser I'll go to localhost/place/subplace/index.php when I really wanted localhost/place/index.php to allow that url to be the only point of entry.
I'm using simple javascript(window.location.pathname or anchorNode.pathname) to retrieve the url path for use with ajax. This is used by a simple router similar to backbone.js to update the page. The javascript routing works and back/forward in the browser works. If only I could get it to work with the single point of entry for urls entered in the address bar.
To sum up:
I want a single point of entry for my php app to get all subdirectories.
At the single point of entry I want to run the javascript to acquire the path and use it to route the page with ajax.
I'm using history.pushState to update the url, but that messes with the single point of entry for the app when the directories are longer than the main directory. Basically I get a 404 page.
Right now I'm not too concerned with making it backwards compatible with browsers that don't have history.pushState. I just want this one thing to work.
As an addendum I would prefer working with regular paths in javascript and not the query string. Whether the page is loaded with the address bar or the history.pushState is used that's what I would prefer. I don't know if this can be handled with apache rewrite or what.
Similar questions:
How to cope with refreshing page with JS History API pushState
Ok. I'm making things too hard.
To get the routing to work on page load I need to do two things.
In the .htaccess file I can use apache rewrite to make all urls route to index.php?path=first/second/third.
When the page loads just concatenate the the new path in the query string to the javascript string that handles the route.
The javascript is still being used, and there's no duplication of functionality. Everything is good.
This also kind of answers this: How to cope with refreshing page with JS History API pushState
I always wrote URLs used by AJAX calls in this way: "/Home/Save" with the forward slash in the beginning. Now this last project is being deployed to a virtual directory on a server. Thus, these URLs aren't working anymore, because instead of "example.com/VirtualDir/Home/Save", they would point to "example.com/Home/Save" which is wrong. I quickly fixed the problem by removing the first forward slash "/" in all occurrences of URLs in my JavaScript. All pages work great, except for one! When AJAX call happens on the problematic page, the specified URL gets appended to the page URL. I've spent a few hours yesterday and the whole morning today, and I cannot figure it out. There is absolutely nothing different about this page comparing to others. Has anyone had this problem before? Should I post my code?
EDIT: After banging my head on the keyboard for another few hours, I ended up implementing the following. I got an action in a common Controller that returns the result of Request.Url.GetLeftPart(UriPartial.Authority), which is your http://www.mysite.com. I render it inside my Layout page into a global JavaScript variable, _AppPath. Then, every AJAX call gets its URL like this: _AppPath + '/Controller/Action'. This works everywhere and I still don't know what the hack is the problem with that page. Cheers!
Can you change the Ajax requests so that they instead point to "/VirtualDir/Home/Save"?
If it helps your code, you could have a path variable, so that you can easily update the virtual directory path (or remove it) when you deploy it somewhere else. Or your code could read its location via the window.location.href property and work out things out from there.
It's not so useful to have paths relative to the current document (i.e. without the / slash prefix) because, as you are observing, some of the pages will then fail their requests, when those pages are at a different point in the site hierarchy. An absolute URL would be the one to go for (i.e. with a / slash prefix).
[UPDATED, based on comments below]
#Dimskiy, it doesn't so much matter that the server-side framework is .NET MVC, or that there are no actual folders for those URLs on the server. The browser will just respond according to the URL structure it sees.
So the things to look for are the URLs in the browser address bar for the different pages, and the URLs of the Ajax requests being made to the server (e.g. look for these in Firebug's "Net" panel). And compare the URLs, looking at the number of folders suggested by each URL.
It doesn't matter if there isn't an actual folder on the server. The browser can't tell, it can only look at the URL structure. If the JavaScript is making a call from a page called "foo" to an Ajax resources at "Home/Save", then the request will be routed to "foo/Home/Save". And if the request is made from page "foo/bar" then it will be routed to "foo/bar/Home/Save". That's a relative path - it's relative to the containing HTML document.
A request to an "absolute" path, say, "/Home/Save" (note the / slash prefix) will always go to the root of the domain, e.g. example.com/Home/Save. But since you need your request to go to the "VirtualDir" virtual directory, then your URL will become "/VirtualDir/Home/Save".
I currently have the following JavaScript function that will take current URL and concatenate it to another site URL to route it to the appropriate feedback group:
function sendFeedback() {
url = window.location.href;
newwin = window.open('http://www.anothersite.com/home/feedback/?s=' + url, 'Feedback');
}
Not sure if this is the proper terminology, but I want to mask the URL in the window.open statement to use the URL from the current window.
How would I be able to mask the window.open URL with the original in JavaScript?
Things you could do:
1- Mask the external site in a html frame inside a document from your site.
(for example www.mysite.com/shortUrl/)
2-Send a Location HTTP header (real url will eventually be displayed)
Keep in mind that browsers do their best to show the real address due to phishing concerns.
I wouldn't use javascript if I wanted to mask url even thought it would work with javascript. You wouldn't get much benefits in that scenario.
The reason is simple:
javascript/jQuery = functions belongs to client-side (browswer/your PC/DOM)
links, url, http, and headers = functions belongs to Apache.
Apache is always top level above client-side. Whenever link is fired to SampeLink.html, Apache wakes up and reads the file, but links/urls are already owned before javascript could claim them. So, it is kinda of pointless if you tried to manipulate links in your javascript scripts, even though it works but weak.
I'd point you to this awesome approach: .htaccess and you will be surprised how powerful it is. If .htaccess is presented in the parent folder of SampleLink.html, Apache denies the DOM engine (your browser) from reading files until Apache have finished reading .htaccess.
With your scenario, .htaccess can do some work for you by rewriting links and send "decoy" links to the DOM engine, meanwhile keeping the orginial links/urls behind the curtain; and visitors would reach to 404page if they tried to break the app or whatever you are concerned about.
This is a bit complicated, but it never ceased to fail me. I use this as my "bible" http://corz.org/serv/tricks/htaccess2.php.