#23960 closed Cleanup/optimization (fixed)
HTTP standard no longer requires the Location header to be an absolute URI
| Reported by: | Carl Meyer | Owned by: | Claude Paroz |
|---|---|---|---|
| Component: | HTTP handling | Version: | 1.9 |
| Severity: | Normal | Keywords: | |
| Cc: | mail@… | 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
RFC 2616 required the Location header (in redirect responses) to be an absolute URI. In Django, we have django.http.utils.fix_location_header() to unconditionally ensure this.
RFC 2616 has now been superseded by RFC 7231, which allows relative URIs in Location (recognizing the actual practice of user agents, almost all of which support them): http://tools.ietf.org/html/rfc7231#section-7.1.2
We should remove django.http.utils.fix_location_header().
Since user agents almost universally allow relative Location (I'm not aware of any that don't), I don't believe this change requires a deprecation path, but it should of course be noted in the release notes.
Attachments (1)
Change History (16)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
If we were going to continue to provide support for this in Django, it seems like a built-in middleware would make more sense than a dedicated setting.
But are there really good enough reasons to be doing this server-side that there needs to be built-in support in Django?
comment:3 by , 9 years ago
I would just drop the unconditional fix and document the change in the release notes.
(In fact I consider all unconditional response_fixes to be response_breaks. We removed the two IE-specific ones in [3800f637]. I bet we'll end up removing them all.)
comment:4 by , 9 years ago
| Has patch: | set |
|---|---|
| Patch needs improvement: | set |
| Triage Stage: | Unreviewed → Accepted |
I started this, but it seems it will take more than 5 minutes as the test client currently relies on always receiving an absolute URI. I haven't looked into what's required to fix it.
by , 9 years ago
| Attachment: | 23960.diff added |
|---|
comment:5 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:7 by , 9 years ago
| Patch needs improvement: | unset |
|---|---|
| Triage Stage: | Accepted → Ready for checkin |
PR from Claude looks good.
comment:9 by , 8 years ago
| Version: | 1.7 → 1.9 |
|---|
Changing the version to "1.9", as that's the release that first contains the fix.
comment:10 by , 8 years ago
The version field usually represents the first version in which a bug is detected. It doesn't matter very much anyway.
comment:11 by , 8 years ago
| Cc: | added |
|---|
Oops, I didn't realize that. Well, since it's not really a "bug" per se, it probably won't hurt in this case :) I'll try to remember for the future though.
This was discussed on IRC I think, and Matt Robenolt drafted a patch using a setting to control the behavior -- not sure the justification for doing that over just dropping it as you've proposed.