Opened 4 years ago

Closed 4 years ago

#16805 closed Bug (needsinfo)

Flatpages middleware does not alter status_code back to 200

Reported by: iElectric Owned by: nobody
Component: contrib.flatpages Version: 1.3
Severity: Normal Keywords: flatpages
Cc: domen@…, taavi223 Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Problem:

Middlewares in the stack have no information if a flatpage was picked or not by the FlatpageFallbackMiddleware. Even more, flatpages pass response.status_code == 400 even if flatpages view returned successfully.

Impact:

Solution:

If we find a flatpage from the view, change back response.status_code to 200.

Tests:

There are no tests for flatpages.

Attachments (1)

flatpages_modify_status_code.patch (973 bytes) - added by iElectric 4 years ago.
set status_code to 200 if flatpage was found

Download all attachments as: .zip

Change History (4)

comment:1 Changed 4 years ago by taavi223

  • Cc taavi223 added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

I just tested this on my computer and am not seeing the same behavior. My flatpages are being returned to my browser with a 200 status code. Where/how did you check the status code of the response? In your python code, or in your browser?

Also, just so you know, your patch isn't going to solve the problem you're seeing, since the line you added will never be executed. Either the line above it will return and end the function, or the line above it will throw an error and the function will skip ahead to the error clause.

If you're still seeing this error, try starting a brand new django project and only setting up flatpages to see if the error still occurs. It seems to me that this could possibly be a problem with a different component. Feel free to reopen this ticket, but make sure to include more information on your setup so that we can reproduce it.

comment:2 follow-up: Changed 4 years ago by iElectric

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Impact:

When using django-sentry, it relies on the response.status_code setting. Because flatpages does not modify attribute to 200 when flatpage is found, django-sentry has no information if flatpage was found or 404 is really present.

I have corrected the patch.

Changed 4 years ago by iElectric

set status_code to 200 if flatpage was found

comment:3 in reply to: ↑ 2 Changed 4 years ago by taavi223

  • Resolution set to needsinfo
  • Status changed from reopened to closed

Replying to iElectric:

Impact:

When using django-sentry, it relies on the response.status_code setting. Because flatpages does not modify attribute to 200 when flatpage is found, django-sentry has no information if flatpage was found or 404 is really present.

I have corrected the patch.

I don't have django-sentry installed, so I can't test that part of this equation. But for me, *all* flatpage responses have a 200 status code. When a flatpage is found for a URL, it generates an entirely new response object (which defaults to a 200 status code) and throws away the old response object with the 404 status code. Have you checked in the browser itself to see what status code is being returned?

Please include more information about your setup so that we can try to replicate this bug.

Note: See TracTickets for help on using tickets.
Back to Top