In the website we developed,
www.website.com/design?somequerystring
works fine but
www.website.com?somequerystring
causes 404 error. We have already checked and are sure that there is no problem with the codes and it must be something about IIS. Also there is no url re-write. What do you think the error could be? What should we check?
Related
I have a personal website at http://deanattali.com/
A few days ago I shared my site on my feed and everything was ok. Now whenever I try to share any other page, Facebook does not parse it and simply ignores it.
I tried the Open Graph Object Debugger tool and it always returns "Error Linting URL An internal error occurred while linting the URL."
For example, try any of the following URLs:
http://deanattali.com/aboutme
http://deanattali.com/2015/03/12/beautiful-jekyll-how-to-build-a-site-in-minutes/
I even tried taking an HTML page from a similar site and copying the exact same HTML onto my site, and the parser worked for the other site but not for mine
Page on other site that works: http://keshinid.github.io/2015-02-26-flake-it-till-you-make-it/
Page on my site with identical HTML that doesn't work: http://deanattali.com/test
This is very frustrating, the error is very vague.
When I try to click on the link to see what the scraper sees on FB's debugger tool (https://developers.facebook.com/tools/debug/og/object/) it says "Document returned no data"
Another point worth mentioning is that this is a GitHub Pages website, with URL daattali.github.io and I have a CNAME to deanattali.com (I'm not sure if that matters at all)
I'm very lost, thank you
For anyone who will ever run into this problem in the future: a bandage fix seems to be to append ?fbrefresh=anystring to the URL. It looks like when there is a fbrefresh param in the query string, it works fine (doesn't matter what the value of the parameter is). Not sure what the underlying cause is, whether this is a bug or not.
I have a page where i want the page to return a 404 response but remain on that page. Please don't ask why - the client wants it that way even after i discussed it with him.
I've got a .net page written in C# running under iis 8 and the app pool is configured to run under 4.0 integrated mode
When i set the statuscode to 404 in the page, it gets sent to the custom 404 error page that's set up for this site. After googling i found another post on SO mention using Response.TrySkipIisCustomErrors. From what i read it sounds like it's exactly what i need. I tried setting it to true and it had no effect in the behavior of the page - still get sent to the customer 404 error page that's setup in iis.
Anyone have any ideas why this isn't working?
Well - this is a first. First time I managed to find the answer before hitting the submit button :)
Found this IIS.net article:
http://www.iis.net/configreference/system.webserver/httperrors
which then lead me to find this:
http://msdn.microsoft.com/en-us/library/ms690576(v=vs.90).aspx
Scroll down to the part that explains what the options for existingResponse mean. I had mine set to Replace which means it ignores TrySkipIisCustomErrors completely. Changed it to Auto and it's working.
I've seen a number of similar questions to this on StackOverflow and on other sites, but nothing that seems to resolve the issue I'm experiencing.
I'm trying to configure a site to return a 500 status code and a custom error page (static HTML file) for ASP.NET errors that would normally return a 500 where customErrors is set to "Off", and 404 status code for pages that our system reports as not being found (the 404 page is not a static page set via IIS, it's generated by our CMS system).
I'm part way there, but I've hit a bit of a brick wall.
At present, I'm able to return the correct 404 status code where our system returns a page with a 404 status code, but I'm now unable to return a 500 status code for ASP.NET server errors. I managed this by setting Response.TrySkipIisCustomErrors = true. My 500 errors, however, are proving more complicated. If I remove the customErrors config section from my web.config, I get the 500 error but it's the ugly ASP.NET YSOD. I can't seem to get this to point to a custom page using IIS at all, no matter what settings I use for the httpErrors config section and no matter what I set via the IIS GUI. If I add the customErrors section back, I get the custom error page as I'd expect, but I get a 200 or 302 error (depending on the value of redirectMode attribute).
Anyone got any ideas?
In terms of httpErrors config section I've tried the following so far:
Setting errorMode to "Custom" and specifying my static content for errors with a statusCode of "500" and a subStatusCode of "-1" (removing existing 500 error first)
Setting errorMode to "Detailed" and specifying my static content for errors with a statusCode of "500" and a subStatusCode of "-1" (removing existing 500 error first)
Setting existingResponse="PassThrough" for both configuration options above.
It seems you may be going above and beyond what you need to do, that is if I understand you correctly. Here is a good link
It seems like you what you need is to handle the global.asax Application_Error Event. This way you can handle it anyway you like and you dont get that ugly asp.net error screen. Any web app I create I put some code in there to handle errors so the user wont see any unformatted "blow ups"
Currently we are using a Kentico CMS for out web site and we used to have a page called pages/page1.aspx. We removed that page but every day the google, bing and yahoo sarch robot tries to read that page. Because the page doesn't exist the CMS throws the following error (in the log)
Event URL: /pages/page1.aspx
URL referrer:
User agent: Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Message: The file '/pages/page1.aspx' does not exist.
Stack Trace:
at System.Web.UI.Util.CheckVirtualFileExists(VirtualPath virtualPath)
// and the rest of the stacktrace
When we get too many of these errors the whole site crashes (have to clear .Net temp files and restart app pool). Basically I can go to a page that doesn't exist, hit refresh many times and take the site down. Extremely bad. However, first thing, how can I get the bots to not try to access this page?
Thanks in advance.
If it's just a single page, or a few pages that are causing this, modify robots.txt to tell the legitimate search engines not to check it.
I'd also check what HTTP response you're sending when the page is not found? You might be sending something that causes the spider to think it should keep checking? Instead of a 404 maybe you should try permanently redirecting to your home page?
Finally, WTF? I'd talk to the Ketnico folks about this bug.
I think that you have a configuration error. While a robots.txt file would hopefully correct this issue, bots can choose to ignore that file.
A better solution would be to setup your error pages correctly. What happens when you go to a page that doesn't exist? It sounds like your system is showing a yellow screen, which is an unhandled exception bubbling all the way up to the user. I would check your error page setup so that users (and robots) get redirected to a 404 error page. I'm guessing that when Yahoo and others see that 404 page, they will stop trying to index it.
Have you tried using a robots.txt file?
I have a file outside a Wordpress install which contains a form that submits to itself. I can access and fill the form out. The form submits and reloads as expected without validation, but when using javascript to submit the form I receive a Wordpress 404 error. The URL of the file stays the same when receiving the 404 error. If I refresh the page it works fine (without 404 error).
I don't know what the difference would be between the two methods of submitting the form. Why would Wordpress get involved in one over the other?
I guess a simple solution would be to update my .htaccess mod_rewrite rules to explicitly ignore the file, could anyone help with that?
Any other suggestions as to the differences between the two methods (form submit v.s javascript submit) would be greatly appreciated, I just can't think of why this would happen.
I tracked down the issue to the form processing. Looking in the logs I found a "Premature end of script headers" error was throwing a 500 Internal Server Error, resulting in a 404 error while trying to use an ErrorDocument to handle the request... the 404 was being handled by wordpress. The premature end of script was caused by some mysql connection code... but in other cases could be caused by an emailer or other form processing scripts. Hope that helps others who run into this problem.