Add request.headers, track used headers and use that information to automatically populate Vary header.

[Linus Lewandowski]

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?

[Tim Graham]

request.headers is already proposed in #20147. Perhaps you should raise the other points on the DevelopersMailingList as it reaches a wider audience than this ticket tracker.

[Tim Graham]

Closing as "needsinfo", pending a discussion.