Cache Deserialization (part two) -- warning message incorrect?
Personne n'a encore pris cette issue.
- #434 par @Adichapati — fermée sans fusion
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 65/100
Piste de recherche
Commencez par l’avertissement dans cachecontrol/controller.py:147 et la comparaison des en-têtes dans cachecontrol/serialize.py:115-119. Reproduisez des requêtes répétées avec un Bearer token modifié et examinez le comportement du cache qui en résulte. Le travail est terminé lorsque l’avertissement distingue correctement une discordance d’en-tête ou une invalidation du cache d’un échec de désérialisation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
This is related to #148 - but I would prefer not to necro. I'm seeing this repeatedly when I make the same request over and over again. I'll detail everything I'm using right now.
(stare) $ python --version
Python 3.7.3
(stare) $ pip --version
pip 19.2.3 from /Users/kratsg/.virtualenvs/stare/lib/python3.7/site-packages/pip (python 3.7)
Package Version Location
------------------- --------- -----------------------
appdirs 1.4.3
aspy.yaml 1.3.0
atomicwrites 1.3.0
attrs 19.1.0
bandit 1.6.2
betamax 0.8.1
betamax-serializers 0.2.1
black 19.3b0
bleach 3.1.0
bumpversion 0.5.3
CacheControl 0.12.5
certifi 2019.6.16
cfgv 2.0.1
chardet 3.0.4
Click 7.0
coverage 4.5.4
docutils 0.15.2
ecdsa 0.13.2
future 0.17.1
gitdb2 2.0.5
GitPython 3.0.2
identify 1.4.6
idna 2.8
importlib-metadata 0.19
lockfile 0.12.2
more-itertools 7.2.0
msgpack 0.6.1
nodeenv 1.3.3
packaging 19.1
pbr 5.4.2
pip 19.2.3
pkginfo 1.5.0.1
pluggy 0.12.0
pre-commit 1.18.2
py 1.8.0
pyasn1 0.4.6
pyflakes 2.1.1
Pygments 2.4.2
pyparsing 2.4.2
pytest 5.1.1
pytest-cov 2.7.1
pytest-mock 1.10.4
python-dotenv 0.10.3
python-jose 3.0.1
PyYAML 5.1.2
readme-renderer 24.0
requests 2.22.0
requests-toolbelt 0.9.1
rsa 4.0
setuptools 41.2.0
six 1.12.0
smmap2 2.0.5
stare 0.0.2 /Users/kratsg/stare/src
stevedore 1.30.1
toml 0.10.0
tqdm 4.35.0
twine 1.13.0
urllib3 1.25.3
virtualenv 16.7.4
wcwidth 0.1.7
webencodings 0.5.1
wheel 0.33.6
zipp 0.6.0
Whenever I make the same request over and over (no warning the first time when there's no cache) but on subsequent requests, I get a warning...
cache entry deserialization failed, entry ignored (controller.py:147)
which indicates this line here: https://github.com/ionrock/cachecontrol/blob/0234b80/cachecontrol/controller.py#L147
So I'm going manually through the steps to find where the crash/error is. I see that we're using v4 so msgpack is being used:
>>> from cachecontrol.serialize import Serializer
>>> s = Serializer()
>>> data = open('.webcache/6/0/a/6/d/60a6d7942f39f888d6dc7b3a89964aea0a63c8f708eef2bdefd601be', 'rb').read()
>>> s.loads('', data)
No error there, so digging in more (given that there's no error on the empty request, I suspect it is not related to the cache but to the request itself...). So reverse-engineering what serialize.py is doing:
>>> ver, data = data.split(b",", 1)
>>> ver
b'cc=4'
>>> ver = ver.split(b"=", 1)[-1].decode("ascii")
>>> ver
'4'
>>> cached = msgpack.loads(data, raw=False)
>>> cached
{'response': {'body': b'<body suppressed for now>', 'headers': {'Date': 'Tue, 27 Aug 2019 14:51:20 GMT', 'Server': 'Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16', 'Vary': 'Authorization,Accept-Encoding,User-Agent', 'X-Powered-By': 'PHP/5.4.16', 'Set-Cookie': 'PHPSESSID=<COOKIE>; path=/', 'Expires': 'Thu, 19 Nov 1981 08:52:00 GMT', 'Cache-Control': 'private', 'Pragma': 'no-cache', 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Headers': 'API-KEY, Authorization', 'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE', 'Content-Encoding': 'gzip', 'Content-Length': '45806', 'Keep-Alive': 'timeout=5, max=100', 'Connection': 'Keep-Alive', 'Content-Type': 'application/json'}, 'status': 200, 'version': 11, 'reason': 'OK', 'strict': 0, 'decode_content': False}, 'vary': {'Authorization': 'Bearer <BEARER TOKEN>', 'Accept-Encoding': 'gzip, deflate', 'User-Agent': 'python-requests/2.22.0'}}
So now I prep a request to compare against to see how cachecontrol works in the prepare_response section
To do this part, I just insert pdb into the relevant section and just evaluate specific lines, but I found out that the problem is that the headers didn't match (and in fact, I'm making different requests since the Bearer Token changed between requests when I submit repeatedly since I'm not caching the access tokens).
https://github.com/ionrock/cachecontrol/blob/0234b80/cachecontrol/serialize.py#L115-L119
So what ends up happening, to me, is that the warning message being spit out is not very clear at all. In fact, it just (in this case) means that the headers didn't match -- so the cache should be rebuilt. That is cache deserialization did not fail.
- Langage dominant
- Python
- Étoiles
- 505
- Forks
- 156
- Merge moyen
- 5 j 37 min
- PR mergées (30 j)
- 2
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de psf/cachecontrol
-
Race condition in send()Peut-être pris @JulienPalard l’a pris il y a 159 jours. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
psf/cachecontrol#424 · 1 commentaire ·
-
HTTP 302 Found responses with Cache Headers not being cachedPeut-être pris @cburroughs l’a pris il y a 291 jours. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 42/100
psf/cachecontrol#384 · 18 commentaires ·
-
Head request is not cached even with cacheable_methods=("GET", HEAD") without a previous GETPeut-être à nouveau libre Une pull request pour cette issue a été fermée sans être fusionnée. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
psf/cachecontrol#337 · 6 commentaires ·
-
Investigate failure to load caches above `2^32 - 1` bytesPeut-être à nouveau libre @woodruffw l’a pris il y a 864 jours, et aucune pull request n’est ouverte. Ouverte
psf/cachecontrol#336 · 4 commentaires · 1 réaction · 1 personne assignée ·
-
The new SeparateBodyFileCache design makes updates/reads non-atomicPeut-être à nouveau libre Une pull request pour cette issue a été fermée sans être fusionnée. Ouvertebug
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 28/100
psf/cachecontrol#324 · 4 commentaires ·
Toutes les issues de psf/cachecontrol
Issues similaires
-
intake mcp-intake needs-ac needs-human-review priority:medium
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
Ikalus1988/MisakaNet#3848 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
521xueweihan/HelloGitHub#4105 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
igormcsouza/bookloud#54 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
aws-samples/sample-per-model-bedrock#526 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
ok-oldking/ok-wuthering-waves#1802 ·
Les mainteneurs répondent en général sous 2 jours