My web application uses ajax and i check request is ajax request or not via php codes. If not then i generate 404 error otherwise run php codes that associated ajax function.
If user or search spider tries to reach ajax function page(ex: /books/ajax/books_list) web app return 404 not found status code and i see a lot of 404 errors in google webmaster tools.
I should change 404 status code but which one is right for this condition ? Can be "406 not acceptable" ?
I think 403 (Forbidden) probably best describes it. The resource is there, but you've determined that you're not going to give access to that resource, and even authenticating the user isn't going to help.
I would suggest that you return the 406 you suggested. The only alternatives worth considering are '501 not implemented'
The server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource
And '403 Forbidden'
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not
wish to make this information available to the client, the status
code 404 (Not Found) can be used instead.
Not sure how you determine whether it's a proper Ajax request. If you expect it to be POST, but the spider uses GET, then it should be 405 (Method Not Allowed).
You should not be using 406: it means "not acceptable", in the sense that you cannot support the HTTP Accept: headers that the browser sent. This would likely be incorrect (as you likely aren't checking the Accept headers at all).
If you really reject the request because it comes from an unauthorized client, then 403 is appropriate.
It's my understanding that SE spiders get a little skittish if they see errors that indicate server problems. (A 406 can indicate a badly implemented server.) A 404 doesn't describe what you're looking for, as the resource is there, but a 403 (forbidden) just lets the spider know that this page isn't for them. You can also use your robots.txt file.
Related
this is a similar question to this post in SO.But the answer provided here cannot be applied in my case as i cannot change the response headers from server.
Suppose an http POST to a different origin. This implies CORS, including a CORS preflight exchange. Now suppose the OPTIONS request returns a 503 service unavailable error due to a server problem. In this case the error handler gives ""for data and 0 for status instead of giving me the status code 503 and the text:service not available. An example of this scenario is illustrated in the below image.
I am using angularjs $http and i know in the response there are no CORS header if such errors happen.and i cannot change it.
Is there any way i can receive the proper error code and the text in my rejection object.
This is not an issue of AngularJS / $http but it is the behavior of the browsers and their XMLHttpRequest object: If the CORS request fails, the browser does not give any information back to the caller.
Before I got this understanding, I also though it to be an AngularJS issue and I raised an open issue on github of Angular -> with the corresponding comment.
https://github.com/angular/angular.js/issues/13085#issuecomment-148047721
So I think there seems no other way to solve this as to add the Access-Control-Allow-Origin response header also on the proxy / load balancer in case of 503.
Edit:
If your load balancer is a HAproxy, the following may help you too:
HAproxy: different 503 errorfile for OPTIONS and POST methods
It shows how to let HAproxy anwer the CORS requests autonomous.
I have an AngularJS application that talks to various java services. In the application I have a global http header setting in an http interceptor. That means all the service requests from my application will get the header values.
Now the trouble is that all the services CORS settings won't allow this header value. Couple of services does, while others does not. The service calls to the servers that do not support the header fails, since the http interceptor always puts the header values.
Is there a better way to design, in the above said case, so as to avoid the issue stated?
Appreciate any help...
How about adding a response interceptor, looking for a 401 status? If you get a 401, attempt to do the same request again without the headers this time. If this succeeds, 'whitelist' this domain to make all following requests without the headers that you don't want.
Otherwise, if you have a limited number of services that you are making calls to, maybe whitelist them inside of your request interceptor? This would probably be easier, but it's not very elegant.
I'm trying to implement a simple interceptor that allows me to display a message along the lines of "cannot contact the server" in my Angular app. However as the API is on a different host I'm dealing with CORS pre-flight OPTIONS requests.
I've found that if the API is unavailable Chrome dev tools shows a 503 on the OPTIONS request but Angular's $http interceptor catches a 404 response to the subsequent GET request. I believe this is because the OPTIONS response did not contain the required CORS headers so the GET is actually never performed.
Is is possible to intercept the OPTIONS response? If all I see is a 404 I can't distinguish "server down" from "no such resource".
You can't intercept this request by design - the browser is "checking up" on you, making sure YOU should be allowed to make the request.
We've used three solutions to work around this:
If the problem is that you're using a development environment like NodeJS, and your domain names aren't matching (that is, if you normally wouldn't need to deal with this in Production) you can use a proxy. The https://github.com/substack/bouncyBounceJS NodeJS Module is an easy to use option. Then your Web service request domain will match the domain your page is on, and the check won't be triggered. (You can also use tricks like this in Production, although it can be easily abused!)
Also for temporary use, you can use something like Fiddler or Charles to manipulate the request by faking the required headers, or tell your browser not to check them (--disable-web-security in Chrome).
If you have this problem in Production, you either need to legitimately fix it (adjust the Web service handler to add the required headers - there are only two), or find a way to make the request in a way that doesn't trigger the check. For instance, if you control both the source and target domains, you can put a script on the target that makes the requests to itself. Run this in an IFRAME, invisibly. Then you can use things like postMessage() to communicate back and forth. Large services like Facebook use "XHR bridges" like this for the same reason.
I am trying to develop a client application that calls a RESTful web service. As part of a RESTful design, the service uses a variety of HTTP status codes to communicate state back to the caller. For instance, if I request a resource that doesn't exist, the service responds with a 404 status code. Likewise, if I pass in malformed parameters, the service responds with a 400 (Bad Request) status code. Silverlight 5 automatically converts these into WebExceptions. Is there anyway I can get SL to not throw exceptions but return a legitimate response object with the status code, etc set to the what was received so that I can decide how to handle the response in my code?
(To further clarify, it appears this is only the case for status codes in the 400 and 500 ranges.)
AFAIK, there is no solution to avoid exceptions. Worse than that, it might be hard or even impossible to get the actual HTTP code (I'm not certain there, I haven't tried too hard).
You'll probably want to develop an HTTP request tool that traps WebException and provide an error status to the caller.
In one of the answers that I have received here, I encountered a problem of not knowing how to pass automatically through "Google App Engines" my ID and a password to a website, on which I am a registered user and have an account. A suggestion was given to me to "check for an HTTP status code of 401, "authorization required", and provide the kind of HTTP authorization (basic, digest, whatever) that the site is asking for". I don't know how to check for status code. Can anyone, please, tell me how to do it?
+++++++++++++++++++++++++++++++++
Additional Information:
If I use this way in Google App Engine (fetching the url of my eBay summary page):
from google.appengine.api import urlfetch
url = "http://my.ebay.com/ws/eBayISAPI.dll?MyEbay&gbh=1&CurrentPage=MyeBaySummary&ssPageName=STRK:ME:LNLK"
result = urlfetch.fetch(url)
if result.status_code == 200:
print "content-type: text/plain"
print
print result.status_code
I always get "200" instead of "401"
In ordinary Python code, I'd probably use the lower-level httplib, e.g.:
import httplib
domains = 'google.com gmail.com appspot.com'.split()
for domain in domains:
conn = httplib.HTTPConnection(domain)
conn.request('GET', '/')
resp = conn.getresponse()
print 'Code %r from %r' % (resp.status, domain)
this will show you such codes as 301 (moved permanently) and 302 (moved temporarily); higher level libraries such as urllib2 would handle such things "behind the scenes" for you, which is handy but makes it harder for you to take control with simplicity (you'd have to install your own "url opener" objects, etc).
In App Engine, you're probably better off using urlfetch, which returns a response object with a status_code attribute. If that attribute is 401, it means that you need to repeat the fetch with the appropriate kind of authorization information in the headers.
However, App Engine now also supports urllib2, so if you're comfortable with using this higher level of abstraction you could delegate the work to it. See here for a tutorial on how to delegate basic authentication to urllib2, and here for a more general tutorial on how basic authentication works (I believe that understanding what's going on at the lower layer of abstraction helps you even if you're using the higher layer!-).
Unless I don't understand fully your question, you can grab the return code from the Response Object using the status_code property.
First, you'll have to issue a fetch() to the URL you want to test.
Most user-oriented sites don't use HTTP authentication, preferring instead to use cookie-based authentication, with HTML forms for signin. If you want to duplicate this in your own code, you need to make an HTTP POST request to the login URL for the application in question, and capture the cookie that's sent back, including that in all your future requests to authenticate yourself. Without more details about the specific site you're trying to authenticate against, it's difficult to be more specific.
You are not getting 401 because that site is not returning 401 but 200 always. Usually type of coding we do for websites is return 200 with a page saying "Please login..blah blah", if site returned anything other then 200 browser will not display the funky error msg.
So in short as i mentioned in other question, you need to look into login page, see what params it uses e.g login=xxx, password=yyy, post it to that page and you will have to manage the cookies too, that is where library like twill etc come into picture.