Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] (Tracking only) Reduce interface of cachecontrol, and make more reliable. #225

Closed
wants to merge 19 commits into from

Conversation

Flameeyes
Copy link
Contributor

This includes the heavy-lifting changes that I don't feel are ready for actual review yet.

The new status code was introduced with RFC 7538 in April 2015.

This makes it so that "308 Permanent Redirect" status codes are treated the
same as "301 Moved Permanently" statuses.
This makes it easier to figure out _why_ something fails to look up altogether.
When caching permanent redirects, if `body` is left to `None`, there's an infinite recursion that will lead to the caching to silently fail and not cache anything at all.

So instead, make `body` a required parameter, which can be empty (`''`) for cached redirects.
This is to workaround an isort bug that appears fixed in master, where the Transfer-Encoding: chunked line is interpreted as an encoding for the file.
This includes isort, black and some basic hygiene on text files.
This is a fairly common unix extension for backup files used at least by Emacsen and vim.
This would be a bit less efficient in Python 2.7, but it would work on Python 3.x.
This makes it easier to use constants for status codes as well.
This is just a matter of cleanup, I can't think of any good reason for this
_not_ to be marked abstract.
This is a bit more nuanced in Python 3, where only EEXIST errors are
suppressed, to match the `delete` codepath.
These heuristics disagree with RFC7234, and while there's no reason to
stick to their implementation, they seem to be more ill-suited than the
default 10%-since-last-modification.
The way this is set up in the module appears to go contrary to RFC7234 by
expecting it to be used for validation purposes:
https://httpwg.org/specs/rfc7234.html#validation.sent
This includes a "policy" module that includes functions to answer policy
decisions on whether to use the cache, whether to cache a certain response,
and whether to consider a response fresh.

Note that this relies on a full-fledged Cache-Control parser that uses the
abnf module, which is Python 3 only.
@frostming
Copy link
Contributor

frostming commented May 30, 2023

Please adapt the code to the latest master branch and send another PR if necessary.

@frostming frostming closed this May 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants