Do I need to do anything extra to get Glimpse to cough up details on a request that return the default 404 server error page on Cassini? By default 404 page, I mean the "Server Error in '/' Application" with a message of "The resource cannot be found" (as well as the HTTP 404 description, requested URL, and version info).
This project has some fairly complex routing, so I don't doubt I have something conflicting with what I am trying to do. I just want Glimpse to provide whatever details it can to point me in the right direction for fixing the problem.
I loaded up Glimpse via NuGet on an MVC3 project I am running through Visual Studio 2010's built-in hosting system (Cassini), and all works fine on previously working action methods and their resulting views. Since then, I added another action method that is proving difficult to hit via the default URL structure (e.g., /controller/action?someparam=x). Since I thought the Glimpse route data would be quite handy for determining what is going wrong here, I went looking for the eyeball in the corder of the default 404 page. Glimpse doesn't appear to be "attached" to this result.
UPDATE: Also doesn't work with RouteDebugger. Whatever I have wrong, it is high enough in the pipeline that nothing seems to be able to pin itself into the response.
UPDATE: The request URL wasn't working because I forgot I had this action set with [HttpPost]. That completely explains the 404, but not how to get any route information from the various utilities on the response sent back.
As far as glimpse goes, one of the reason it wasn't showing in the first place is that we only enable Glimpse on 200 Success results. Hence why the eyeball wouldn't showup for a 404.
Why its not showing up now... have you gone to the /Glimpse/Config page and turned glimpse on? Glimpse isn't enabled by default, so you have to explicitly turn it on.
Let me know how it goes.
Related
I am in the process of building a shop on wordpress using woocommerce. All is well except that at checkout there is an endless spinning wheel blocking the payment processing.
I have checked the error logs - which show no errors
I have disabled all plug ins - which makes no difference
I have reverted to the default woocommerce shopfront theme - which has the same result.
The console shows no errors.
I have also followed the instructions here https://docs.woocommerce.com/document/endless-loadingspinner-on-the-checkout-page/ which assumes its a memory limit issue. This did not work.
So, after a bit of digging I found some reference here https://mikejolley.com/2015/11/12/debugging-unexpected-token-in-woocommerce-2-4/ and here https://www.maxsangster.com/blog/woocommerce-endless-loading-spinner-on-checkout/
Referring to these two pages I have been able to see that the json response from /?wc-ajax=checkout is just returning HTML which I would imagine is where the issue is.
However I am running an Apache server rather than Nginx as has been mentioned in some threads and articles. Assuming there is a server misconfiguration of the server or something that needs changing what might that be? Bearing in mind that I do not have direct access to this, so will need to be asking someone else to sort it out for me.
And finally if there is something else I can try what might that be?
Thank you to #plushyObject for generating the spark for this one.
The issue turned out that I had a legacy static html holding page in place as the site's homepage rather than having one set up with wordpress. Simply removing the .html page and letting wordpress's homepage take over solves the problem.
The moral of the story create your holding page in wordpress.
Go to Google Developer Tools, then Go to the Network tab. Click the button and make the request and let that bad boy spin out.
You mentioned the response is returning HTML. Click on the request that goes out that appears to be taking forever (/?wc-ajax=checkout) and then click on the Preview tab to display that HTML. I bet it shows an error or a clue, anyway.
In my case the checkout was working fine on Desktop but not on Mobile. After many search on internet I read the solution of #UntitledGraphic.
I had set a redirect in ht-access. The redirect was showing a different home page for mobile. When I removed it, the error gone. I checked back & forth and was sure the ht-access redirect was the problem.
If you have set any redirect in the Htaccess then remove it. This will solve your issue in this case.
I also checked the redirect code on function.php instead of htaccess again the problem appeared. So finally removed the redirection.
In my own case the redirection was the issue. So I had to delete the redirect I created via Cpanel.
I was reading this guide of best practices by Yahoo:
http://developer.yahoo.com/performance/rules.html#no404
One rule that caught my eye is this.
HTTP requests are expensive so making an HTTP request and getting a
useless response (i.e. 404 Not Found) is totally unnecessary and will
slow down the user experience without any benefit.
Some sites have helpful 404s "Did you mean X?", which is great for the
user experience but also wastes server resources (like database, etc).
Particularly bad is when the link to an external JavaScript is wrong
and the result is a 404. First, this download will block parallel
downloads. Next the browser may try to parse the 404 response body as
if it were JavaScript code, trying to find something usable in it.
Is this really best practice?? If a user enters the wrong url on my website, what is this guide recommending? That I just leave the user with the default server error page? If the user enters the wrong url, how can the server return anything other than a 404? I simply don't understand this advice and wonder if anyone can explain the reasoning, thank you.
The best practice is that you serve different 404 documents in different situations.
For resources, that are not intended to be directly requested by a user but rather embedded into other documents (i.e., images, stylesheets, script files, etc.), should not result in a detailed error document but rather simply be empty, i.e., no body. With no body present, the browser won’t try to parse it.
But for resources, that are intended to be directly requested, a detailed 404 document with helpful information and guidance is better.
You could also take the presence of a Referer header field instead of the author’s intention as indicator whether a 404 document is useful or not.
I have an application running in Azure (trial account). So far so good, everything has been nice, except for a long deploy times (10-15 minutes).
I've done a deploy recently and got a lot of weird bugs I cannot trace. For example, if I log in and thus a cookie is created (I use FormsAuthentication) all I get from the application is a blank page, as in, absolutely nothing is sent to the browser. The application works fine in the ASP.NET Web Dev Server, IIS Express, even the Azure Emulator!
What could be the issue? Searching the web hasn't been much help, with only a couple of unrelated issues.
I tried logging into the site (if I correctly understood from one if the comments, the url is versulo.com) and I didn't get any blank page with 404 status code.
However, there is another problem I spotted. Your site seems to be implementing caching inappropriately. The main page, the one from which you trigger the login and which is dynamic in nature contains an Expires header set at 5 minutes after the pages first load. That means that each call or redirect to that page within 5 minutes since it was first loaded, will be served from the browser's cache.
Because of that, after I login into your application I am redirected back to the home page which looks like I am not logged in. If I force a F5 refresh on the browser, then the page will indeed show me as logged in.
If instead of a refresh I try to login again (which is what I did in my first trials, since it looked like the login didn't work in the first time), I am getting an error page with the following message:
Sorry, there has been an error on the server.
500
The page looks like an application error page and even if it displays the 500 number, it is actually served with an HTTP 200.
So, while I am not 100% sure if this is also the cause of the problem described by you, you should remove the Expires headers from the dynamic pages your application is serving.
This can be because you're combining Forms Authentication with multiple instances. Are you using multiple instances? If that's the case, could you:
Try to change it to 1 instance. Does this fix the issue?
Try to make the following change to the web.config (configure machineKey): http://msdn.microsoft.com/en-us/library/ff649308.aspx
some partial views are not rendered at all;
Do you mean some pages are working fine, but others are not? It would be better if you can point out a pattern on what’s working and what’s not? For now, please make sure all referenced assemblies (except for default .NET assemblies and Windows Azure runtime) have Copy Local set to true. For example, MVC assemblies are considered as extensions to .NET, so please set Copy Local to true. In addition, you can also try to use Fiddler to monitor the requests to see what’s returned from the server.
Best Regards,
Ming Xu.
Could you provide a link to the application, or perhaps some source code?
When you say 'blank page', what is actually returned, a 404 / 500?
Have you inspected the IIS logs, or added some trace information to your code?
Have you tried accessing the service using it's ip address rather than domain name?
I am developing a website using Microsoft MVC3, and have built it upon the default MVC3 Application template. It accesses an external database and works on localhost.
I have deployed it to a shared server I rent from storminternet via the publish tool using ftp method (storminternet do not yet support web deploy), and it runs well. It accesses the database okay and get requests work fine.
However, any form that submits via POST protocol returns page not found error 404 (this is on actions where I have asserted [HttpPost]).
Storm internet assure me that POST and GET are allowed by default, and since the helpdesk are not developers, I'm unsure who to turn to. I don't have an excellent understanding of web.config, although I can read and understand xml and see what's going on by reading through and googling. I have tried adding the protocols to the root web.config, and I think I might be barking up the wrong tree.
Has anyone else had this problem, or might anyone know how to help me?
To replicate my error, my site is here... 213.229.125.117/$sitepreview/ase-limited.com/Dev (sorry it isn't blue. The dollar gets parsed to % something)
and the quickest route to a POST request is to click 'Add Building' at the top of the left-hand side and then click 'Save' at the top of the dialogue box.
Any help will be gratefully received. I've been stuck on this for days without luck.
Best Regards
Nick
STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-STOP-PRESS-
It turned out to be a known issue with sitepreview. Switching to the proper domain sorted everything.
I have noticed that you have some 404 javascript errors when performing your AJAX requests. For example you have a request to:
http://213.229.125.117/$sitepreview/ase-limited.com/BuildingManager/Employees/2
instead of:
http://213.229.125.117/$sitepreview/ase-limited.com/Dev/BuildingManager/Employees/2
Notice how /Dev is missing. That's because in your javascripts you have hardcoded your urls instead of using url helpers to generate them. For example you wrote something like this:
$.ajax({
url: '/BuildingManager/Employees/2',
....
});
which works fine on localhost because you don't have a virtual directory name but doesn't work when you deploy on your server because now the correct path is:
$.ajax({
url: '/Dev/BuildingManager/Employees/2',
....
});
For this reason you should absolutely never hardcode urls like that.
And when I try to POST the form in tries to post to http://213.229.125.117/Dev/BuildingManager/SaveBuilding which seems a very weird url as it is missing the whole beginning. Once again: never hardcode urls. Always use url helpers.
So I've been noticing some strange results in how google peruses our site. One issue is that a url such as this:
http://example.com/randomstring
is showing up on google with all of the data of
http://example.com/
So in my mind there are two solutions. One is to add a 301 redirect whenever someone visits a sub-url of the main one, and redirect them to the parent URL, or just give a 404, with a nice message saying, "Maybe you meant parent-url".
Thoughts? I'm pretty sure I know where I want to send them, but what is the proper web-etiquette? 404 or 301?
The correct http way would be a 404, as long as a request is made to something that doesn't exist.
301 is for something that is moved, which is not the case here.
However, 100% correct http convention is rarely followed today. Depending on the context it could be useful to redirect the user to the home page with a notification that the page wasn't found and that they were redirected. Though in this case you should use a 303 See Other code.
You should never redirect without letting the user know that a redirect happened, though. That confuses the user to think that maybe something is wrong.
The already posted answers cover your question nicely but I thought there may be some value in going to the source: rfc 2616
10.3.2 301 Moved Permanently
The requested resource has been assigned a
new permanent URI and any future
references to this resource SHOULD use
one of the returned URIs. Clients with
link editing capabilities ought to
automatically re-link references to
the Request-URI to one or more of the
new references returned by the server,
where possible. This response is
cacheable unless indicated otherwise.
The new permanent URI SHOULD be given
by the Location field in the response.
Unless the request method was HEAD,
the entity of the response SHOULD
contain a short hypertext note with a
hyperlink to the new URI(s).
If the 301 status code is received in
response to a request other than GET
or HEAD, the user agent MUST NOT
automatically redirect the request
unless it can be confirmed by the
user, since this might change the
conditions under which the request was
issued.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
10.4.5 404 Not Found
The server has not found anything matching the
Request-URI. No indication is given of
whether the condition is temporary or
permanent. The 410 (Gone) status code
SHOULD be used if the server knows,
through some internally configurable
mechanism, that an old resource is
permanently unavailable and has no
forwarding address. This status code
is commonly used when the server does
not wish to reveal exactly why the
request has been refused, or when no
other response is applicable.
Of course, with these things it tends to be that the common usage takes precedence over the actual text of the RFC. If the entire world is doing it one way, pointing at a document doesn't help much.
I'd say a 404 is the right thing to do, as there never was a meaningful resource at the location, so nothing has "moved permanently" (which is the meaning of 301) and the client needs to know their URL was faulty and has not just changed in the meantime.
But I don't quite understand yet what the issue is. Is Google hitting your site with random URL requests? That would be odd. Or is it that your site is showing the same results for domain.com/randomstring as for domain.com/index.html? That you should change, methinks with a 404.
If you know what URL they should go to, that's exactly what 301 is for.
So are you saying that your site is doing redirects without your control?
When you want to use a 301 (permanent redirect) is when that page originally existed but has moved somewhere else. It's a "Change of Address Card". Huge lifesaver when restructuring a site. If the page is just some wacky random URL, then passing a 404 tells spiders (and humans too but people do this less) that this page never existed so don't keep coming back and wasting my web-servers time. Some people disagree with this because they never want their users to see a 404 page. I think these codes were developed for good reason and are used pretty well by Search Engines.
Passing either of these status codes does not prevent you from serving "friendly pages" (although a 301 will typically just redirect you if the browser allows).
The thing to remember is that Google doesn't like duplicate content, so you want to make sure that your site does not appear to be serving the same content with different URL's.