#15741: Class-based generic views dropped support for X-Object-* headers
-------------------------------------+-------------------------------------
Reporter: russellm | Owner: nobody
Type: New | Status: new
feature | Component: Generic views
Milestone: | Severity: Normal
Version: 1.3 | Keywords:
Resolution: | Has patch: 0
Triage Stage: Design | Needs tests: 0
decision needed |
Needs documentation: 0 |
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
Description changed by russellm:
Old description:
> The function-based generic views use the
> django.core.xheaders.populate_xheaders method to attach a X-Object-Type
> and X-Object-Id header to responses served by a generic view. This debug
> information in the response
>
> Django needs to either:
> 1) Deprecate and remove populate_xheaders, or
> 2) Add X-Object-Type and X-Object-Id header support to class-based
> generic views.
>
> If we choose to do (2), then we can't just wrap the generic view response
> in populate_xheaders, because we don't have access to the response object
> at the time at which we determine the object that is in use. It will
> probably be necessary to add generic support to define headers anywhere
> in the lifespan of a request, and then apply those headers when the
> response is constructed; i.e., in much the same way that self.request is
> available throughout the lifespan of a request, make
> self.response_headers available throughout the lifespan of a request.
New description:
The function-based generic views use the
django.core.xheaders.populate_xheaders method to attach a X-Object-Type
and X-Object-Id header to responses served by a generic view. This debug
information in the response
Django needs to either:
1. Deprecate and remove populate_xheaders, or
2. Add X-Object-Type and X-Object-Id header support to class-based
generic views.
If we choose to do (2), then we can't just wrap the generic view response
in populate_xheaders, because we don't have access to the response object
at the time at which we determine the object that is in use. It will
probably be necessary to add generic support to define headers anywhere in
the lifespan of a request, and then apply those headers when the response
is constructed; i.e., in much the same way that self.request is available
throughout the lifespan of a request, make self.response_headers available
throughout the lifespan of a request.
--
--
Ticket URL: <http://code.djangoproject.com/ticket/15741#comment:1>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
