I want to make some changes to my web site that requires some URL rewriting to keep my old URLs. I can't use proper URL rewriting because I have very limited control from my hosting provider.
As I'm using ASP.NET and all of my pages have the .aspx extension, one idea I had is to put something in the global.asax under the Application_BeginRequest event. This could check if the URL of the page requested is one of the old ones and use Server.Transfer to open the correct page.
My question is, would this transfer this invisible to Google? I don't want my ranking within Google to be affected.
Server.Transfer happens entirely on the server side, so any client (including Google) will not be aware of it.
The client (browser or bot) won't have any idea whatsoever that the Server.Transfer occurred. It will see only that it requested a given URL and got the content you return. There's no response to the client saying that you've moved things (that would be Response.Redirect).
In your case, it sounds like that would mean you'll have two URLs returning the same content — two identical pages — which could affect how search indexes treat the content (and certainly means you'll end up with people linking to both URLs, which could impact the rank of each URL).
You can address that by specifying what the canonical URL for the content is. More in this Google blog post, but basically, if you have both http://example.com/foo.aspx and http://example.com/bar.aspx returning the same content, and you want the canonical (official) URL to be http://example.com/bar.aspx, tell the indexers that:
<link rel="canonical" href="http://example.com/bar.aspx" />
Google is only bothered about the Page Content, It does'nt bother how the content is constructed on the web server. Since Server.Transfer is completely internal to a web request, i think you should be okay with your website rankings.
Related
I have ssl in my e-commerce web site. At first, browser always asking "do you want to show this web site's content" in all page and when I redirect to mycart page browser shows the same alert like that "This webpage contains content that will not be delivered using a secure HTTPS connection, which could comprise the safety of the entire webpage....Yes...No....". After I clicked to yes, all my sessions get null. Do you have any suggestions for me?
KR,
Çağın
The problem is your secure page is accessing information (scripts, images, etc.) from pages that are not secure. For example if you reference a javascript file (say jQuery) from a nonsecure site (say Google) then certain browsers (like IE) will display this message. You need to search through your references and find these. In other words searching src="http or something along those lines will pull up the nonsecure references.
Depending on what you are referencing you can move those items to your site so that they are now "secure". Also, in some cases changing your reference from src="http to src="https can resolve the problem.
Once you resolve this alert you can check again to see if you are having sessions issues as you could have some other issues to address.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.
I know that Server.Transfer() should be used to redirect to another ".aspx" page on the same server. But what is the reason behind why should I not use this method to redirect to aspx page on another server or html page?
Your answers are really appriciated.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
From : Server.Transfer vs. Response.Redirect
So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.
Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
Server.Transfer has an optional parameter to pass the form data to the new page.
Since the release version, this no longer works, because the Viewstate now has more security by default (The EnableViewStateMac defaults to true), so the new page isn’t able to access the form data. You can still access the values of the original page in the new page, by requesting the original handler:
The Server.Transfer() only works within one webapplication.
With Transfer, the "handling" of the request is internally (to the webserver/application) passed on to another page, so the Request object stays the same. This means that the processing needs to stay within the webapplication.
If you want to let processing continue on another webapplication, you will need a fresh Request there. This means that you will need have the browser issue an other request, so you need a Response.Redirect.
Server.Transfer can only happen for single HttpContext. Each virtual directory or app has its own HttpContext object and they know not that they co-exists! so you cannot do that.
Take a look at Server.Transfer Vs. Response.Redirect
Sessions is not shared among servers so that would be a big problem.
I do not believe this is possible, but I figure there are people out there way smarter than me, so why not check ..
I would like to have an HTTP image that is viewable from within a page when used w/in an img tag, but NOT visible if the img src link is called directly. Does that make sense? Viewable in page, but not if called directly.
Quick edit .. acceptable alternative is to embed image in page in such a way as url is not human readable / able to be extracted and typed into browser.
Update 2 ... .NET IIS7 env.
Note that "security" products such as Norton Internet Security and Norton Personal Firewall prevent the HTTP Referer: (TBL's spelling mistake, not mine) header being sent by default. As these products are widely used, referrer blocking will break things for an awful lot of people.
FWIW, if I was keen to get your image other than by viewing your page (although I can't imagine why I should be) I would just grab the bits as they came over the network when I viewed your page, using something like Charles or Fiddler. It's completely impossible to make content available over the web but prevent people from making a copy.
I believe that you can achieve something like this by relying on the referrer header supplied by the browser - when the referrer is a web page on your own site, you serve up the image, but not otherwise.
It's not 100% reliable (as passing the referrer isn't mandatory in the HTTP spec) but works well enough for some sites.
This is achieved through configuration of your webserver; you therefore might have more luck asking this on ServerFault.
Yes, there are lots of articles on how to setup mod_rewrite rules in apache to try and prevent direct access to files.
http://www.cyberciti.biz/faq/apache-mod_rewrite-hot-linking-images-leeching-howto/
It depends on how it gets built. You can always make sure your referrer is the page that you expect it to be hosted from and lock down requests there.
If you have some notion of authentication, you could bury the image under some type of php/ruby script or asp.net http handler that requests the image from the server or database (in a place that is not publicly viewable but is reachable by your server-side code) and that handler could check for your authentication status before returning it.
Frankly, I re-worked my solution so I didn't really have to worry bout it ... know that's a cop out, as it doesn't REALLY answer the question, but there it is. My concern that users would be able to defraud the "game" I was creating if they could figure out the sequence that was being used to name the images. Quick and dirty solution .... don't make image file names sequential / predictable.
I'm replacing an old web application with a new one, with different structure.
I can not change the virtual directory path for the new app, as I have users which have bookmarked different links to the old app.
Lets say I have a user, who has this bookmark:
http://server/webapp/oldpage.aspx?data=somedata
My new app is going to reside in the same virtual directory, replacing the old one, but it has no longer oldpage.aspx, instead it has different layout, but it still needs the parameter from the old url.
So, I have set to redirect 404 errors to redirectfrombookmark.aspx, where I decide how to process the request.
The problem is, that the only parameter I receive is "aspxerrorpath=/webapp/oldpage.aspx", but not the "data" parameter, and I need it to correctly process the request.
Any idea how I can get the full "original" url in the 404 handler?
EDIT: reading the answers, looks like I did not make the question clear enough:
The users have bookmarked many different pages (oldpage1, oldpage2, etc.) and I should handle them equally.
The parameters for each old page are almost the same, and I need a specific ones only.
I want to re-use the "old" virtual directory name for the "new" application.
The search bots, etc., are not a concern, this is internal application with dynamic content, which expires very often.
The question is - can I do this w/o creating a bunch of empty pages in my "new" application with the old names, and Request.Redirect in their OnLoad. I.e. can this be done using the 404 mechanism, or some event handling in Global.asax, etc.
For the purposes of SEO, you should never redirect on a 404 error. A 404 should be a dead-end, with some helpful information of how to locate the page you're looking for, such a site map.
You should be using a 301, moved permanently. This allows the search bots to update their index without losing the page rank assigned to the original page,
See: http://www.webconfs.com/how-to-redirect-a-webpage.php on how to code this type of response.
You could look into the UrlRewritingNet component.
You should also look into using some of the events in your Global.ascx(?extention) file to check for errors and redirect intelligently. The OnError event is what you want to work with. You will have the variables from the request at that point in time (under the HttpContext object) and you can have your code work there instead of a 404. If you go this route, be sure you redirect the 404 correctly for anything other than oldpage.aspx.
I am sorry I don't have any explicit examples or information right now, hopefully this will point you in the right direction.
POST and GET parameters are only available per request. If you already know the name of the old page (OldPage.aspx) why not just add there a custom redirect in it?