I have a ASP.NET web application that implements url rewrite throught an Http Module. Each rewrite rule are loaded from a database table.
After I added a new rule I got the following error:
Value does not fall within the expected range.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: Value does not fall within the expected range.
I don't find anyting in application logs.
In this case, after a long investigation I found the character
\n
after redirection url name.
When http module send redirect to IIS, all went Ok, but during request processing IIS itself got the error above.
I think that's a very strange error, and I spent lot of time to detect, so I think to share solution (of course it's all my fault!).
Related
Why is error 410 considered a user error (4xx) and not a redirect (3xx) or a server error (5xx)?
I request a payload from a server, and the server returns a link. I copy the link and the link gives 410? It isn't my fault to verify the link actually exists on their server. But at the same time, from the server's point of view the error originated from me, as I accessed something that doesn't exist, similar to 404 where I access something that was never there.
Can anyone help me understand the decision behind this?
Code 410
"410 Gone" client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.
If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.
Why is error 410 a user error and not a server error?
It's not a "user" error, it's a client error; but yeah, that's a lousy label. The labels reflect the client-server architectural constraint, but it might be better to use labels that point more directly at the contents of the request, rather than the client (or the user).
In practice, it's a client error for the same reason that 404 is a client error; it is specifically calling attention to the target resource of the HTTP request.
In the context of the web, it does make some (imperfect) sense - the client followed a broken link (which could be a consequence of the server's current representations, but might also come from following links in stale representations, following stale bookmarks, a spelling error in a representation provided by a different server, etc).
It's not a question of fault, it just means that the request should not be considered to ever work in the future (it shouldn't be retried). Whereas a server error (like a 5xx error) could be retried periodically and should eventually work sometime in the future since the request itself is considered valid.
In my TYPO3 9 LTS installation, when a request with an invalid (i.e. no TypoScript-configured) type number (PAGE.typeNum) comes in, my installation returns an ugly error message:
Example request: https://www.example.com?type=1234
Example response:
Service Unavailable (503)
The page is not configured! [type=1234][]. This means that there is no TypoScript object of type PAGE with typeNum=1234 configured.
More information regarding this error might be available online.
The more information link points to https://typo3.org/go/exception/CMS/1294587217 , but there currently isn't any helpful information how to better configure my installation.
These error messages are also annoying as they may be triggered by webcrawlers and each request creates an error entry in the TYPO system protocol.
What can I do to fallback to/serve the default type=0 HTML page if a requested type number is not configured?
AFAIK TYPO3 can currently not properly handle that. A 503 is generated, but the according errorHandler in the site configuration is not triggered.
At least the error message will be a bit less ugly ("Ooops, an error...") when you are in TYPO3_CONTEXT=Production ...
There is a feature request to make the unknown page type behave like 404: https://forge.typo3.org/issues/86844
For the time being I suggest adding redirects (301) for all types that you do not want to serve outside of TYPO3 (e.g. .htaccess RewriteRules or nginx rewrites).
I wrote a Node service that takes parameters from a client and puts them into a SOAP request to another (3rd party) service. Lately, when a request is made to my service, the initial response is a 502 Bad Gateway error with a generic HTML block titled "Server Error" (see image). When I submit the same request a second time, the 3rd party responds with a 500 Internal Server error and a message indicating that a request has already been issued for that transaction.
Obviously the initial request made it to the 3rd party somehow, but they say that the 502 error isn't theirs and isn't logged in their system as ever having occurred.
What I'm trying to find out is if the error is somehow coming from my service because of Docker or Azure (or something else I'm not thinking of). The error is so generic that research hasn't yielded anything useful on it. Has anyone encountered this or know what it is?
It turns out that this was an error being thrown by Azure (or so we think) as the result of some faulty error-handling. Part of the response was being parsed incorrectly, which caused the app to stall. It still doesn't explain how the data still got to the other side while this was happening (or why it hit the catch block at all when there was no error in the processing), but if you see a server error returned with this HTML block, check your error-handling code and investigate Azure!
I have seen people using the HTTP code 500 as a generic error code for all kind of error cases (server errors, http errors, code exceptions, expected record not found in DB, time-out exceptions etc). However I have also read and heard that this code 500 should only be used in case of errors originating from the application server (JBoss in my case), and NOT application itself i.e. not for code-exceptions or invalid passwords or DB-record-not-found cases. So, when should we return HTTP Status Code 500 from a REST service method?
As described in the HTTP spec:
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
Original: https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.6
Note that from the protocol point of view, it doesn't matter whether it's the application server or something running inside the application server.
I have just set up a custom tab on my page for the first time. I have thoroughly followed the setup guide and seem to have everything on the Facebook side setup correctly.
However when I view my page it throws the following error:
Method Not Allowed The requested method GET is not allowed for the
URL /Facebook/index.html. Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request. Apache/1.3.41 Server at feebnaturals.com.au Port 80
I believe it may be some kind of Apache server config issue, however I'm not that Apache savvy, so not sure where to start.
I had the same problem, but instead of GET, it was POST method which was not allowed. This is a setting on your server. Not server savvy myself, but it seems that my provider didn't allow this method on html-page, but makes no problem on doing the same for php-pages. So all I did was rename my page from .html to .php, updated the app settings in facebook and all works fine now.
This is definitely an error on your side, check your server logs and see what they say - it looks like you've configured the page to only work via a POST request and it's being requested in a GET request