On Fri, Jan 25, 2019 at 8:27 PM James Bennett wrote:
> My immediate thought here is: if people already aren't taking the time to
> patch using the existing mechanism, they also aren't going to take the time
> to opt out of patching. So what you're proposing is effectively still "any
> accessed
On Fri, Jan 25, 2019 at 9:39 AM Linus Lewandowski <
linus.lewandow...@netguru.co> wrote:
> True, probably a way to access headers without marking them as used would
> be required - maybe something like request.headers.get(XYZ,
> vary_response=False).
>
> However, right now people are commonly
I would like this - Django is a framework with batteries, and my
development group tells me "Django is too hard". This is because they
don't understand HTTP; mostly they understand HTML/CSS and SQL, with maybe
some easy jquery level of SQL. So, this kind of solution would fit well for
my
While reading this thread https://code.djangoproject.com/ticket/19649 came
to mind. I think most (if not all) from there basically is the same issue,
even though that one just concerns itself with the Cookie header.
I do not agree that request.headers is __now__ the single place for
accessing
> Accessing the value of a header doesn't necessarily mean that the
response varies based up on, for example it might simply be accessed for
storage in informational logs.
True, probably a way to access headers without marking them as used would
be required - maybe something like
Accessing the value of a header doesn't necessarily mean that the response
varies based up on, for example it might simply be accessed for storage in
informational logs. Additionally, Request.headers is not the only way to
access the values now, Request.META has not been removed. I don't believe
Right now, it's hard to report Vary header correctly. 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 - and all those cases should be reflected in the Vary header,
or
