Consider using HTTP error response statuses where appropriate
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Start by locating the Scotty route handlers and the nginx configuration for compile.purescript.org. Review how oversized bodies, compilation failures, missing endpoints, and deployment failures currently respond; done means the appropriate HTTP statuses and CORS behavior are defined and applied consistently.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- PureScript
- Sterne
- 121
- Forks
- 51
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus purescript/trypurescript
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
purescript/trypurescript#309 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
purescript/trypurescript#308 ·
-
Publish as a library Offen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
purescript/trypurescript#303 · 1 Kommentar ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
purescript/trypurescript#301 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
purescript/trypurescript#293 · 7 Kommentare ·
Alle Issues in purescript/trypurescript
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
area/profiles comp/cli comp/dashboard P2 sweeper:risk-session-state type/bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
NousResearch/hermes-agent#122365 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
vllm-project/production-stack#1105 ·
-
bug priority:low
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
CyberAgent/psd2svg#430 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100