Skip to content

multiple_choices vs multiple_choices_redirect #184

Description

@sk1p

While working on #183 and wondering why some tests take a long time, I noticed a bug in TestMultipleChoicesRedirects - the test accesses /multiple_choices_redirect/ but the SimpleApp server only defines /multiple_choices/ - so in this case, it falls back to the default 200 response in __call__. This may be hiding a real bug, I didn't really investigate further.

Maybe it would be a better idea to return a 404 or 500 error in cases of unknown URLs

Activity

  1. Nikhil172913832 commented on Jan 1, 2026

    @Nikhil172913832

    I dug a bit deeper and was able to confirm @sk1p ’s findings. The test currently hits /multiple_choices_redirect, which isn’t defined in SimpleApp and falls back to call, returning a 200 with Cache-Control: max-age=5000, so the test passes without actually exercising a 300 response. The /multiple_choices endpoint does return a 300, but without explicit freshness information, and while 300 responses are cacheable by default, CacheControl doesn’t apply heuristic freshness, so a response without explicit cache headers won’t be reused. Based on that, a possible fix would be to correct the test URL to /multiple_choices and add an explicit Cache-Control header to that endpoint, which should make the test deterministic and closer to its original intent. I might be missing something here and would appreciate any thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions