I am observing a website with Google Chrome and Fiddler version 4.4.
The page is using AJAX to update its data. I want to block a specific URL to test what will happen if it doesn't work.
What is the easiest way to block the URL?
What would you like to have happen?
Go to the AutoResponder tab. Tick Enable Automatic Responses and Unmatched requests pass through. Click the Add button. In the top box, enter http://example.com/yourURLisHere. In the box below it, select either 404_Plain.dat or choose *drop or *reset. The first returns a 404. The second just drops the connection if it sees the target URL. The third sends a TCP/IP RST packet if it sees the target URL.
Related
So I am concerned with
webdriver.navigate().back();
in particular. AFter reading How does the Back button in a web browser work?
it made me think of how can I make sure back button behaves as expected?
Here's different ways of having "back" navigation. How would you go about detecting which approach to use? Listen to whether POST or GET is being made? Listen for AJAX requests and plan the appropriate plan?
a) navigate back() (essentially hitting back button in firefox)
b) make GET request to the previous page url
c) click on "return to results" on current page
with a) back() sometimes do not work correctly for AJAX sites with no breadcrumbs. or for POST search results for example where pressing back will prompt alert message.
with b) my concern is that the url may not match up,
ex) dynamic urls with unique hash sessionid parameters
http://www.aa.com/results.php?sessionid=29756293changeseverytime
So how do I create a contingency to make sure the back navigation works correctly as expected for a variety of web apps and sites (there are lot of variability in terms of how the back button will behave).
Why don't you store the location of the page that you want to verify, hit a link, use the goBack and then verify location of check the variables (the one you stored and the location of the verify page)?
By the way, if your site uses AJAX I suggest you use the pause function that waits for the AJAX lib. To fully load, or set the speed of your site (maybe combine them together in rare cases).
I was wondering if there is a simple way of "catching" the URLs processed by Firefox (or any browser for that matter) once I click them (e.g. click "Send friend request" on Facebook).
The "Friend Request" on Facebook is just an example, so please don't give me a specific link for that. I want to know if I can retrieve the URL that is being processed, e.g. http:// facebook.com / ajax / request.php?type=friend&id=1234567890
in a simple way - dissecting the code from source is not an option.
One option would be to write a GreaseMonkey script that attaches an event handler to each link on the page.
Once the link is clicked, you intercept it's it's href attribute and then it let it continue processing it's standard behavior.
If you click on a result in Google Instant, the referer sent by your browser to the destination website contains a bunch of parameters, including the all important q=[autocompleted query]
But you're coming from a page whose URL is simply http://www.google.com/ with a bunch of stuff after the # character, i.e. as an on-page anchor.
So the browser appears to be sending a URL as the referer which is different from the URL of the page that you were viewing when you clicked.
There doesn't seem to be an additional redirection, so how on earth do they do that?
Most of the time, a Google search result actually sends you to a Google redirect page rather than directly to the target page. They use JavaScript to switch the target of the link onmousedown as you click on it.
You can see this effect by click-and-holding on the search result link and watching your status bar.
This isn't specific to Google Instant, they've been doing it for quite a long time on their standard results pages.
The page anchor part of the URL can be manipulated client-side without a new request to the server. Even when talking about static anchor links (e.g. Section Foo), clicking on them does not cause a new request to be sent to the server; it is processed completely within the browser.
The javascript being used by Google to make Google Instant work is simply altering the anchor programatically before making a request to the server.
What Google are you using?
My URL after searching is this:
http://www.google.es/#sclient=psy&hl=es&q=something+to+search&aq=f&aqi=g4g-o1&aql=&oq=&gs_rfai=&pbx=1&fp=b0....
It does include the q= part
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1
I'm writing an AJAX app, but as the user moves through the app, I'd like the URL in the address bar to update despite the lack of page reloads. Basically, I'd like for them to be able to bookmark at any point and thereby return to the current state.
How are people handling maintaining RESTfulness in AJAX apps?
The way to do this is to manipulate location.hash when AJAX updates result in a state change that you'd like to have a discrete URL. For example, if your page's url is:
http://example.com/
If a client side function executed this code:
// AJAX code to display the "foo" state goes here.
location.hash = 'foo';
Then, the URL displayed in the browser would be updated to:
http://example.com/#foo
This allows users to bookmark the "foo" state of the page, and use the browser history to navigate between states.
With this mechanism in place, you'll then need to parse out the hash portion of the URL on the client side using JavaScript to create and display the appropriate initial state, as fragment identifiers (the part after the #) are not sent to the server.
Ben Alman's hashchange plugin makes the latter a breeze if you're using jQuery.
Look at sites like book.cakephp.org. This site changes the URL without using the hash and use AJAX. I'm not sure how it does it exactly but I've been trying to figure it out. If anyone knows, let me know.
Also github.com when looking at a navigating within a certain project.
It is unlikely the writer wants to reload or redirect his visitor when using Ajax.
But why not use HTML5's pushState/replaceState?
You'll be able to modify the addressbar as much as you like. Get natural looking urls, with AJAX.
Check out the code on my latest project:
http://iesus.se/
This is similar to what Kevin said. You can have your client state as some javascript object, and when you want to save the state, you serialize the object (using JSON and base64 encoding). You can then set the fragment of the href to this string.
var encodedState = base64(json(state));
var newLocation = oldLocationWithoutFragment + "#" + encodedState;
document.location = newLocation; // adds new entry in browser history
document.location.replace(newLocation); // replaces current entry in browser history
The first way will treat the new state as a new location (so the back button will take them to the previous location). The latter does not.
SWFAddress works in Flash & Javascript projects and lets you create bookmarkable URLs (using the hash method mentioned above) as well as giving you back-button support.
http://www.asual.com/swfaddress/
The window.location.hash method is the preferred way of doing things. For an explanation of how to do it,
Ajax Patterns - Unique URLs.
YUI has an implementation of this pattern as a module, which includes IE specific work arounds for getting the back button working along with re-writing the address using the hash. YUI Browser History Manager.
Other frameworks have similar implementations as well. The important point is if you want the history to work along with the re-writing the address, the different browsers need different ways of handling it. (This is detailed in the first link article.)
IE needs an iframe based hack, where Firefox will produce double history using the same method.
If OP or others are still looking for a way to do modify browser history to enable state, using pushState and replaceState, as suggested by IESUS, is the 'right' way to do it now. It's main advantage over location.hash seems to be that it creates actual URLs, not just hashes. If browser history using hashes is saved, and then revisited with JavaScript disabled, the app won't work, since the hashes aren't sent to the server. However, if pushState has been used, the entire route will be sent to the server, which you can then build to respond appropriately to the routes. I saw an example where the same mustache templates were used on both the server and the client side. If the client had JavaScript enabled, he would get snappy responses by avoiding the roundtrip to the server, but the app would work perfectly fine without the JavaScript. Thus, the app can gracefully degrade in the absence of JavaScript.
Also, I believe there is some framework out there, with a name like history.js. For browsers that support HTML5, it uses pushState, but if the browser doesn't support that, it automatically falls back to using hashes.
Check if user is 'in' the page, when you click on the URL bar, JavaScript says you are out of page.
If you change the URL bar and press 'ENTER' with the symbol '#' within it then you go into the page again, without click on the page manually with mouse cursor, then a keyboard event command (document.onkeypress) from JavaScript will be able to check if it's enter and active the JavaScript for redirection.
You can check if user is IN the page with window.onfocus and check if he's out with window.onblur.
Yeah, it's possible.
;)