Dropshot idiomatic way of managing CORS ? #1274

rgrunbla · 2025-03-05T13:56:11Z

rgrunbla
Mar 5, 2025

Hey,

I'm using Dropshot to build and expose an OpenAPI endpoint that is consumed by some JS frontend. I also have to deal with CORS, as I will not serve the frontend through the dropshot server.

Is there an idiomatic way of dealing with CORS (e.g. setting headers, answering to preflight OPTION requests) with Dropshot ? My workaround for now is encapsulating my HttpResponse in a CorsResponse struct, e.g.

pub struct CorsResponse<T>(pub HttpResponseHeaders<HttpResponseOk<T>>)
where
    T: Send + Sync + JsonSchema + Serialize + 'static;

impl<T> From<HttpResponseOk<T>> for CorsResponse<T>
where
    T: Send + Sync + JsonSchema + Serialize + 'static,
{
    fn from(response: HttpResponseOk<T>) -> Self {
        let mut response = HttpResponseHeaders::new_unnamed(response);
        response.headers_mut().append(
            header::ACCESS_CONTROL_ALLOW_ORIGIN,
            HeaderValue::from_static("*"),
        );
        CorsResponse(response)
    }
}

impl<T: JsonSchema + Serialize + Send + Sync + 'static> HttpResponse for CorsResponse<T> {
    fn to_result(self) -> Result<Response<Body>, HttpError> {
        self.0.to_result()
    }

    fn response_metadata() -> ApiEndpointResponse {
        dropshot::HttpResponseOk::<T>::response_metadata()
    }

    fn status_code(&self) -> StatusCode {
        self.0.status_code()
    }
}

I'm also implementing OPTIONS endpoints "manually", but that's not exactly optimal.

Could dropshot support a middleware, e.g. like axum does it ?

davepacheco · 2025-03-05T17:27:01Z

davepacheco
Mar 5, 2025
Maintainer

Sorry about that. It's by design that Dropshot doesn't support middleware for the reasons explained here:
https://github.com/oxidecomputer/dropshot/blob/main/README.adoc#why-is-there-no-way-to-add-an-api-handler-function-that-runs-on-every-request

This does make some things more annoying and I don't have a better suggestion for you on this one. The wrapper you've got there seems pretty reasonable. It sounds annoying to have to implement all the OPTIONS endpoint by hand. I could see adding some kind of sugar for that? e.g., maybe in the endpoint macro you could say "for this GET endpoint, also go impl OPTIONS and use this common function for it"?

1 reply

rgrunbla Mar 7, 2025
Author

Thanks for the answer.

@options : Yes, basically, the possibility to have an attribute to specify the behaviour (or function) to use for OPTIONS would be great. In a way, that's losely related to the discussion happening at #57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dropshot idiomatic way of managing CORS ? #1274

{{title}}

Replies: 1 comment 1 reply

{{title}}

{{title}}

Select a reply

Dropshot idiomatic way of managing CORS ? #1274

rgrunbla Mar 5, 2025

Replies: 1 comment · 1 reply

davepacheco Mar 5, 2025 Maintainer

rgrunbla Mar 7, 2025 Author

rgrunbla
Mar 5, 2025

Replies: 1 comment 1 reply

davepacheco
Mar 5, 2025
Maintainer

rgrunbla Mar 7, 2025
Author