OPTIONS header has to be explicitly handled

[edqx]

I might be missing something, I don't know anything about the HTTP spec.

Using the built-in cors middleware, for each endpoint I have to explicitly declare both an OPTIONS handler as well as the handler for the endpoint:

router.options("/resources", options, .{});
router.post("/resources", createResource, .{});

Otherwise, OPTIONS /resources returns 404 and the browser freaks out.

Am I expected to declare these .options endpoints myself, or should http.zig add them 'implicitly'?

P.S. Great project, been very useful for me.

[karlseguin]

I agree this isn't ideal. Before httpz supported middleware, when CORS was just a built-in part of the flow, it behaved like you'd expect.

While I think about how to solve this, one temporary workaround it to define a catch-all route for options:

router.options("/*", noop, .{.middlewares = &.{cors}});

[edqx]

In terms of solving it, is OPTIONS as a method not a standard way for the client to request information about the route? if so, httpz could handle it implicitly.

[karlseguin]

When you create the router, you can now pass a list of middlewares. These will be globally applied (including to requests with no matching route):

var router = server.router(.{.middlewares = .{cors});

Any route-specific middleware will be appended to the global list.

Let me know if that solves the issue.