Merge lp://staging/~mhall119/developer-ubuntu-com/cache-cooke-fix into lp://staging/developer-ubuntu-com
Proposed by
Michael Hall
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Michael Hall | ||||
| Approved revision: | 115 | ||||
| Merged at revision: | 116 | ||||
| Proposed branch: | lp://staging/~mhall119/developer-ubuntu-com/cache-cooke-fix | ||||
| Merge into: | lp://staging/developer-ubuntu-com | ||||
| Diff against target: |
14 lines (+4/-0) 1 file modified
developer_portal/middleware.py (+4/-0) |
||||
| To merge this branch: | bzr merge lp://staging/~mhall119/developer-ubuntu-com/cache-cooke-fix | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Nicholas Skaggs (community) | Approve | ||
| Ubuntu App Developer site developers | Pending | ||
|
Review via email:
|
|||
Commit message
changes the cache-friendly middleware to only strip out session cookies when the user is not logged in *and* when it's a 200 status code.
Description of the change
In order to facilitate caching in China, we strip out session cookies for not logged in requests. However, in situations where there is a 404, 500, or other non-success status code, the Django response does not include the logged in user object, which would cause those logged in user to have their session cookie removed, effectively logging them out.
This changes the cache-friendly middleware to only strip out session cookies when the user is not logged in *and* when it's a 200 status code.
To post a comment you must log in.
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
+1, this will ensure we only change the response on non-200 status pages. Regarding other codes:
<balloons> mhall119, what about other codes.. so we be explicit instead of implicit? I'm curious about redirects for instance
<mhall119> redirects didn't seem to be a problem
<mhall119> but there's no real reason to share cached responses other than 200
<mhall119> and as far as I know, those are always guaranteed to have a user object associated with them when the user is logged in