Is it possible to check Http status code in Apache configuration as %{REQUEST_STATUS} for instance?
There is no such thing as a "request status", and no way for a server to interact with a browser in the middle of serving an error message.
HTTP is not an interactive protocol; the browser sends a request, the server sends a response, and that's it. So if the browser sends a request, and the application crashes, the server can send a response with 500 and the error details, or a response with 401 requesting the user to log in. Either way, that's the end of the conversation.
When it receives a 401 response, the browser can't say "here's the login details, carry on with the current request", it has to make a new request. It can make an identical request, which might reproduce the error message; but the original error message is gone.
If the requirement is to show a different amount of detail to different users, you need some notion of optional authentication, so that the server can decide immediately whether to include the error details or not, without an extra round-trip to the browser. I would suggest either:
Have a list of IP addresses which the application can check against; if the IP address of the request is in the list, include the error details.
Have a custom login system where you can authenticate and set a "session cookie" in the browser. If the user has an active session cookie, include the error details.
Related
I am confused by why the cors package allows the request to be processed even if the origin in the request header isn't white-listed. For example, res.status(202).send(await User.find()) returns a response with status code 202, but the data can't be loaded in the Chrome console.
Also, doesn't the browser send preflight OPTIONS requests to know what's allowed; why would it send cookies/credentials along a request with a disallowed origin?
Edit: Tried a post request on jsfiddle and the post request doesn't happen server side. When I said "why the cors package allows" it would be better to say why the browser allows.
CORS is enforced in the browser, not in your server. The server participates in setting headers that the browser can then use to determine whether the request should be allowed or not. But, it is the browser that ultimately decides whether the CORS request satisfies the requirements or not and the result should be passed through to the Javascript in the browser.
Thus, the request is sent to the server, response is received and THEN the browser decides whether the Javascript in the page is allowed to see the result or not.
In some cases where the request is likely to have side effects on the server (based on a set of criteria in the request), the browser will send a pre-flight request to get just the CORS info first.
We have a curious situation with http referrer and response.
Our application is a J2EE with a WEB and EJB project. Working fine for years.
Recently, from one specific location, when user click to submit, our EJB sysout picked up trace that there was more than one submit (POST request) resulting in a null pointer. Our button have been designed to be disabled after it has been clicked. We are not sure how a subsequent request can possibly happen. In this simulation of the problem, we click once and there is only one user in the system.
Since this only occur when we connect from a particular ISP. We do not experience multiple request from other ISP locations. So we are suspecting that the ISP may have in advertently trigger a resubmit. But we are not sure. What else can we do to trace the root cause of this problem.
Thanks for your help.
Update on 12-Apr
We have installed wireshark to trace the signal from the browser side. We notice that the browser concern makes a "retry" after every 11 or 12 minutes. Would this be a normal browser behaviour?
I think we have found the cause of the problem. It is explained by by this https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries
It is something in the HTTP spec
"If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. W3 Hypertext Transfer Protocol -- HTTP/1.1
All major web applications (Google, Facebook, etc.) return page status 200 ok in case of authentication failure, i.e. wrong login/password pair.
Although by definition, if a resource is not found with request URI - status 404 Not found is returned.
Wikipedia says:
[404 Not Found] Used when the requested resource is not found, whether it doesn't exist or if there was a 401 or 403 that, for security reasons, the service wants to mask
How does the login case differ?
Server code 200 means you get the response . Whether it is your wrong credentials or not. if Your request has not been processed then server returns different error code . But for your case,
Your login request has been processed , connection with database has been established and from that you get you wrong credential message . So code 200 is for your successfully processed request.
I have some logic in the web server to find out if the user is trying to do a DoS attack. But what's the correct HTTP response code to return for that? Also what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
But what's the correct HTTP response code to return for that?
RFC 6585 suggests 429 Too Many Requests
The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting").
If the attack has compromised your ability to handle legitimate requests, then to those you might respond with 503 Service Unavailable.
Note the change in semantics - the person sending the bad requests gets a status out of the 4NN Client Error class, while those not at fault get a status from the 5NN Internal Service Error class.
what's a good error message I can put in HTTP body to tell the user politely that he's got into the DoS attack path?
Please stop that?
Whenever I try to call Magento's rest resources via PHP, I get an HTTP 500 Internal Server Error. My link is, in accordance to Magento's REST API, http://mymagento.com/api/rest/products.
Everything is set up properly and whenever I try to access it via the browser, the response is a page with the XML data I want. Same thing goes for the RESTClient plugin for Firefox.
I also get the internal server error whenever I try to do an authorised request as a customer.
Does anyone know why this is happening? I ran out of ideas an hour ago or so.
If you just got that problem (only) then,
500 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:
Obtain an IP address from the IP name of the site (the site URL
without the leading 'http://'). This lookup (conversion of IP name to
IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response.
This data stream contains status codes whose values are determined by
the HTTP protocol. Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'. (Last updated: March 2012).
Fixing 500 errors - general
This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.