I'm using HTML5's History API (through History.js) to dynamically rewrite URLs. I would like them to be the following format:
http://www.example.com/example/article/page
where both 'article' and 'page' are set by the History API.
However, this doesn't quite work as expected, as the pushState or replaceState provided by History.js only seem to work on the part of the URL which is after the last slash.
A quick example: if I'm at http://www.example.com/example/ and do pushState('Article-Title/1'), the url becomes http://www.example.com/example/Article-Title/1. Now I can change the page number with pushState('2'), but I have no way of changing the Article-Title part, which is what I'm after. window.location.href, which is used in Ben Lupton's example, can change the URL, but it also causes a "hard" redirect.
I suppose that this constraint is in place in order to prevent XSS; however, it bothers me greatly. Is there a reasonable way around it?
Found it: the URL I'm pushing has to start with a forward slash. That's all it takes.
You can also use relative URLS : ../../Another-Section/1
Related
I was sent a hyperlink to a Tableau Public link by a client. When I tried opening it, I got a 404 exception. I wrote back to the client but was told by the same that the link was working fine. I visited his profile page and was able to open the presentation there, but the URL that ended up working was slightly different than the one behind the original, non-functioning link.
Here's the anonymized URL behind the original link
https://public.tableau.com/profile/[client_name]%23!/vizhome/Project-AirportDelay/FlightPerformancesinUSA?publish=yes
And here's the URL via the profile page:
https://public.tableau.com/profile/[client_name]#!/vizhome/Project-AirportDelay/FlightPerformancesinUSA
The only differences I see are ?publish=yes and %23!. I tried appending the former, ?publish=yes, to the working URL, and it was still functional. So I suspect that it has to do with the other difference %23! vs. #!. Could the first work because he is opening it from his computer where he is likely logged onto Tableau Public? What's the difference between these syntax? Any ideas about why the original hyperlink might not be functional?
For obvious privacy reasons, I can't provide the whole URL.
It looks like the basic URL pattern for passing filters ?publish=yes
and
%23 is the URL encoded representation of #
The first # after the authority component starts the fragment component. If the # should be part of the path component or the query component, it has to be percent-encoded as %23.
As # is a reserved character, these URIs aren’t equivalent:
http://example.com/foo#bar
http://example.com/foo%23bar
There are countless ways how a URI reference could become erroneous. The culprit is often a software, like a word processor, where someone pastes the correct URI, and the software incorrectly percent-encodes it (maybe assuming that the user didn’t paste the real/correct URI).
Copy-pasting the URI from the browser address bar into a plain text document should always work correctly.
I have a basic link:
Free Pie Here
but when I click on it, I'm redirected to https://pieworld.com/apple
Everything after the hash mark, as well as the hash, are not included. This is only happening in IE10. I've tested without the target="_blank" as well, but the link still breaks at the hash.
Can't seem to find any documentation on this. The closest I've come to is this SO question, but it doesn't help.
Some background info that might help:
This is a .Net site
I'm redirecting from a http: to a https: site.
According to the RFC3986 https://www.rfc-editor.org/rfc/rfc3986 it is not OK to use this format. You should remove the trailing slash. If you have a trailing slash, it points to a directory within the server. Without it, you point to a document and with the hashmark you are allowed to point to a segment of the document. See example here.
A hash character is used for bookmarks in an URL. To use a hash character as part of the URL itself, you need to URL encode it using %23:
Free Pie Here
Why do you have a trailing slash after the hash?
Try https://pieworld.com/apple/#1
That would be more standard. I've never heard of anyone putting trailing slashes after hash links.
I Think, as the other folks suggested, that the website that you are trying to navigate to may interpret the /#1 as a folder/page inside the parent-page/document. Try removing the forward-slash before the #1 or look inside the html for the header's id/name tag so you can link it directly.
May also be a bug in IE10.
-Phantom
Any URL that contains a # character is a fragment URL. The portion of the URL to the left of the # identifies a resource that can be downloaded by a browser and the portion on the right, known as the fragment identifier, specifies a location within the resource.
http://www.httpwatch.com/features.htm#print
In HTML documents, the browser looks for an element with id attribute matching the fragment. For example, in the URL shown above the browser finds a matching tag in the Printing Support heading:
<h3 id="print">Printing Support</h3>
and scrolls the page to display that section.
I am not sure if the slash after the hash is supported. If you didn't mean to use it as a fragmented url, you should remove the hash or replace it.
The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments,
along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)
for more information check this thorough post.
Hash removed from URL when back button clicked IE9 , IE10 IE11
In IE10 browser, first time on clicking the HREF link, then it comes to the correct below url: http://www.example.com/yy/zz/ff/paul.html#20007_14
If back button is clicked from the IE10 browser and again clicked the HREF link , then it comes to the below url: http://www.example.com/yy/zz/ff/paul.html
Solution :
Please change your url with https
It works for mine
Here's a question i'm finding hard to answer with google and seem to be having problems with it on my site.
I am encoding/decoding user id's just to confuse matters and would like to link to parts of a page using anchors
Thing is.. My encryption is making a nice secure long string but I think there must be a limit to the length of the # anchor names because it works when its shorter, but not when its longer.
Does this seem to be true?
An example of the hash tag url is http://wgwegw.co.uk/wegweg/protected/view-game/wegweg/platform#x243j3f41684w2w2m594n416
For example i have a link:
Go to comment
When i click on it.. it opens up using HTACCESS file redirects. if i use javascript window.hash it returns the hash so i imagine the hash code is not affected by the htaccess redirects.
I land on the page: http://.co.uk//protected/view-game/*/platform#y213j3f41684w2w2m594n416
On that page in html is an anchor name: <a name="y213j3f41684w2w2m594n416"></a>
It does not skip to that part of the page?
OK here you go.
You won't believe this but I have suffixed an 'a' and now it works.
What on earth?
EDITED//
Could it be because i have an id and a name that equal the same? so i have a
<div id = "y213j3f41684w2w2m594n416">
and I have a
<a name = "y213j3f41684w2w2m594n416" />
So when i attach a to the end of the name.. it no longer is the same as the id and thus doesn't get confused?
EDITED//
If I try this on W3 example tweaks it still works so it can't be that?
Aghh now it's fixed i am desperate to know why it's working.
Is there some secret and mystical way to change the value of my HTTP-request's referer, or at the very least, keep it from showing? Also, using a MitM page from another domain would not solve my issue, as you are now just submitting that other page's value.
This is not browser specific, I would need to do this on the HTML level.
The problem I am facing is a silent-login page where it sends an HTTP-Redirect to the http-Referrer, unless it is the same domain, or empty.
You can not control this on an html level. Your only option is to modify the login code to not issue the redirect or to direct it to the desired page.
It's an old question, but I know how you can do this. The first way is not guaranteed across all browsers, but you can use rel=noreferrer. AFAIK GC is the only UA to currently support this but it is in the standard. FX may also, IDK.
The second way is far more reliable, and it involves a cool little hack someone shared with me on IRC:
Basically, construct an iframe from a base64-encoded data: URI. The framed document is to have a script that listens for a window.postMessage() and when it gets fed the command with a URL to visit, it executes window.top.location = msg.data.URI or however it is that one reads the message. Sorry I can't recall, I haven't slept for a few days.
Enjoy if you still care.. :)
So I'm working on a web app, and I want to filter search results.
A nice restful implementation might look like this:
1. mysite.com/clothes/men/hats+scarfs
But lets say we want to ajax up the filtering, like the cool kids, and we want to retain deep linking, we might use the anchor tag and parse that with Javascript to show the correct listings:
2. mysite.com/clothes#/men/hats+scarfs
However, if someone clicks the first link with JS enabled, and then changes filters, we might get:
3. mysite.com/clothes/men/hats+scarfs#/women/shoes
Urk.
Similarly, if someone does not have JS enabled, and clicks link 2 - JS will not parse the options and the correct listings will not be shown.
Are Ajax deep links and non-Ajax links incompatible? It would seem so, as servers cannot parse the # part of a url, since it is not sent to the server.
There's a monkeywrench being thrown into this issue by Google: A proposal for making Ajax crawlable. Google is including recommendations for url structure there that may give you ideas for your own application.
Here's the wrapup:
In summary, starting with a stateful
URL such as
http://example.com/dictionary.html#AJAX
, it could be available to both
crawlers and users as
http://example.com/dictionary.html#!AJAX
which could be crawled as
http://example.com/dictionary.html?_escaped_fragment_=AJAX
which in turn would be shown to users
and accessed as
http://example.com/dictionary.html#!AJAX
View Google's Presentation here (note: google docs presentation)
In general I think it's useful to simply turn off JavaScript and CSS entirely and browse your website and web application and see what ends up getting exposed. Once you get a sense of what's visible, you will understand what most search engines see and that in turn will show you what is and is not getting spidered.
If you go to mysite.com/clothes/men/hats+scarfs with JavaScript enabled then your JavaScript should automatically rewrite that to mysite.com/clothes#men/hats+scarfs - when you click on a filter, they should be controlled by JavaScript meaning you'll only change the hashtag rather than the entire URL (as you're going to have return false anyway).
The problem you have is for non-JS users going to your JS enabled deeplinks as the server can't determine that stuff. Unfortunately, the only thing you can do is take them to mysite.com/clothes and make them start their journey again (as far as I'm aware). You'll need to try and ensure that when people link to the site, they use the hardcoded deeplink rather than the hashed deeplink
I don't recommend ever using the query string as you are sending data back to the server without direct relevance to the prior specified destination. That is a corruptible security hole as malicious code can be manually added to the query string to cause a XSS or buffer overflow attack at your webserver.
I believe REST was intended to work with absolute URIs without a query string, because then your specifying only a location of a resource and it is that location that is descriptive and semantically relevant in addition to the possibility of the resource being so equally relevant. Even if there is no resource at the specified path you have still instantiated a potentially unique and descriptive location that can be processed accordingly.
Users entering the site via deep links
Nonsensical links (like /clothes/men/hats#women/shoes) can be avoided if you construct your Ajax initialisation code in such a way that users who enter the site on filtered pages (e.g. /clothes/women/shoes) are taken to the /clothes page before any Ajax filtering happens. For example, you might do something like this (using jQuery):
$("a.filter")
.each(function() {
var href = $(this).attr("href").replace("/clothes/", "/clothes#");
$(this).attr("href", href);
})
.click(function() {
update_filter($(this).attr("href").split("#")[1]);
});
Users without JavaScript
As you said in the question, there's no way for the server to know about the URL fragment so filtering would not be applied for users without JavaScript enabled if they were given a link to /clothes#filter.
However, even without filtering, these links could be made more meaningful for non-JS users by using the filter strings as IDs in your /clothes page. To prevent this messing with the Ajax experience the IDs would need to be changed (or the elements removed) with JavaScript before the Ajax links were initialised.
How practical this is depends on how many categories you have and what your /clothes page contains.