如何在DRF中更新Allow头以匹配OPTIONS请求的权限？

问题场景 #

使用Django Rest Framework 3.14，搭配ModelViewsets和全局DjangoModelOrAnonReadOnly权限类时，未认证用户向/api/collections/collectionA/items发送OPTIONS请求，返回的Allow头包含POST，但实际根据权限应该只有GET, HEAD, OPTIONS。自定义options方法时已获取到正确的允许方法，但设置响应头不生效。

解决方案 #

直接通过Response构造函数设置headers可能被DRF后续处理逻辑覆盖，正确做法是先通过元数据确定允许的方法，再直接给响应对象设置Allow头，同时确保HEAD方法（与GET绑定）被正确包含。

代码实现 #

在你的ModelViewSet中重写options方法：

from rest_framework.response import Response

def options(self, request, *args, **kwargs):
    # 初始化元数据类实例
    metadata = self.metadata_class()
    # 获取当前权限下允许的操作
    allowed_actions = metadata.determine_actions(request, self)
    allowed_methods = list(allowed_actions.keys())
    
    # 补充HEAD方法（DRF中GET默认支持HEAD，但determine_actions不会自动返回）
    if 'GET' in allowed_methods and 'HEAD' not in allowed_methods:
        allowed_methods.append('HEAD')
    # 确保OPTIONS方法被包含
    allowed_methods.append('OPTIONS')
    
    # 格式化允许的方法字符串
    allowed_methods_str = ', '.join(sorted(allowed_methods))
    
    # 获取元数据响应内容
    data = metadata.determine_metadata(request, self)
    
    # 创建响应并设置Allow头
    response = Response(data)
    response['Allow'] = allowed_methods_str
    
    return response

简化写法（复用父类逻辑） #

如果想复用DRF默认的OPTIONS处理流程，可先调用父类方法再修改响应头：

def options(self, request, *args, **kwargs):
    response = super().options(request, *args, **kwargs)
    metadata = self.metadata_class()
    allowed_actions = metadata.determine_actions(request, self)
    allowed_methods = list(allowed_actions.keys())
    
    if 'GET' in allowed_methods and 'HEAD' not in allowed_methods:
        allowed_methods.append('HEAD')
    allowed_methods.append('OPTIONS')
    
    response['Allow'] = ', '.join(sorted(allowed_methods))
    return response

原理说明 #

• determine_actions方法会结合当前用户权限，返回实际允许的HTTP方法映射，能准确反映权限控制后的可用操作。
• 直接通过response['Allow']赋值的方式，比在Response构造函数中传入headers更可靠，避免被后续处理逻辑覆盖。
• 手动补充HEAD方法是因为DRF中GET方法默认隐含支持HEAD，但determine_actions不会自动返回该方法，需手动添加。

OGC API Features规范要求 #

服务器无需实现本规范描述的全部可变资源方法（如POST、PUT、PATCH或DELETE）。支持资源增改删的服务器通常会做访问控制，比如策略限制（仅允许插入不允许删除）或用户权限控制（用户X仅能创建资源）。无论采用哪种控制方式，服务器都必须通过HTTP OPTIONS方法，告知当前上下文下资源支持的可用方法。

HTTP OPTIONS方法允许服务器明确声明特定资源端点支持的HTTP方法。本规范涉及POST、PUT、PATCH和DELETE方法，也可列出与特定资源相关的其他HTTP方法。

内容的提问来源于stack exchange，提问作者WhyNotTryCalmer