I sometimes get http 404 errors in my client on a certain url on my tastypie API.
However, when I access it manually via my browswer, it works all the time with the exact URL that the client is requesting.
This is a GET call with some query parameters:
https://example.com/v2/xxx?limit=&offset=×tamp=
How can I debug this?
UPDATE 1
It looks like the error is returned by tastypie because the response body is {"error_message": "Sorry, this request could not be processed. Please try again later."}
UPDATE 2
It seems that it is a NOT_FOUND_EXCEPTIONS in tastypie resources.py, but how can I debug a transient problem? The data is pretty static and does not change.
Related
For my Django project, I am using djstripe. Using test data, I have confirmed that payments are successful. However, when testing a webhook, I get errors of 404 and then it sometimes changes to 503 (for the same webhook). I am using Heroku free tier so I am not sure if that is the problem, or if I am configuring the webhooks entirely wrong (likely since this is my first project). Any help is appreciated.
Stripe endpoint I have as [heroku domain]/users/accounts/webhook/ and my project urls is path('users/accounts/', include('allauth.urls')),
404 means that the URL you've provided to Stripe for your webhook is not found on/by your server; this is something you'll need to investigate on your end.
If you share more code - like specifically the code containing your route for the webhook - that might be useful for helping you diagnose the issue here.
i have found some solutions.
1- copy response of HTML tags and convert it to an HTML Page. you will be able to see the error raising from your platform which is failing the webhook.
2- Debug the each line of webhook view/code.
I have a django project which used the normal email admins on an unhandled exception when debug is set to False. ie in production.
I normally just review the error message and the stack trace. However I clicked on the request url link, which managed to recreate the error on the prouduction site (which then fired off another email).
What is this request url? Does it recreate the full http request (including the session etc..) which resulted in the original error?
Can I get the link to point to a local version of the site? (As after fixing a previous error clicking on the earlier request url has manged to create a recent error that we have been unable to reproduce, so it would be good to recreate this locally so it can be debugged.
I am trying a GET request from Facebook for a batch of ids using my app access token separated by a comma.
Please find below the call:
https://graph.facebook.com/?ids=1374186930,100005305471358,1516423103,100003031846875,100002939786624,100004705179654,522691095,100002893804783,100005269178084,1417831236,100004652521769,100003511989378,100002394692546,1646211152,1092931510,100000152985362,100004151552444,100004122698187,100001574061632,100005007584068&access_token=<my_app_access_token>&format=json
Facebook returns an error intermittently for some of these requests with an HTTP status code of 502.
I've tried fetching for these ids using the graph API explorer as well as the app access token later. They have been fetched properly. I have performed some research, but all issues of Facebook were related to open graph and 502 is "Bad Gateway Error". Since mine is not a web app, I cannot even refresh a browser to make the call again. This is a normal call made to Facebook API.
The error returned by Facebook is html which contains the following message:
"Sorry, something went wrong. We're working on getting this fixed as soon as we can."
Since they have given this response, I want to know if someone is facing this issue as well and if somebody could tell me, when this will be resolved.
This is affecting the other calls as well and there is a delay in the fetching.
Thanks in advance.
The Error 502 means that the message is too large. I do not know exactly the maximum size. Curiosity. What language are you using??
Good Bye
The background is like this:
The client web browser send a request to the server;
The server program will launch some biz check rules before doing the real work.
If check fail, some tips should be feed back to the client browser.
So, here is the question. Should I use an error response http code to indicate this, or use 200 directly, and then parse the message from response body.
Sometimes, this is not a problem. But, some client component give some util methods if error code returned. So, that's a hard decision to make:
return 200,and error message. parse and show them myself;
return some code like 500, let the client component to show it directly.
I would suggest to use as many http status codes as possible. That is a standard and why should you not use them?
Here are some examples where IMHO the usage of http status codes makes sense:
Somebody wants a dataset wich is not aviable use 404 not found
A secured ressource needs an authentification use 401
A ressource which is not aviable for the currient user should get a 403 forbidden
A error accours which you cannot handle well write out an 500 status
And so on
Look also for the logic for REST-APIs there you can see the advantages.
Typically, you'll want to indicate the reason the service failed. Returning custom errors can also potentially allow the client application to respond in an appropriate way. If an input validation check fails, for instance, I imagine the user would appreciate the chance to fix and resubmit the request. An HTTP error won't be enough to indicate what exactly went wrong.
I'm implementing an API. The API accepts/returns JSON content type.
Now, suppose that the data submitted by some POST request is not valid, like a missing attribute, or a duplication exists for the same data.
What is the standard HTML response code in that case?
The error lies on the client side, so you want to use a 4xx status code. I'd go with 400 - Bad Request:
The request could not be understood by
the server due to malformed syntax.
The client SHOULD NOT repeat the
request without modifications.
There are two answers:
If you have submitted a form, just return 200 - OK with HTML explaining why the object was not created.
If you have an API you should use the following
200 OK
When the request was OK and returned the proper data.
201 CREATED
The call was successful and the new object created.
400 BAD REQUEST
Invalid request URI
Invalid HTTP Header
Receiving an unsupported, nonstandard parameter
Receiving an invalid HTTP Message Body
401 UNAUTHORIZED
Authorization problems. E.g. wrong API key, etc.
403 FORBIDDEN
Properly authorized, but not allowed.
404 NOT FOUND
The resource does not exist (e.g. on Read or Update)
405 METHOD NOT ALLOWED
Use in situations that a given REST method is not allowed. E.g. a POST on a single resource, or a DELETE on the entire collection of resources.
409 CONFLICT
When an update fails, send "Conflict" to allow the client side to resolve the conflict themselves and retry.
500 INTERNAL SERVER ERROR
Internal error. This is the default code that is used for all unrecognized errors.
501 NOT IMPLEMENTED
Use for expected, but not yet implemented features.
The closest i can find would be 400 Bad Request.
As Ariejan said you should base your API in the HTTP codes already defined. If you want to send a error message the best way should be not use the HTTP message, but better include the message in the response body, JSON formatted.
422 Unprocessable Entity (see RFC 4918, Section 11.2)