Problem - Open new
page in the same browser window, while hiding browser toolbar
Solution - I would say it is half-possible to do this. To understand better, let us split it into two different problems.
- Problem 1 - To open the new page in the same browser window.
Solution - One of the solutions is to set the second parameter in window.open method to '_self'. This parameter denotes the target window, and by default, it should be '_blank'. Here is a sample call to window.open method that will open a new page in the same browser window.
window.open('NewPage.html','_self');
- Problem 2 - To hide the browser toolbar (while staying on the same page)
I would say, it is better to leave the browser behaviour in this case to browser, rather than confuse it much.
If the requirement is not to stay ont he same page, here is how to do it on a fresh page.
window.open('NewPage.html', '', 'toolbar=0,menubar=1,resizable=1');
PS: To understand the window.open() method much better, refer this.
Please comment if this served your purpose by any chance. Happy coding :)
- Clear browser cache from javascript
- How to loop through
gridview.datakeys
- Anonymous methods in C#
- Stepping through test methods in Visual Studio Unit test f framework
- Hosting an ASP.NET MVC application to work on IIS 5 (6 or 7) and getting around the HTTP 404's
Problem – HTTP 304 (‘Not Modified’) status response every time a page(rendered html) has reference to ScriptResource.axd or WebResource.axd.
To replicate the behaviour, do a browser refresh on any web page that has ScriptManager. Use Fiddler or similar software to view the 304-response.
Context – This reference is added by Ajax tool kit. ScriptManager adds .axd references in the rendered html to get the javascript support for AJAX.
User Impact –The user would neither getting any server-side error, nor any AJAX errors. But, some server traffic-monitoring software like the Tealeaf show these HTTP 304's as errors in their statistics.
Probable Causes –
When the actual page gets rendered with #pragma set to ‘no-cache’ and such page is refreshed, the broswer tries to load again from server.
When we verify the request/response headers –
Request headers for both page and .axd files would have cache-control set to ‘no-cache’
While the response headers differ as,
page would still have ‘no-cache’, the .axd file response (with 304 status) would have ‘public’, which means the file can be cached.
Hence, the browser would try to verify the .axd file version with cached version and hence, the HTTP 304 – ‘Not Modified’ status.
304 basically says, the resource is not modified from its last cached copy.
Though this is more a feature than an error, you can try to work it around not to let 304 status response. For instance,
Force-get the .axd files as if they are not cached
To do this,
- Extend the ScriptResourceHandler (that implements IHttpHandler) and Override the ProcessRequest method.
- Set the Expires property to a past date (which would effectively set the cache-control to ‘no-cache’).
- Explicitly setting cache-control to ‘no-cache’ is also necessary to handle the behaviour on all browsers.
Doing this can have a slight impact on performance, but it should be consistent.
MY CONCLUSION ON THIS -
From my knowledge and analysis on HTTP 304’s, this is a feature of HTTP rather than a bug. That’s the correct message the server is sending in accordance with HTTP protocol, and it is not an error/warning message, but just a status message.
304 basically says, the resource is not modified from its last cached copy and the browser can load it from its local cache. This way, it avoids the resource being unnecessarily transferred between client and server, thereby, enhancing the performance of the application.
Some IIS traffic-monitoring software, like the Tea leaf can misread it as an error, while it is actually a feature. They will have to be configured accordingly.
PS: Please comment if this served your purpose by any chance. Happy coding :)
