Mystery... Faked Referrer Generates 500 Instead of 404 Error - django

I hope someone can provide some clues.I have begun receiving
regular 500 errors from a page that does not exist. Without providing
the entire error page, here are the essentials:
[Django] ERROR (EXTERNAL IP): Internal Server Error: /sample/
path/calendar.pl
IOError: request data read error
'HTTP_REFERER': 'http://mydomain.org/calendar.pl',
'PATH_INFO': u'/sample/path/calendar.pl',
If I visit the page http://mydomain.org/calendar.pl, I get a 404
error, but the error message referencing the same page generates an
internal server (500) error.
QUESTIONS:
Should I be concerned?
Why do I get a 500 error instead of 404 error?
Any suggestions for troubleshooting?
This has been driving me nuts for a few days. Any help is very
appreciated.
Thanks

Are you trying to change one of the attributes of request, which are read-only (or at least, should be considered to be read-only"). Are you trying to change request.META['HTTP_REFERER']?

This is still an open bug which might be resolved in v. 1.6.
In the meantime, though, you can use this workaround in your settings.py file.

Related

Getting error: "The content-type is not JSON compatible" after a period of time

I'm not really sure exactly how long it takes before I get this error, but after a period of time, I get "The content-type is not JSON compatible" error. I am able the query just fine from graphql playground but not in my app. I am using persisted queries, so not sure if that is the cause.
The only fix is to restart my app.
Here is the
stacktrace
Based on the stacktrace you posted I can see that the server (in particular, probably the resolver for whatever query/mutation you are sending) is returning something unexpected i.e. not "JSON compatible".
Based on what you provided, that's all I can say. Please add more details and I can provide additional help. Just including the stacktrace is not enough to determine the cause of this issue.

Getting gskey: request denied

Hey trying to insert and update a list items on one of my tabs but i'm getting the error msg "gskey: request denied error".
I don't understand what this error means. Can someone please clarify what would be the cause for this error.
A call to the checkgskey function on the server side gives the "gskey: request denied" error if the X-GSREQ-KEY in the POST request is missing.
X-GSREQ-KEY is automatically transmitted by a dedicated parameter in either ajxpgn or reload tab. The content of the gskey is output by the emitgskey function.
emitgskey('unique_phrase');
checkgskey('unique_phrase');
As long as the two unique phrases match, the request is not blocked. The unique phrase acts as a seed to compute a protective challenge that's unique to the user, session and location. In a way, the purpose of a GSKey is similar to a nounce.
Additional documentation here.
Turns out the gskey wasn't being passed in with the call. You get that error when there's a key expected but not given.

Sharepoint 2013 Online - Newsfeed error

Adding a news feed from Mysite of Sharepoint 2013 Online gives this error
"
The following error is returned: The request is invalid. Internal type name: Microsoft.Office.Server.Microfeed.MicrofeedException. Internal error code: 14. Contact your system administrator for assistance in solving this problem.
This can not be sent, because there are some problems have occurred."
Adding a newsfeed from home page works though.
In my case i had jquery library refrence in the page. I created a new jquery object using noConflict() and used that instead of the default $. For some reasoms $ caused some issues and i was unable to post in the news feed.
var jQ = jQuery.noConflict();
jQ(document).ready(function(){
//demo code
});
Below is the error message that used to get.
The request is invalid. Internal type name : Microsoft.Office.Server.Microfeed.MicrofeedException . Internal error code : 14+sharepoint
Another reason was i have multiple references of jquery library in my page which was the reason.
Hope this might be useful to someone.
Internal error code 14 says "Invalid_Content_Null_Or_Empty". So it might be possible that the content you are updating is invalid. So you need to check that.

Apache wink REST - IllegalArgumentException for a particular header

My rest service works fine if I give the authentication header. But the same is throwing 500 internal Service error when I add log-level=debug|info along with the authentication header. I don't know where it is failing. I'm getting only the below errors.
org.apache.wink.server.internal.RequestProcessor logException
IllegalArgumentException occurred during the handlers chain invocation
I could not able to get more information about the error. Please help me. Thanks.
Update:
i'm using wink incubator 1.1.1
Atlast found the solution to this. Instead of debug, when i try with Debug this is working fine. The exception was thrown from a .jar. when I got the source of it, i debugged and found the value for loglevel was in a enum and its in camelcase. The issue is fixed now. Thanks for your responses.

REST: Mapping application errors to HTTP Status codes

Is it to be considered good practice to reuse RFC HTTP Status codes like this, or should we be making up new ones that map exactly to our specific error reasons?
We're designing a web service API around a couple of legacy applications.
In addition to JSON/XML data structures in the Response Body, we aim to return HTTP Status Codes that make sense to web caches and developers.
But how do you go about mapping different classes of errors onto appropriate HTTP Status codes? Everyone on the team agrees on the following:
GET /package/1234 returns 404 Not Found if 1234 doesn't exist
GET /package/1234/next_checkpoint returns 400 Bad Request if "next_checkpoint" and 1234 are valid to ask for but next_checkpont here doesn't make sense...
and so on... but, in some cases, things needs to be more specific than just "400" - for example:
POST /dispatch/?for_package=1234 returns 412 Precondition Failed if /dispatch and package 1234 both exist, BUT 1234 isn't ready for dispatch just yet.
(Edit: Status codes in HTTP/1.1 and Status codes in WebDAV ext.)
RESTful use of HTTP means that you must keep the API uniform. This means that you cannot add domain specific methods (ala GET_STOCK_QUOTE) but it also means that you cannot add domain specific error codes (ala 499 Product Out Of Stock).
In fact, the HTTP client error codes are a good design check because if you design your resource semantics properly, the HTTP error code meanings will correctly express any errors. If you feel you need additional error codes, your resource design is likely wrong.
Jan
422 Unprocessable Entity is a useful error code for scenarios like this. See this question what http response code for rest service on put method when domain rules invalid for additional information.
GET /package/1234/next_checkpoint
returns 400 Bad Request if
"next_checkpoint" and 1234 are valid
to ask for but next_checkpont here
doesn't make sense...
This is the wrong way to think about that URI.
URIs are opaque, so observing that parts of it are 'valid' and others are not doesn't make any sense from a client perspective. Therefore you should 'just' return a 404 to the client, since the resource "package/1234/next_checkpoint" doesn't exist.
You should use 4xx series responses that best match your request when the client makes a mistake, though be careful to not use ones that are meant for specific headers or conditions. I tend to return a human-readable status message and either a plain-text version of the error as the response body or a structured error message, depending on application context.
Update: Upon further reading of the RFC, "procondition failed" is meant for the conditional headers, such as "if-none-match". I'd give a general 400 message for that instead.
Actually, you shouldn't do this at all. Your use of 404 Not Found is correct, but 400 Bad Request is being used improperly. A 400 Bad Request according to the RFC is used solely when the HTTP protocol is malformed. In your case, the request is syntactically correct, it is just an unexpected argument. You should return a 500 Server Error and then include an error code in your REST result.