Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server does not return valid JSON #25

Open
andreaferretti opened this issue Dec 4, 2014 · 5 comments

Comments

@andreaferretti
Copy link

commented Dec 4, 2014

Many responses from the server are returned with content-type application/json, but only contain OK (without quotes) as the body.

This makes many clients fail, as OK is not valid JSON. It would be enough to either

  • return "OK" with quotes, or
  • change the content-type to text/plain for those responses
@velvia

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2014

Good point.

-Evan
"Never doubt that a small group of thoughtful, committed citizens can change the world" - M. Mead

On Dec 4, 2014, at 3:37 AM, andreaferretti notifications@github.com wrote:

Many responses from the server are returned with content-type application/json, but only contain OK (without quotes) as the body.

This makes many clients fail, as OK is not valid JSON. It would be enough to either

return "OK" with quotes, or
change the content-type to text/plain for those responses

Reply to this email directly or view it on GitHub.

@xjrk58

This comment has been minimized.

Copy link

commented Sep 17, 2015

Maybe better to return valid JSON by replacing all
ctx.complete("OK") with
ctx.complete(StatusCodes.OK, Map(StatusKey -> "OK"))

@noorul

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

I don't think we need status for most of the operations. In REST world we should actually be using HTTP status codes.

@noorul noorul added the enhancement label Oct 7, 2015

@velvia

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

There’s a difference between status codes for a job and the status of the HTTP request itself, which is what the HTTP codes are for.

For example:

HTTP 200 - “OK” - request succeeded and job succeeded
HTTP 200 - “ERROR” - request succeeded for info, job errored out
HTTP 500 - something wrong with request (wrong job ID - actually that would be 400) or job server

I think the distinction is important.

On Oct 7, 2015, at 5:45 AM, Noorul Islam K M notifications@github.com wrote:

I don't think we need status for most of the operations. In REST world we should actually be using HTTP status codes.


Reply to this email directly or view it on GitHub #25 (comment).

@CalebFenton

This comment has been minimized.

Copy link
Contributor

commented Sep 1, 2016

HTTP 200 with a status of ERROR may also mean akka had a timeout (e.g. akka.pattern.AskTimeoutException). This means if you're parsing responses, getting 'ERROR' may mean the job had an error or there was an error handling the request.

@bsikander bsikander added bug newbie and removed enhancement labels May 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.