Opened 11 years ago
Closed 10 years ago
#21483 closed New feature (fixed)
[RFE] Add WSGI environ to request_started signal emission
Reported by: | Owned by: | anonymous | |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
As written, the request_started signal cannot take into account any of the specifics of the aforementioned request in a connected handler. The signal provided args should add the WSGI environ to the emitted signal to allow connected handlers to act related to the request's context.
Pull request provided here: https://github.com/django/django/pull/1951
Change History (7)
comment:1 by , 11 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
I'm wondering if whatever you're planning to do in the signal receiver wouldn't be better implemented in a middleware.
But maybe that's just my phobia of signals :)
comment:5 by , 11 years ago
For many (most?) cases, I'd agree with you - middleware has that explicitness, where as signals are automated magic. However the signal is the absolute earliest place to modify the handling of a request - for cases where middleware may even be too late, doing work with a signal handler could be the best option.
comment:6 by , 10 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Patch needs improvement: | set |
I left comments for improvement on the PR. Please uncheck "Patch needs improvement" when you update it, thanks.
comment:7 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Suggestions noted on the PR! Assign this ticket to yourself if you are planning to work on it ;-)