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

Consider using HTTP error response statuses where appropriate #170

Open
hdgarrood opened this issue May 3, 2020 · 0 comments
Open

Consider using HTTP error response statuses where appropriate #170

hdgarrood opened this issue May 3, 2020 · 0 comments

Comments

@hdgarrood
Copy link
Collaborator

hdgarrood commented May 3, 2020

Right now, the API server returns 200 responses basically unconditionally. The readme says:

Among other things, this makes it easier to use the API from another domain using CORS.

But I don't think this is quite true, because according to my reading of the CORS spec, 4xx and 5xx responses should be visible as long as the appropriate Access-Control-Allow-Origin header is set. It's only preflight requests which must return 2xx responses for the request to succeed, and we don't need to use those because we only use "simple methods" (GET and POST).

I think a 200 response in the case where the code failed to compile is appropriate, but I don't think it's appropriate in a case where we are refusing the process the request because the body is too large; the 413 Request Entity Too Large response seems more appropriate for that. I'm not sure what the best way to handle modules not called Main is.

Relatedly, I think we should add the appropriate CORS headers (in particular Access-Control-Allow-Origin: *) for compile.purescript.org in nginx, rather that on the individual scotty routes as we are doing currently. This way, clients from different origins would be able to handle errors which occur outside of the handling of those particular routes in Scotty, such as 404s for non existent endpoints, or 502s for if a deployment has gone wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant