Serve CORS
El middleware de CORS maneja el preflight OPTIONS y agrega headers Access-Control-* a las respuestas. cors_configure define el origen permitido, los métodos y los headers. Las cadenas de middleware se aplican en el orden de registro.
Código
// nyx-serve CORS — cross-origin headers for frontend APIs
// CORS nyx-serve — headers cross-origin para APIs de frontend
import "std/http"
import "std/web"
fn api_data(req: Request) -> Response {
return response_json(200, "{\"data\": [1, 2, 3]}")
}
fn main() -> int {
let app: App = app_new()
// Configure CORS policy — who can call the API, what methods, headers
cors_configure(
"https://myapp.com",
"GET, POST, PUT, DELETE",
"Content-Type, Authorization, X-API-Key"
)
// Register CORS middleware — handles OPTIONS preflight + adds headers
app_use(app, mw_cors)
// Also register logging middleware
app_use(app, mw_logging)
app_get(app, "/api/data", api_data)
print("CORS configured for https://myapp.com")
print("middleware chain: logging -> cors -> route handler")
print("OPTIONS preflight requests return 204 with appropriate headers")
return 0
}Salida
CORS configured for https://myapp.com middleware chain: logging -> cors -> route handler OPTIONS preflight requests return 204 with appropriate headers
Explicación
Los navegadores aplican la política de mismo origen (same-origin) sobre XHR y fetch — un sitio en myapp.com no puede llamar a api.myapp.com a menos que el servidor lo habilite explícitamente. CORS es el protocolo de habilitación: el navegador envía un preflight OPTIONS preguntando "¿puedo?", y el servidor responde con headers Access-Control-Allow-*. mw_cors maneja ambas mitades: corta en seco el OPTIONS con un 204 y los headers configurados, y sella cada respuesta real con Access-Control-Allow-Origin. cors_configure centraliza la política para que nunca la hardcodees en un handler. La cadena de middleware corre en el orden de registro — logging observa cada solicitud antes de que cors la reescriba, que suele ser lo que uno quiere.