[GitHub] trafficserver issue #1626: enable proxy.config.http.negative_revalidating_en...
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/issues/1626 Don't get this sentence: > If it is enabled, than caching the negative response, the current (possibly stale) content is preserved and served. I think this should only be in play for stale content -- wouldn't be revalidating fresh content, right? Perhaps If it is enabled, rather than caching the negative response, the current stale content is preserved and served. > If the origin provides a valid response that is not considered a failure in this context. Perhaps missing a comma after response? Would a 5xx error be considered a valid response? We use cache hierarchies extensively, and this setting kicks in when our parents return a 5xx error to the children. Perhaps 'a valid response specific to the object'? proxy.config.http.negative_revalidating_lifetime appears to be both reloadable and overridable. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1626: enable proxy.config.http.negative_revalidating_en...
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/issues/1626 How about if I add: That is, when enabled, |TS| will serve stale when it can not reach the origin server (similar to the stale-if-error Cache-Control directive). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1626: enable proxy.config.http.negative_revalidating_en...
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1626 enable proxy.config.http.negative_revalidating_enabled by default I think we should enable [proxy.config.http.negative_revalidating_enabled](https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy-config-http-negative-revalidating-enabled) by default in ATS 8. This config allows ATS to serve stale when it cannot reach the origin. With the current settings the client receives 502s. The config is overridable. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1575: 5xx response instead of stale content
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/issues/1575 This is proxy.config.http.negative_revalidating_enabled which is disabled by default. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1575: 5xx response instead of stale content
Github user mlibbey closed the issue at: https://github.com/apache/trafficserver/issues/1575 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1602: proxy.config.ssl.server.multicert.exit_on_load_fa...
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1602 proxy.config.ssl.server.multicert.exit_on_load_fail not documented Not sure when proxy.config.ssl.server.multicert.exit_on_load_fail was added, but its not documented. What does it do? Is it reloadable? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1584: More detailed 5xx errors
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1584 More detailed 5xx errors Cloudflare has made some very useful 5xx errors for troubleshooting. From wikipedia: - 520 Unknown Error: The 520 error is used as a "catch-all response for when the origin server returns something unexpected", listing connection resets, large headers, and empty or invalid responses as common triggers. - 521 Web Server Is Down: The origin server has refused the connection from Cloudflare. - 522 Connection Timed Out: Cloudflare could not negotiate a TCP handshake with the origin server. - 523 Origin Is Unreachable: Cloudflare could not reach the origin server; for example, if the DNS records for the origin server are incorrect. - 524 A Timeout Occurred:Cloudflare was able to complete a TCP connection to the origin server, but did not receive a timely HTTP response. - 525 SSL Handshake Failed: Cloudflare could not negotiate a SSL/TLS handshake with the origin server. - 526 Invalid SSL Certificate: Cloudflare could not validate the SSL/TLS certificate that the origin server presented. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1575: 5xx response instead of stale content
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/issues/1575 - in whatever fix we do, should make sure that the CC:must-revalidate does return the 5xx error (eg, the must-revalidate does not allow for serving stale --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1575: 5xx response instead of stale content
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1575 5xx response instead of stale content Stale content should be used when available over general transient errors. However, once ATS gets a 5xx error, it will return the 5xx to the user instead of stale content. To reproduce: - set up ats and an origin - get an object cached. Wait for the object to expire Then perform these tests: 1) serve stale with origin unavailable: - fetch the object. - you will (and should) get the stale object. This is expected and desired behavior ð 2) 5xx error case: - have the origin respond 502/504 (like a parent)... for the object - fetch the object-- you will get a 502-- you should get the stale object - turn off the origin and refetch-- you will still get the 502. In these cases the via header will report hit-stale, so the object is still in cache, just isn't served. We expect a stale object instead of the transient error. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1553: Consistent hashing in parent.config can use subop...
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1553 Consistent hashing in parent.config can use suboptimal URL for hash (was TS-4025 https://issues.apache.org/jira/browse/TS-4025) -- original description: In a setup, where the same assets can have different URLs (e.g. query parameters, or two paths normalized to the same cache key), parent proxy can be suboptimal. This is TS-4020, and the solutions would be similar; Use the cache key (CacheInfo->md5) which is internally what we call LookupURL. LookupURL is that URL that plugins modify to change the cache key. This has to be rolled out carefully as well, we're thinking something like 6.x - We add a new configuration, that lets you use the LookupURL for the hash (default off) 7.x - We change this new configuration to be enabled by default 8.x - We remove this configuration. This Jira tracks the first step, we'll file subsequent Jira's for 7.x and 8.x. -- This is still important to us. We frequently use the cachekey plugin to modify query parameters, the hostname, etc. However, the parent choice is equally important. If we choose the 'wrong parent', the request goes to a parent that has not seen the request before, the effect is the same as an inconsistent cachekey. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1534: Use StringView for protocol stack to avoid callin...
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/pull/1534 I'm terrible at reading RFC docs, so, fwiw, the Via header structure is described here: https://tools.ietf.org/html/rfc7230#section-5.7.1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1505: Set proxy.node.config.reconfigure_time when remap...
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/issues/1505 Sure... then set at every place that has the config atomic swap, call some function whose job is to set the proxy.node.config.reconfigure_time ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1505: Set proxy.node.config.reconfigure_time when remap...
GitHub user mlibbey opened an issue: https://github.com/apache/trafficserver/issues/1505 Set proxy.node.config.reconfigure_time when remap.config done reloading. In ATS7, we have a messages line that notes, "remap.config done reloading!", when reload is finished (in proxy/ReverseProxy.cc, reloadUrlRewrite()). We should set the proxy.node.config.reconfigure_time stat here too -- it currently has the time of the reload request, as opposed to the time of the reload request finish. The former does not allow one to correlate behavior with a config change -- there is an unknown time delta between the event and the load. Similarly, the former happens regardless of the success of the reload. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #821: TS-4678 Promotes a few plugins to stable
Github user mlibbey commented on the issue: https://github.com/apache/trafficserver/pull/821 Think we need trafficserver/doc/admin-guide/plugins/index.en.rst changes too? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
