Opened 9 years ago
Closed 9 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 , 9 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 9 years ago
| Has patch: | set |
|---|
PR