Opened 8 years ago
Closed 8 years ago
#28081 closed Bug (fixed)
django.test.client:conditional_content_removal() is not compliant with RFC7230
Reported by: | Ed Morley | Owned by: | João Silva |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
RFC7230 section 3.3.2 says:
A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request (Section 4.1 of [RFC7232]); a server MUST NOT send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent in the payload body of a 200 (OK) response to the same request.
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [RFC7231]).
However conditional_content_removal()
sets Content-Type: 0
in these cases:
https://github.com/django/django/blob/941b8691351d4739cd9391b0a1326abd0b1c29c0/django/test/client.py#L91-L108
...which is not compliant with the specification.
The fix is to not set Content-Type
at all in conditional_content_removal()
.
Note: After #26052 conditional_content_removal()
is only used by the django.test.client
, though that caused the regression #28054, for which the fix will be making runserver use it too.
Change History (4)
comment:1 by , 8 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 8 years ago
Has patch: | set |
---|
PR