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
DNSP and caching have a very tight relation.
If caching doesn't happen, DNSP can still go through proxy and get the desired response.
Problem is, the whole process without cache is bit slower (~100 msec per request depending on remote server's presence on the internet. It means, DNS response can get up to 200 msec per request.
Itself is not an issue, but I must have messed up with Etag and other caching headers, and I can get no cache anymore on my webserver, which happens to be behind CloudFlare caching/acceleration.
Caching was OK, it has always been working on simple Apaches/NGINX.
I want and need to repair it. Having the resource correcly cached means that we do not even need to get the 304 from the remote server, we shall pop the resource from the cache, but query string sometimes doesn't play nicely with Polipo or Squid......
DNSP doesn't seem to be impacted in its core functions, and the PHP is still fast, correct, looks good.
The problem is with cache-valdity overrides done by custom CloudFlare headers. Is a common practice for CDN, but it doesn't integrate with DNSP.
Solution: strip down the headers in the dnsp.c code programmatically, and fine tune HTTP cache to accept the suggested validity (14400).
The text was updated successfully, but these errors were encountered:
i put tag question and help as cache is very susceptible to being altered ...
so far validated with:
cloudflare
google cloud (app engine)
controlling our cache (with validity and Etag headers) is super easy, 3 minutes to add it to dnsp.c
in http2/DOH the TTL is done in custom-headers OUTSIDE of Validity (wich is an HTTP notion yet, and not a DNS thingy even if very similar in this context)
fantuz
changed the title
No cache for most of HTTP 301, 304, 200. Why, when, what ?
Sometimes no-cache for HTTP 304, returns 200. Why ? headers to blame.
Mar 5, 2018
DNSP and caching have a very tight relation.
If caching doesn't happen, DNSP can still go through proxy and get the desired response.
Problem is, the whole process without cache is bit slower (~100 msec per request depending on remote server's presence on the internet. It means, DNS response can get up to 200 msec per request.
Itself is not an issue, but I must have messed up with Etag and other caching headers, and I can get no cache anymore on my webserver, which happens to be behind CloudFlare caching/acceleration.
Caching was OK, it has always been working on simple Apaches/NGINX.
I want and need to repair it. Having the resource correcly cached means that we do not even need to get the 304 from the remote server, we shall pop the resource from the cache, but query string sometimes doesn't play nicely with Polipo or Squid......
DNSP doesn't seem to be impacted in its core functions, and the PHP is still fast, correct, looks good.
The problem is with cache-valdity overrides done by custom CloudFlare headers. Is a common practice for CDN, but it doesn't integrate with DNSP.
Solution: strip down the headers in the dnsp.c code programmatically, and fine tune HTTP cache to accept the suggested validity (14400).
The text was updated successfully, but these errors were encountered: