Django 3.1: CORS headers not set on error responses?

Hello, I’m not sure if there’s something I’m misunderstanding, but from my experiments, it seems like django-cors-headers is not setting CORS headers on HTTP 4XX error responses, when used with Django 3.1. I know there’s been some changes to the way middleware are handled over the years. Is it possible that django-cors-headers needs to be updated to be fully compatible with newer versions?

As an experiment, I added a process_exception() method to CorsMiddleware, like this:

def process_exception(self, request, exception):
    return self.process_response(request, exception)

And that seems to have resolved my issue. Is this a sensible way to proceed? If so, I’m happy to put together a formal pull request.

Thanks for a useful library!

[bjmc]

In our case, yes, I think we definitely want CORS headers set on error responses. We’re using graphene-django to build a GraphQL API. If the client sends us a malformed query, we want to be able to return a sensible error without the browser tripping over CORS restrictions.

I can’t say this is universal, but I would guess most people building APIs in Django and setting CORS headers would also want those headers on their error responses. Do you think it’s correct to treat process_exception() and process_response() equivalently? The only thing that gives me pause is returning an HTTP response from process_exception() will short-circuit other middleware executions. But the CORS middleware needs to be near the outside of the middleware stack anyway, right?

[bjmc]

Hi @marcosalcazar yes, we just subclassed CorsMiddleware and added the process_exception() method as above. We haven’t run into any problems that I’m aware of, but it does feel a little bit hacky. I’d like to see a proper upstream fix for this issue.