#26052 closed Cleanup/optimization (fixed)
Consider removing conditional_content_removal
Reported by: | Aymeric Augustin | Owned by: | Susan Tan |
---|---|---|---|
Component: | HTTP handling | Version: | 1.9 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
It's the last survivor of the "response_fixes" and I think it should go away. Its origin is #5898.
Graham Dumpleton has described better than I would why frameworks should leave the task stripping the body of HEAD requests to servers: http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html (first five paragraphs).
We should check whether mod_wsgi, gunicorn and uwsgi properly strip the body of HEAD requests before proceeding. We should also move that behavior into runserver -- that is, on the other side of the WSGI.
Change History (15)
comment:1 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 9 years ago
Patch needs improvement: | set |
---|
I think the PR needs improvement as described in the ticket description, "mod_wsgi, gunicorn and uwsgi properly strip the body of HEAD requests before proceeding. We should also move that behavior into runserver
."
comment:6 by , 9 years ago
Description: | modified (diff) |
---|
I observed that gunicorn and runserver (based on Python's server) don't send content for HEAD requests. I didn't check mod_wsgi or uwsgi since they are marginally more complicated to setup a test project. If we go ahead and remove this, one place where developers might see a difference would be in the test client. Do you think it's worth trying to keep it in that context? I lean toward simply removing it and reacting if anyone complains.
comment:7 by , 9 years ago
Some data about the rest of the behavior of conditional_content_removal
(discarding the content of responses with 1xx, 204, and 304 status codes):
Python's BaseHTTPRequestHandler
(which runserver
uses) also has discards the response content for 204 and 304 status codes. I observed the same behavior from gunicorn as well.
I also don't get any response data on HTTP 1xx responses regardless of whether or not conditional_content_removal
is active.
comment:8 by , 9 years ago
I tested the HEAD behaviour of mod_wsgi without conditional_content_removal
and confirms it strips the content.
If it's not too hard to simulate this behavior in the test client, I think we should do it at that level.
comment:9 by , 9 years ago
Patch needs improvement: | unset |
---|
Okay, here's a PR based on that suggestion.
comment:10 by , 9 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
follow-up: 12 comment:11 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In bb0b4b70:
comment:12 by , 8 years ago
Tim,
I think that some documentation might need a little rewording after this change:
https://github.com/django/django/blob/bb0b4b7/docs/topics/http/decorators.txt#L47-L52
comment:13 by , 8 years ago
Thanks for pointing that out. I think we could replace "Django will automatically" with "Most web servers" or "Web servers should". Did you have anything else in mind?
comment:15 by , 8 years ago
Python's BaseHTTPRequestHandler (which runserver uses) also has discards the response content for 204 and 304 status codes
Unfortunately the linked BaseHTTPRequestHandler
handling appears to just be for error conditions (send_error()
) so this change caused runserver.py to start returning a body for HTTP 200 HEAD requests.
I've filed #28054.
I would like to work on this ticket. Can anyone please guide me exactly what changes would be required in the code.
Thanks