You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The workaround is to delete the database and resync (lots of data and several days. Difficult to do "offline")
My best guess to a root cause is trying to use a wifi hotspot (e.g. Starbucks) before "accepting" the TOS.
When local-npm makes a request, DNS is hijacked by the router which responds with something other than the file (e.g. a login page). This "fake" version seems to be cached as local-npm continues serving this error even after the hotspot TOS is accepted. This is my best guess.
The fix would be to discard the fake cached version, so local-npm could re-GET the original.
A warning message could be shown and the response not cached if the response is missing the expected headers (see @gabrielcsapo's suggestion).
@gabrielcsapo: @MichaelJCole if you could open a new issue we can track the bug there. We would need to be able to reproduce that problem and determine if we can use headers the client sends to the server to resolve cache problems @gabrielcsapo: @MichaelJCole this also a flaw in the caching as it does inspect the headers to validate source
The text was updated successfully, but these errors were encountered:
MichaelJCole
changed the title
Discard cache if invalid. Check source before caching.
Discard cache if hash is invalid. Check response headers before caching.
Sep 19, 2017
Hi there,
This bug is related to: #84
The error symptom is:
GET http://127.0.0.1:5080/tarballs/base64id/0.1.0.tgz -> {"error":"hashes don't match, not returning"}
The expected state is:
GET http://127.0.0.1:5080/tarballs/base64id/1.0.0.tgz -> (downloads tgz)
The workaround is to delete the database and resync (lots of data and several days. Difficult to do "offline")
My best guess to a root cause is trying to use a wifi hotspot (e.g. Starbucks) before "accepting" the TOS.
When local-npm makes a request, DNS is hijacked by the router which responds with something other than the file (e.g. a login page). This "fake" version seems to be cached as local-npm continues serving this error even after the hotspot TOS is accepted. This is my best guess.
The fix would be to discard the fake cached version, so local-npm could re-GET the original.
A warning message could be shown and the response not cached if the response is missing the expected headers (see @gabrielcsapo's suggestion).
The text was updated successfully, but these errors were encountered: