id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
28533	Add request.headers, track used headers and use that information to automatically populate Vary header.	Linus Lewandowski	nobody	"Right now, it's hard to report Vary correctly - as headers might get accessed in many different places, like middlewares, subroutines (which can't use patch_vary_headers as they don't have access to the response object), etc.

On the other hand, it's possible to easily track all used headers automatically, by using a getter that stores all the requested ones in a set - and then set the Vary header in a middleware.

This is a trivial example of a middleware that does the job - provided that the code accesses headers thru request.headers:
{{{
from django.utils.cache import patch_vary_headers

class RequestHeaders:
	def __init__(self, META):
		self.META = META
		self.used = set()

	def __getattr__(self, header):
		self.used.add(header.lower())
		return self.META.get('HTTP_' + header.upper())

class HeadersMiddleware:
	def __init__(self, get_response):
		self.get_response = get_response

	def __call__(self, request):
		request.headers = RequestHeaders(request.META)
		response = self.get_response(request)
		patch_vary_headers(response, request.headers.used)
		return response
}}}

I think it's a good idea to add similar functionality to the core Django, and I'm willing to provide a pull request - but there are some points to discuss first:

1. Should we add request.headers property, or put this getter on the request object (like in response object; but it may get confused with GET/POST params), or modify the request.META getter?
2. Should the Vary header get set/patched in a new middleware, or one of the existing ones?
3. Maybe it would be a good idea to deprecate patch_vary_headers?"	New feature	closed	HTTP handling	dev	Normal	needsinfo			Unreviewed	0	0	0	0	0	0