From lagged at gmail.com Sat Sep 2 20:15:28 2017 From: lagged at gmail.com (Andrei) Date: Sat, 2 Sep 2017 15:15:28 -0500 Subject: Hit idle send timeout Message-ID: Hello everyone, I'm running 4.1.8 as a frontend to a local Apache 2.4 and just recently ran into a burst of the following "idle/write errors" without any corresponding errors logged in Apache. Any suggestions on what to keep an eye on or further review would be greatly appreciated. * << Request >> 482784125 - Begin req 482784124 rxreq - Timestamp Start: 1504382885.868717 0.000000 0.000000 - Timestamp Req: 1504382885.868717 0.000000 0.000000 - ReqStart [redacted.xfwd2IP] 35207 - ReqMethod GET - ReqURL /[redacted.url]/ - ReqProtocol HTTP/1.1 - ReqHeader Host: www.[redacted.domain.tld] - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G920F Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 Mobile Safari/537.36 - ReqHeader Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 - ReqHeader Accept-Language: ro-RO,ro;q=0.8,en-US;q=0.6,en;q=0.4 - ReqHeader Cf-Connecting-Ip: [redacted.xfwd1IP] - ReqHeader Cf-Ipcountry: RO - ReqHeader Cf-Origin-Https: off - ReqHeader Cf-Ray: 3983196ce0b87ea0-BUD - ReqHeader Cf-Visitor: {"scheme":"http"} - ReqHeader Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C34%2C11%7C35 - ReqHeader Referer: https://www.google.ro/ - ReqHeader Upgrade-Insecure-Requests: 1 - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] - ReqHeader X-Forwarded-Proto: http - ReqHeader Accept-Encoding: gzip - ReqHeader Connection: close - ReqUnset X-Forwarded-For: [redacted.xfwd1IP] - ReqHeader X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] - VCL_call RECV - VCL_acl MATCH cloudflare "172.64.0.0/13" - ReqHeader X-Country: RO - ReqHeader ignore_becache: 1 - ReqUnset Host: www.[redacted.domain.tld] - ReqHeader Host: www.[redacted.domain.tld] - ReqUnset X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] - ReqHeader X-Forwarded-For-Src: CloudFlare - ReqHeader X-Real-IP: [redacted.xfwd1IP] - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] - ReqHeader X-Client: [redacted.xfwd2IP] - VCL_acl NO_MATCH facebook - ReqUnset X-Forwarded-Proto: http - ReqHeader X-Forwarded-Proto: http - ReqHeader X-Forwarded-HTTPS: off - ReqHeader X-Port: 80 - ReqHeader X-Forwarded-Port: 80 - ReqHeader X-HTTPS: off - VCL_acl NO_MATCH global_blacklist - VCL_acl NO_MATCH tor_blacklist - ReqHeader X-UA-Device: pc - ReqUnset X-UA-Device: pc - ReqHeader X-UA-Device: mobile-android - ReqHeader X-My-Purge-Key: [redacted] - ReqHeader X-Purge-Key-Auth: false - ReqURL /[redacted.url]/ - VCL_Log COOKIESTRIP:/[redacted.url]/ - ReqUnset Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C34%2C11%7C35 - ReqHeader allow_override: enabled - ReqUnset Accept-Encoding: gzip - ReqHeader Accept-Encoding: gzip - ReqHeader Surrogate-Capability: key=ESI/1.0 - ReqUnset X-My-Purge-Key: [redacted] - ReqHeader X-TTL: 14400.000 - ReqHeader X-Cacheable: YES:Dynamic cache, ttl: 14400.000 - ReqHeader X-Req-Type: Cache:Dynamic - VCL_return hash - VCL_call HASH - ReqHeader hash: /[redacted.url]/ - ReqUnset hash: /[redacted.url]/ - ReqHeader hash: www.[redacted.domain.tld]#/[redacted.url]/ - ReqUnset hash: www.[redacted.domain.tld]#/[redacted.url]/ - ReqHeader hash: http#mobile-android#www.[redacted.domain.tld]#/[redacted.url]/ - VCL_return lookup - Hit 482125483 - VCL_call HIT - VCL_Log OKHITDELIVER: obj.ttl:14065.370 obj.keep: 0.000 obj.grace: 21600.000 - VCL_return deliver - RespProtocol HTTP/1.1 - RespStatus 200 - RespReason OK - RespHeader Date: Sat, 02 Sep 2017 20:02:30 GMT - RespHeader x-frame-options: SAMEORIGIN - RespHeader X-XSS-Protection: 1; mode=block - RespHeader X-Content-Type-Options: nosniff - RespHeader X-Pingback: http://www.[redacted.domain.tld]/xmlrpc.php - RespHeader Link: ; rel=shortlink - RespHeader Content-Type: text/html; charset=UTF-8 - RespHeader X-Req-Type: Cache:Dynamic - RespHeader Accept-Encoding: gzip - RespHeader Vary: Accept-Encoding, X-UA-Device - RespHeader X-UA-Device: mobile-android - RespHeader X-Req-Host: www.[redacted.domain.tld] - RespHeader X-Req-URL: /[redacted.url]/ - RespHeader X-Req-URL-Base: /[redacted.url]/ - RespHeader X-TTL: 14400.000 - RespHeader X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 - RespHeader X-Varnish: 482784125 482125483 - RespHeader Age: 334 - RespHeader Via: 1.1 varnish-v4 - VCL_call DELIVER - RespHeader X-Cache: HIT - VCL_Log OKHITDELIVERY: obj.hits: 1 ttl:14400.000 - RespUnset X-Req-Type: Cache:Dynamic - RespUnset Age: 334 - RespUnset X-Cache: HIT - RespUnset X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 - RespUnset X-TTL: 14400.000 - RespUnset X-Req-Host: www.[redacted.domain.tld] - RespUnset X-Req-URL: /[redacted.url]/ - RespUnset X-Req-URL-Base: /[redacted.url]/ - RespUnset X-Varnish: 482784125 482125483 - RespUnset Via: 1.1 varnish-v4 - RespUnset X-UA-Device: mobile-android - VCL_return deliver - Timestamp Process: 1504382885.868905 0.000188 0.000188 - RespHeader Accept-Ranges: bytes - RespHeader Content-Length: 63072 - Debug "RES_MODE 2" - RespHeader Connection: close - Debug "Hit idle send timeout, wrote = 55480/63504; retrying" - Debug "Write error, retval = -1, len = 8024, errno = Broken pipe" - Timestamp Resp: 1504382886.049021 0.180304 0.180115 - ReqAcct 869 0 869 432 63072 63504 - End -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.hanesse at gmail.com Mon Sep 4 12:12:20 2017 From: olivier.hanesse at gmail.com (Olivier Hanesse) Date: Mon, 4 Sep 2017 14:12:20 +0200 Subject: Varnish Lurker is getting slower / Ban lists keeps increasing In-Reply-To: References: <12ca81a6-44fa-bfa0-046d-b051cabc92b6@schokola.de> Message-ID: Hello, I got some news about this issue : The "MAIN.bans_lurker_obj_killed_cutoff" value has increased from 0 to "322451" in one update ! (i am polling this value every minute). The ban list size was around 100k when this has happened. And I can see at the same time, a drop of the "n_object" value (this is normal and expected). Are the stats used by varnishstat about the lurker "well" updated "every minute" ? The fact that the statistics was only updated once is kinda strange : the ban list size is higher than the cutoff value everyday :( Regards Olivier 2017-08-30 15:41 GMT+02:00 Olivier Hanesse : > Ok, so I could upgrade the cutoff parameter to 70K (bans_lurker_tests_tested > is around 1.4M) > > I will keep it at 18500 to debug this ban list behaviour. > > 2017-08-30 15:14 GMT+02:00 Nils Goroll : > >> >> On 30/08/17 11:44, Olivier Hanesse wrote: >> > 50ms of latency, 370K/s ban.lurker.tested >> >> BTW, the value to be used for the calculation is >> rate(bans_lurker_tests_tested) >> not rate(bans_lurker_tested) >> >> I've also just improved the documentation of ban_cutoff in master. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Sep 4 14:11:02 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 4 Sep 2017 16:11:02 +0200 Subject: Varnish Lurker is getting slower / Ban lists keeps increasing In-Reply-To: References: <12ca81a6-44fa-bfa0-046d-b051cabc92b6@schokola.de> Message-ID: On Mon, Sep 4, 2017 at 2:12 PM, Olivier Hanesse wrote: > Are the stats used by varnishstat about the lurker "well" updated "every minute" ? The fact that the statistics was only updated once is kinda strange : the ban list size is higher than the cutoff value everyday :( No, that's a limitation of the statistics, serving HTTP traffic has higher priority than committing updates of the counters. See this for reference: https://github.com/varnishcache/varnish-cache/pull/2290 Dridi From olivier.hanesse at gmail.com Mon Sep 4 14:54:24 2017 From: olivier.hanesse at gmail.com (Olivier Hanesse) Date: Mon, 4 Sep 2017 16:54:24 +0200 Subject: Varnish Lurker is getting slower / Ban lists keeps increasing In-Reply-To: References: <12ca81a6-44fa-bfa0-046d-b051cabc92b6@schokola.de> Message-ID: In this case, that means that as long as the ban lurker is working, no statistics are updated right ? So if I don't see any updates of statistics such as "bans_deleted", or "bans_lurker_obj_killed_cutoff" during a long period, it doesn't mean that the lurker is sleeping, hanged or waiting for a lock, it means that the lurker worker is working pretty "hard", is that correct ? 2017-09-04 16:11 GMT+02:00 Dridi Boukelmoune : > On Mon, Sep 4, 2017 at 2:12 PM, Olivier Hanesse > wrote: > > Are the stats used by varnishstat about the lurker "well" updated "every > minute" ? The fact that the statistics was only updated once is kinda > strange : the ban list size is higher than the cutoff value everyday :( > > No, that's a limitation of the statistics, serving HTTP traffic has > higher priority than committing updates of the counters. > > See this for reference: > > https://github.com/varnishcache/varnish-cache/pull/2290 > > Dridi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info+varnish at shee.org Thu Sep 7 15:10:07 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Thu, 7 Sep 2017 17:10:07 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> Message-ID: Hi, a bit latency caused by vacation. Am 21.07.2017 um 09:53 schrieb Guillaume Quintard : > > Don't pipe. ever. Unless your are using websockets. Okay, I tried just to delete "req.http.cookie" or return(pass) both do not help here. > do_stream is set by default, you can remove it. Okay, thanks to clarify it. > Are we talking aboud VoD or Live? if the latter, remember to set grace to 0, other you'll have outdated manifest problems. VoD - plain mp4 files. > What isn't working on Safari? Does the problem goes away if you connect straight to the origin? (ie. no varnish) Test scenario: just GET the mp4 file and play it in the browser (HTML5). Connecting straight to the backend (via SSH tunnel): File size 7081786 test.mp4 $ curl -s -I localhost:8080/test.mp4 HTTP/1.1 200 OK Date: Thu, 07 Sep 2017 14:48:14 GMT Server: Apache ETag: "6c0f3a-55899f81639c0" Accept-Ranges: bytes Content-Length: 7081786 Cache-Control: max-age=28800 Expires: Thu, 07 Sep 2017 22:48:14 GMT X-Frame-Options: SAMEORIGIN Content-Type: video/mp4 Safari loads the file (progress bar shows up) and autoplays it directly: Webserver log: - - - [07/Sep/2017:16:08:09 +0200] "GET /test.mp4 HTTP/1.1" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" - - - [07/Sep/2017:16:08:11 +0200] "GET /test.mp4 HTTP/1.1" 206 2 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" - - - [07/Sep/2017:16:08:11 +0200] "GET /test.mp4 HTTP/1.1" 206 7081786 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" - - - [07/Sep/2017:16:08:13 +0200] "GET /test.mp4 HTTP/1.1" 206 6669784 "http://localhost:8080/test.mp4" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" Connecting through varnish with return(pass): curl -s -I https://www.DOMAIN.org/test.mp4 | grep -v -E "key-pins|access-control|strict" HTTP/2 200 date: Thu, 07 Sep 2017 14:48:59 GMT etag: "6c0f3a-55899f81639c0" accept-ranges: bytes content-length: 7081786 cache-control: max-age=28800 expires: Thu, 07 Sep 2017 22:48:59 GMT x-frame-options: SAMEORIGIN content-type: video/mp4 x-varnish: 10 age: 0 via: 1.1 Cache Safari starts to loading the file, progressbar does not shows any progress and video does not get autoplayed: Varnish log: IP - - [07/Sep/2017:16:12:04 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 2 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:04 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3076986 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:07 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3142462 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:12 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:03 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:58 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3207941 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:11 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 3989392 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:14:13 +0200] "GET http://www.DOMAIN.org/test.mp4 HTTP/2.0" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" Webserver log: IP - - [07/Sep/2017:16:12:03 +0200] "GET /test.mp4 HTTP/1.1" 200 7081786 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:04 +0200] "GET /test.mp4 HTTP/1.1" 206 2 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:04 +0200] "GET /test.mp4 HTTP/1.1" 206 7081786 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:12:07 +0200] "GET /test.mp4 HTTP/1.1" 206 7049018 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:11 +0200] "GET /test.mp4 HTTP/1.1" 206 6983482 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:12 +0200] "GET /test.mp4 HTTP/1.1" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:57 +0200] "GET /test.mp4 HTTP/1.1" 206 6819642 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:13:58 +0200] "GET /test.mp4 HTTP/1.1" 206 6754106 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" IP - - [07/Sep/2017:16:14:13 +0200] "GET /test.mp4 HTTP/1.1" 206 65536 "https://www.DOMAIN.org/test," "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8" Even pressing play manually, does not shows the video fluent. Instead a part is loaded and played (e.g. 2 seconds of the video) and then the playback stops again. Sometimes I see a lot of sequent 64k-requests "GET /test.mp4 HTTP/1.1" 206 65536" while video is played partly. This happens only after a couple of time (more then 30 sec.) after the initial request. > What do the developer tools tell you? Have you looked at varnishlog? Developer tools of Safari does not tell something useful because media stuff is handled over to Quicktime ... Are there more infos catchable that I am not aware of (tools of varnish etc.)? -- Thank you, Leon From dridi at varni.sh Thu Sep 7 15:35:01 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 7 Sep 2017 17:35:01 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> Message-ID: On Thu, Sep 7, 2017 at 5:10 PM, wrote: > Safari loads the file (progress bar shows up) and autoplays it directly: > Connecting through varnish with return(pass): > Safari starts to loading the file, progressbar does not shows any progress and video does not get autoplayed: It might be a known bug when browsers ask for multiple ranges in a single request, Varnish may serve the first one, disregard the rest and think it is done, so that leaves the browser hanging waiting for the rest of the response. I think it you can work around that in VCL by detecting when you have more than one range and return a 416 response. Dridi From info+varnish at shee.org Fri Sep 8 12:55:58 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Fri, 8 Sep 2017 14:55:58 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> Message-ID: <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> Am 07.09.2017 um 17:35 schrieb Dridi Boukelmoune : > It might be a known bug when browsers ask for multiple ranges in a > single request, Varnish may serve the first one, disregard the rest > and think it is done, so that leaves the browser hanging waiting for > the rest of the response. Thanks to pointing to this direction. Looking into it I see following (trimmed): Request 1 ReqMethod GET ReqURL /test.mp4 ReqHeader range: bytes=0-1 VCL_call HIT RespStatus 200 RespReason OK RespHeader Content-Length: 7081786 VCL_return deliver RespHeader Accept-Ranges: bytes RespHeader Content-Range: bytes 0-1/7081786 RespStatus 206 RespReason Partial Content RespUnset Content-Length: 7081786 RespHeader Content-Length: 2 Request 2 ReqMethod GET ReqURL /test.mp4 ReqHeader range: bytes=65509-7081785 VCL_call HIT RespStatus 200 RespReason OK RespHeader Content-Length: 7081786 VCL_return deliver RespHeader Accept-Ranges: bytes RespHeader Content-Range: bytes 65509-7081785/7081786 RespStatus 206 RespReason Partial Content RespUnset Content-Length: 7081786 RespHeader Content-Length: 7016277 Seems to be mapped correctly, one range in one request. Also the response seems to be "valid" (adapted Content-Length). > I think it you can work around that in VCL by detecting when you have > more than one range and return a 416 response. It seems to be related to the range handling in varnish, but the problem is not clearly right now. Any other suggestions would be greatly appreciated. -- Leon From dridi at varni.sh Fri Sep 8 15:05:56 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 8 Sep 2017 17:05:56 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> Message-ID: On Fri, Sep 8, 2017 at 2:55 PM, wrote: > Thanks to pointing to this direction. Looking into it I see following (trimmed): > > Request 1 > ReqMethod GET > ReqURL /test.mp4 > ReqHeader range: bytes=0-1 > > VCL_call HIT > RespStatus 200 > RespReason OK > RespHeader Content-Length: 7081786 > VCL_return deliver > RespHeader Accept-Ranges: bytes > RespHeader Content-Range: bytes 0-1/7081786 > RespStatus 206 > RespReason Partial Content > RespUnset Content-Length: 7081786 > RespHeader Content-Length: 2 Are those actual transactions originating from the browser or you using a tool like curl to test the range behavior? Dridi From info+varnish at shee.org Fri Sep 8 16:54:10 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Fri, 8 Sep 2017 18:54:10 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> Message-ID: <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> > Am 08.09.2017 um 17:05 schrieb Dridi Boukelmoune : > > On Fri, Sep 8, 2017 at 2:55 PM, wrote: > >> Thanks to pointing to this direction. Looking into it I see following (trimmed): >> >> Request 1 >> ReqMethod GET >> ReqURL /test.mp4 >> ReqHeader range: bytes=0-1 >> >> VCL_call HIT >> RespStatus 200 >> RespReason OK >> RespHeader Content-Length: 7081786 >> VCL_return deliver >> RespHeader Accept-Ranges: bytes >> RespHeader Content-Range: bytes 0-1/7081786 >> RespStatus 206 >> RespReason Partial Content >> RespUnset Content-Length: 7081786 >> RespHeader Content-Length: 2 > > > Are those actual transactions originating from the browser or you > using a tool like curl to test the range behavior? Its the real browser (Safari.app 10.1.2, Mac OS X 10.11.6 (15G1611)). Indeed it seems to be strange requesting only 2 bytes initially. A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before). Does it make sense? -- Leon From eyal.marantenboim at storecast.de Mon Sep 11 08:52:17 2017 From: eyal.marantenboim at storecast.de (Eyal Marantenboim) Date: Mon, 11 Sep 2017 01:52:17 -0700 Subject: Is there a way to force exit vcl_recv? Message-ID: Hi, We are trying to have varnish respond to all OPTIONS method requests. These requests should not go to any backend. They should return the CORS headers with an empty body, always (cors headers are added in vcl_deliver). Our problem is that, because of the logic that follows in the config, Varnish still ends up picking a backend and adding body, etc. I would like to avoid adding everywhere 'if req.method != OPTIONS'.. Is there a way in vcl_recv to do something like this: if (req.method ~ "(OPTIONS)"){ // dont pick backend, finish vcl_recv processing and jump directly to vcl_deliver } ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Sep 11 09:43:47 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 11 Sep 2017 11:43:47 +0200 Subject: Is there a way to force exit vcl_recv? In-Reply-To: References: Message-ID: On Mon, Sep 11, 2017 at 10:52 AM, Eyal Marantenboim wrote: > Hi, > > We are trying to have varnish respond to all OPTIONS method requests. These > requests should not go to any backend. They should return the CORS headers > with an empty body, always (cors headers are added in vcl_deliver). > > Our problem is that, because of the logic that follows in the config, > Varnish still ends up picking a backend and adding body, etc. > > I would like to avoid adding everywhere 'if req.method != OPTIONS'.. > > Is there a way in vcl_recv to do something like this: > > if (req.method ~ "(OPTIONS)"){ > // dont pick backend, finish vcl_recv processing and jump directly to > vcl_deliver > } > > ? > > Thanks! Hi, You are looking for synthetic responses: sub vcl_recv { if (req.method == "OPTIONS") { return (synth(200)); } } sub vcl_synth { if (req.method == "OPTIONS") { # set the CORS response headers return (deliver); } } Dridi From eyal.marantenboim at storecast.de Mon Sep 11 11:35:28 2017 From: eyal.marantenboim at storecast.de (Eyal Marantenboim) Date: Mon, 11 Sep 2017 04:35:28 -0700 Subject: Is there a way to force exit vcl_recv? In-Reply-To: References: Message-ID: On 11. September 2017 at 11:44:27, Dridi Boukelmoune (dridi at varni.sh) wrote: On Mon, Sep 11, 2017 at 10:52 AM, Eyal Marantenboim wrote: > Hi, > > We are trying to have varnish respond to all OPTIONS method requests. These > requests should not go to any backend. They should return the CORS headers > with an empty body, always (cors headers are added in vcl_deliver). > > Our problem is that, because of the logic that follows in the config, > Varnish still ends up picking a backend and adding body, etc. > > I would like to avoid adding everywhere 'if req.method != OPTIONS'.. > > Is there a way in vcl_recv to do something like this: > > if (req.method ~ "(OPTIONS)"){ > // dont pick backend, finish vcl_recv processing and jump directly to > vcl_deliver > } > > ? > > Thanks! Hi, You are looking for synthetic responses: sub vcl_recv { if (req.method == "OPTIONS") { return (synth(200)); } } sub vcl_synth { if (req.method == "OPTIONS") { # set the CORS response headers return (deliver); } } Dridi Exactly what I was looking for. Thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmec.stf at gmail.com Mon Sep 11 18:34:32 2017 From: kmec.stf at gmail.com (Stefan Kmec) Date: Mon, 11 Sep 2017 20:34:32 +0200 Subject: Varnish after target property Message-ID: Hello all, I am writing you regarding the issue I experiencing after one of the latest Red hat release. Regarding the configuration file "/usr/lib/systemd/system/varnish.service" varnish starts after network begin with start process : "After=network.target" This makes big troubles to the customer websites after reboot of systems. Our network is taking bit longer to start(30sec) but varnish doesn't depend on it as it needs only see network starting. So after network begin with start(30sec) varnish also starts(5sec). That makes varnish fail as it needs network up before starting itself. For that should be used : "After=network-online.target" After using this correct property everything is okay after boot process - varnish waits till network is up and then starts itself. Unfortunately varnish update leads to rewrite this property back to old one, what again made bit issue to us. Is it possible to amend this property to "After=network-online.target" from old one ? I think it could be the proper setup for the service for future function and would really help me and our customer. As far as I know targets changed just few RHEL7 releases ago where online property was included in service config files. Most of network dependent services has changed this property as the release came out. Would be great having varnish changed that too. Thank you very much in advance. Kind regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Sep 11 19:56:11 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 11 Sep 2017 21:56:11 +0200 Subject: Varnish after target property In-Reply-To: References: Message-ID: On Mon, Sep 11, 2017 at 8:34 PM, Stefan Kmec wrote: > Hello all, > > > I am writing you regarding the issue I experiencing after one of the latest > Red hat release. > > Regarding the configuration file "/usr/lib/systemd/system/varnish.service" > varnish starts after network begin with start process : > "After=network.target" > > This makes big troubles to the customer websites after reboot of systems. > Our network is taking bit longer to start(30sec) but varnish doesn't depend > on it as it needs only see network starting. So after network begin with > start(30sec) varnish also starts(5sec). > That makes varnish fail as it needs network up before starting itself. > > For that should be used : > "After=network-online.target" > > After using this correct property everything is okay after boot process - > varnish waits till network is up and then starts itself. > > Unfortunately varnish update leads to rewrite this property back to old one, > what again made bit issue to us. That probably means that you edited the service file in /usr/lib which is not how you should use systemd. https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path > Is it possible to amend this property to "After=network-online.target" from > old one ? Yes, you can submit a pull request in the pkg-varnish-cache project on github and we'll review that. > I think it could be the proper setup for the service for future function and > would really help me and our customer. > > As far as I know targets changed just few RHEL7 releases ago where online > property was included in service config files. Most of network dependent > services has changed this property as the release came out. Would be great > having varnish changed that too. > > Thank you very much in advance. Thanks a bunch for letting us know! Dridi From info+varnish at shee.org Wed Sep 13 14:00:02 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Wed, 13 Sep 2017 16:00:02 +0200 Subject: Announcements missing 4.0.5, 4.1.8 and 5.1.3 Message-ID: <66BEE238-BE8C-424B-8160-7DA4AE3645F6@shee.org> I do not see any announcements for 4.0.5, 4.1.8 and 5.1.3 via varnish-announce at varnish-cache.org. Is this intentional? -- Thanks, Leon From phk at phk.freebsd.dk Wed Sep 13 14:10:28 2017 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 13 Sep 2017 14:10:28 +0000 Subject: Announcements missing 4.0.5, 4.1.8 and 5.1.3 In-Reply-To: <66BEE238-BE8C-424B-8160-7DA4AE3645F6@shee.org> References: <66BEE238-BE8C-424B-8160-7DA4AE3645F6@shee.org> Message-ID: <48124.1505311828@critter.freebsd.dk> -------- In message <66BEE238-BE8C-424B-8160-7DA4AE3645F6 at shee.org>, info+varnish at shee.org writes: >I do not see any announcements for 4.0.5, 4.1.8 and 5.1.3 via >varnish-announce at varnish-cache.org. Is this intentional? I guess the closest we came to announcing them was a brief mention in the security advisory: https://varnish-cache.org/lists/pipermail/varnish-announce/2017-August/000722.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From info+varnish at shee.org Wed Sep 13 14:52:14 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Wed, 13 Sep 2017 16:52:14 +0200 Subject: Announcements missing 4.0.5, 4.1.8 and 5.1.3 In-Reply-To: References: <66BEE238-BE8C-424B-8160-7DA4AE3645F6@shee.org> Message-ID: > Am 13.09.2017 um 16:13 schrieb Dridi Boukelmoune : > > Those were security releases, they had a security advisory instead of the usual announce. Feels not so coherent but good to known, thanks. -- Leon From info+varnish at shee.org Wed Sep 13 14:54:47 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Wed, 13 Sep 2017 16:54:47 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> Message-ID: Am 08.09.2017 um 18:54 schrieb info+varnish at shee.org: > A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on > the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another > dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before). Dridi, did you had time to assess this? -- Thanks, Leon From dridi at varni.sh Wed Sep 13 15:10:14 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 13 Sep 2017 17:10:14 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> Message-ID: On Wed, Sep 13, 2017 at 4:54 PM, wrote: > Am 08.09.2017 um 18:54 schrieb info+varnish at shee.org: >> A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on >> the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another >> dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before). > > Dridi, did you had time to assess this? No, we kind of have a major release this week, I don't have time for much. But if I had to bet I'd blame the h2 feature. Dridi From info+varnish at shee.org Wed Sep 13 15:28:11 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Wed, 13 Sep 2017 17:28:11 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> Message-ID: <8ECF12EA-A42E-418B-BCFB-3850757727BE@shee.org> > Am 13.09.2017 um 17:10 schrieb Dridi Boukelmoune : > > On Wed, Sep 13, 2017 at 4:54 PM, wrote: >> Am 08.09.2017 um 18:54 schrieb info+varnish at shee.org: >>> A further investigation shows, that the delivery via plain http through varnish works fine. So, I concentrated then on >>> the TLS termination. Downgrading the protocol support to http/1.1 leads to a working mp4 delivery. So far I get another >>> dimension to the problem h2-support + range-handling (sorry, I didn't mentioned the enabled "+http2 feature" before). >> >> Dridi, did you had time to assess this? > > No, we kind of have a major release this week, I don't have time for > much. But if I had to bet I'd blame the h2 feature. Thanks for the answer. Looking forward for the next release :-) -- Leon From vassilis at onlab.xyz Sun Sep 17 18:36:56 2017 From: vassilis at onlab.xyz (Vassilis Aretakis) Date: Sun, 17 Sep 2017 20:36:56 +0200 Subject: Service stall pages in case backends are sick Message-ID: <6b12b42e-7318-5d7f-14fa-a2de9f7097a6@onlab.xyz> I have a setup which was working on Varnish 3.0 but not with 4.1 The stale pages where servered in case the backends where sick. But I cannot make this work with varnish 4. Can you help me to make it serve the cached pages in case backends are gone? also session-cookies can be removed/ignored My config is: vcl 4.0; import directors; import std; backend b1 { ? .host = ? .port = "80"; ? .first_byte_timeout = 180s; ? .between_bytes_timeout = 120s; ? .probe = { ????? .url = "/healthy_check/d.php"; ????? .interval = 10s; ????? .timeout = 2 s; ????? .window = 7; ????? .threshold = 1; ? } } backend b2 { ? .host = ? .port = "80"; ? .first_byte_timeout = 180s; ? .between_bytes_timeout = 120s; ? .probe = { ????? .url = "/healthy_check/d.php"; ????? .interval = 10s; ????? .timeout = 2 s; ????? .window = 7; ????? .threshold = 1; ? } } sub vcl_init { ? new vdir = directors.round_robin(); ? vdir.add_backend(b1); ? vdir.add_backend(b2); } sub vcl_recv { ? set req.backend_hint = vdir.backend(); ? #Ignore adminpanel ? if (req.url == "^/adminpanel/.*" || ????? req.url == "^/adminApplication/.*" || ????? req.url ~ "^/adminApplication/" || ????? req.url ~ "^/adminpanel/" || ????? req.url ~ "^/newsfeed.php" || ????? req.url ~ "^/comment") { ??? return (pass);?? # unset req.http.Cookie; ? } ? if (req.method != "GET" && ????? req.method != "HEAD" && ????? req.method != "PUT" && ????? req.method != "POST" && ????? req.method != "TRACE" && ????? req.method != "OPTIONS" && ????? req.method != "DELETE") { ??? /* Non-RFC2616 or CONNECT which is weird. */ ??? return (pipe); ? } ? if (req.method != "GET" && req.method != "HEAD") { ????? /* We only deal with GET and HEAD by default */ ????? return (pass); ? } ? #set req.http.grace = "none"; ? return (hash); ?} sub vcl_pipe { ? return (pipe); } sub vcl_pass { ? return (fetch); } sub vcl_hit { ? if (obj.ttl >= 0s) { ??? # normal hit ??? return (deliver); ? } ? # We have no fresh fish. Lets look at the stale ones. ? if (std.healthy(req.backend_hint)) { ??? # Backend is healthy. Limit age to 10s. ??? if (obj.ttl + 10s > 0s) { ????? set req.http.grace = "normal(limited)"; ????? return (deliver); ??? } else { ????? # No candidate for grace. Fetch a fresh object. ????? return(fetch); ??? } ? } else { ??? # backend is sick - use full grace ??? if (obj.ttl + obj.grace > 0s) { ????? set req.http.grace = "full"; ????? return (deliver); ??? } else { ????? # no graced object. ????? return (fetch); ??? } ? } } sub vcl_miss { ? return (fetch); } sub vcl_backend_fetch { ? set bereq.backend = vdir.backend(); } sub vcl_backend_response { ? # Happens after we have read the response headers from the backend. ? # ? # Here you clean the response headers, removing silly Set-Cookie headers ? # and other mistakes your backend does. ? unset beresp.http.set-cookie;? set beresp.grace = 1h; ? if (beresp.status > 500) { ?? return (retry); ? } ? if (bereq.url == "^/") { ??? set beresp.ttl = 60s; ? } ? #jpeg caching (forced) ? if (bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg|swf|css|js)$" || ????? bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg)&width.*" || ????? bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg)?.*") { ??? set beresp.http.cache-control = "max-age = 2592000"; ? } ? return (deliver); } sub vcl_hash { ?? hash_data(req.url); ?? if (req.http.host) { ?????? hash_data(req.http.host); ?? } else { ?????? hash_data(server.ip); ?? } ?? return (lookup); } sub vcl_deliver { ? set resp.http.grace = req.http.grace; } From live4life at usa.net Sun Sep 17 22:16:16 2017 From: live4life at usa.net (Andrew Incorvia) Date: Sun, 17 Sep 2017 18:16:16 -0400 Subject: Help with Default.vcl ; WordPress / phpmyadmin Message-ID: <536ViqwPq7888S03.1505686576@web03.cms.usa.net> An HTML attachment was scrubbed... URL: From lagged at gmail.com Mon Sep 18 06:22:47 2017 From: lagged at gmail.com (Andrei) Date: Mon, 18 Sep 2017 09:22:47 +0300 Subject: Varnish Cache 5.2.0 released In-Reply-To: <4714.1505481542@critter.freebsd.dk> References: <4714.1505481542@critter.freebsd.dk> Message-ID: Hello everyone, Am I missing something or did Geoff's UNIX socket patch not make it in 5.2.0? On Fri, Sep 15, 2017 at 4:19 PM, Poul-Henning Kamp wrote: > We have just released Varnish 5.2.0: > > http://varnish-cache.org/releases/rel5.2.0.html#rel5-2-0 > > A big thanks to the entire crew for a great effort! > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > varnish-announce mailing list > varnish-announce at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-announce > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Sep 18 07:11:43 2017 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Sep 2017 07:11:43 +0000 Subject: Varnish Cache 5.2.0 released In-Reply-To: References: <4714.1505481542@critter.freebsd.dk> Message-ID: <14698.1505718703@critter.freebsd.dk> -------- In message , Andrei writes: >Am I missing something or did Geoff's UNIX socket patch not make it in 5.2.0? No, it did not. There were too many outstanding questions about how things should look in VCL and too little time to figure out the answers and implement them. It will be in the next release (march 2018) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From lagged at gmail.com Mon Sep 18 07:51:49 2017 From: lagged at gmail.com (Andrei) Date: Mon, 18 Sep 2017 10:51:49 +0300 Subject: Varnish Cache 5.2.0 released In-Reply-To: <14698.1505718703@critter.freebsd.dk> References: <4714.1505481542@critter.freebsd.dk> <14698.1505718703@critter.freebsd.dk> Message-ID: Thanks for the confirmation, and outstanding work phk! On Mon, Sep 18, 2017 at 10:11 AM, Poul-Henning Kamp wrote: > -------- > In message gmail.com>, Andrei writes: > > >Am I missing something or did Geoff's UNIX socket patch not make it in > 5.2.0? > > No, it did not. There were too many outstanding questions about > how things should look in VCL and too little time to figure out > the answers and implement them. > > It will be in the next release (march 2018) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Sep 18 08:25:49 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 18 Sep 2017 10:25:49 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: <8ECF12EA-A42E-418B-BCFB-3850757727BE@shee.org> References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> <8ECF12EA-A42E-418B-BCFB-3850757727BE@shee.org> Message-ID: >>> Dridi, did you had time to assess this? >> >> No, we kind of have a major release this week, I don't have time for >> much. But if I had to bet I'd blame the h2 feature. > > > Thanks for the answer. Looking forward for the next release :-) Hi Leon, Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental. Thanks, Dridi From info+varnish at shee.org Mon Sep 18 14:48:52 2017 From: info+varnish at shee.org (info+varnish at shee.org) Date: Mon, 18 Sep 2017 16:48:52 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> <8ECF12EA-A42E-418B-BCFB-3850757727BE@shee.org> Message-ID: <37FA0EF7-C7B0-4AE3-AF41-326BF1CFD70E@shee.org> > Am 18.09.2017 um 10:25 schrieb Dridi Boukelmoune : > >>>> Dridi, did you had time to assess this? >>> >>> No, we kind of have a major release this week, I don't have time for >>> much. But if I had to bet I'd blame the h2 feature. >> >> Thanks for the answer. Looking forward for the next release :-) > > Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental. Yes, that is what I have deployed now. Without h2 enabled it works as expected (hitch; alpn-protos = "http/1.1). Doing so I lose a bit of site performance but the functional requirement playing media is higher scored. Right now rolling 5.2.0 packages, just to stay current (h2 stuff seems to be untouched). -- Thanks Leon From guillaume at varnish-software.com Tue Sep 19 20:10:08 2017 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Tue, 19 Sep 2017 22:10:08 +0200 Subject: Help with Default.vcl ; WordPress / phpmyadmin In-Reply-To: <536ViqwPq7888S03.1505686576@web03.cms.usa.net> References: <536ViqwPq7888S03.1505686576@web03.cms.usa.net> Message-ID: - ban("req.url ~ " + req.url + " && req.http.host ~ " + req.http.host); + ban("req.url ~ " + req.url + " && req.http.host ~ " + req.http.host); bad html formatting, that will should soon will be fixed, thanks. If there's another issue, please give us the error message. -- Guillaume Quintard On Mon, Sep 18, 2017 at 12:16 AM, Andrew Incorvia wrote: > Hello Varnish-cache Community: > > Ubuntu 16.04.3 > Varnish-Cache 5.1.3 > Apache 2.4.18 > > I could use a little help with getting the default.vcl correct for use > with WP and phpmyadmin > > Want I want to do is exclude these paths from varnish: > > myipaddress_hostname/phpmyadmin/ [without hardcoding the > myipaddress_hostname] > > and also > > myipaddress_hostname/wp-login.php > > > Additionally, > > I want to handle cookies correctly as per: > https://info.varnish-software.com/blog/step-step-speed- > wordpress-varnish-software > [This article is old, and I believe the syntax is causing issues as I > tried, and Varnish-Cache would not start.] > > Thanks! > > A.I > > My default.vcl > > # > # This is an example VCL file for Varnish. > # > # It does not do anything by default, delegating control to the > # builtin VCL. The builtin VCL is called when there is no explicit > # return statement. > # > # See the VCL chapters in the Users Guide at > https://www.varnish-cache.org/docs/ > # and https://www.varnish-cache.org/trac/wiki/VCLExamples for more > examples. > > # Marker to tell the VCL compiler that this VCL has been adapted to the > # new 4.0 format. > vcl 4.0; > > # Default backend definition. Set this to point to your content server. > backend default { > .host = "127.0.0.1"; > .port = "8080"; > } > > ### Exluding URLs from Caching ### > sub vcl_recv { > if (req.url ~ "^/phpmyadmin/") { > return (pass); > } > } > > sub vcl_recv { > # Happens before we check if we have this in cache already. > # > # Typically you clean up the request here, removing cookies you don't > need, > # rewriting the request, etc. > > if (req.method == "PURGE") { > > if (req.http.X-Purge-Method == "regex") { > > ban("req.url ~ " + req.url + " && req.http.host ~ " + > req.http.host); > > return (synth(200, "Banned.")); > > } else { > > return (purge); > > } > } > > set req.http.cookie = regsuball(req.http.cookie, "wp-settings-\d+=[^;]+(; > )?", ""); > > set req.http.cookie = regsuball(req.http.cookie, > "wp-settings-time-\d+=[^;]+(; )?", ""); > > set req.http.cookie = regsuball(req.http.cookie, > "wordpress_test_cookie=[^;]+(; )?", ""); > > if (req.http.cookie == "") { > > unset req.http.cookie; > } > } > > sub vcl_backend_response { > # Happens after we have read the response headers from the backend. > # > # Here you clean the response headers, removing silly Set-Cookie > headers > # and other mistakes your backend does. > } > > sub vcl_deliver { > # Happens when we have all the pieces we need, and are about to send > the > # response to the client. > # > # You can do accounting or modifying the final object here. > } > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel_3_gonzalez at yahoo.es Tue Sep 19 22:12:57 2017 From: miguel_3_gonzalez at yahoo.es (=?UTF-8?Q?Miguel_Gonz=c3=a1lez?=) Date: Wed, 20 Sep 2017 00:12:57 +0200 Subject: Help with Default.vcl ; WordPress / phpmyadmin In-Reply-To: References: <536ViqwPq7888S03.1505686576@web03.cms.usa.net> Message-ID: <691267e0-dc61-4110-f52e-a5098c5edf81@yahoo.es> Guillaume, this one got out of my radar ;) On 09/19/17 10:10 PM, Guillaume Quintard wrote: > > - ban("req.url ~ " + req.url + " && req.http.host ~ " + > req.http.host); > > + ban("req.url ~ " + req.url + " && req.http.host ~ " + req.http.host); > > bad html formatting, that will should soon will be fixed, thanks. > > If there's another issue, please give us the error message. > > -- > Guillaume Quintard > > On Mon, Sep 18, 2017 at 12:16 AM, Andrew Incorvia > wrote: > > Hello Varnish-cache Community: > > Ubuntu 16.04.3 > Varnish-Cache 5.1.3 > Apache 2.4.18 > > I could use a little help with getting the default.vcl correct for > use with WP and phpmyadmin > > Want I want to do is exclude these paths from varnish: > > myipaddress_hostname/phpmyadmin/???? [without hardcoding the > myipaddress_hostname] > > and also > > myipaddress_hostname/wp-login.php > > > Additionally, > > I want to handle cookies correctly as per: > https://info.varnish-software.com/blog/step-step-speed-wordpress-varnish-software > > > [This article is old, and I believe the syntax is causing issues as > I tried, and Varnish-Cache would not start.] > > Thanks! > > A.I > > My default.vcl > > # > # This is an example VCL file for Varnish. > # > # It does not do anything by default, delegating control to the > # builtin VCL. The builtin VCL is called when there is no explicit > # return statement. > # > # See the VCL chapters in the Users Guide at > https://www.varnish-cache.org/docs/ > > # and https://www.varnish-cache.org/trac/wiki/VCLExamples > for more > examples. > > # Marker to tell the VCL compiler that this VCL has been adapted to the > # new 4.0 format. > vcl 4.0; > > # Default backend definition. Set this to point to your content server. > backend default { > ??? .host = "127.0.0.1"; > ??? .port = "8080"; > } > > ### Exluding URLs from Caching ### > sub vcl_recv { > ?? if (req.url ~ "^/phpmyadmin/") { > ????? return (pass); > ?? } > } > > sub vcl_recv { > ??? # Happens before we check if we have this in cache already. > ??? # > ??? # Typically you clean up the request here, removing cookies you > don't need, > ??? # rewriting the request, etc. > > if (req.method == "PURGE") { > > if (req.http.X-Purge-Method == "regex") { > > ban("req.url ~ " + req.url + " && req.http.host ~ " + > req.http.host); > > return (synth(200, "Banned.")); > > } else { > > return (purge); > > } > } > > set req.http.cookie = regsuball(req.http.cookie, > "wp-settings-\d+=[^;]+(; )?", ""); > > set req.http.cookie = regsuball(req.http.cookie, > "wp-settings-time-\d+=[^;]+(; )?", ""); > > set req.http.cookie = regsuball(req.http.cookie, > "wordpress_test_cookie=[^;]+(; )?", ""); > > if (req.http.cookie == "") { > > unset req.http.cookie; > } > } > > sub vcl_backend_response { > ??? # Happens after we have read the response headers from the backend. > ??? # > ??? # Here you clean the response headers, removing silly Set-Cookie > headers > ??? # and other mistakes your backend does. > } > > sub vcl_deliver { > ??? # Happens when we have all the pieces we need, and are about to > send the > ??? # response to the client. > ??? # > ??? # You can do accounting or modifying the final object here. > } > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > . From Christopher at hippomotorgroup.co.uk Wed Sep 20 09:47:13 2017 From: Christopher at hippomotorgroup.co.uk (Christopher Edwards) Date: Wed, 20 Sep 2017 09:47:13 +0000 Subject: Stuck with cookies and phpsessid Message-ID: When a user tries to upload content via our CMS, we're getting a incorrect permissions due to PHPSESSID not being sent. Here is my current vcl file, what would I have to change to resolve the PHPSESSID error? As an alternative to resolving this issue (not ideal) set a section of the site to not be cached by varnish but I'm also not sure of how to do that. vcl 4.0; import directors; import std; backend site1 { .host = "127.0.0.1"; .port = "8080"; } backend site2 { .host = "127.0.0.1"; .port = "8081"; } backend site3 { .host = "127.0.0.1"; .port = "8082"; } acl purge { "localhost"; "127.0.0.1"; } sub vcl_recv { # SINGLE BACKEND # set req.backend_hint= default; if (req.http.host == "www.site2.co.uk") { set req.backend_hint = site2; } else if (req.http.host == "www.site3.co.uk") { set req.backend_hint = site3; } else if (req.http.host == "site1.site2.co.uk") { set req.backend_hint = site1; } else { return (synth(404, "Host not found")); } # SET HTTP HEADERS set req.http.X-Forwarded-For = client.ip; set req.http.X-Forwarded-Proto = "https"; # REMOVE HEADERS THAT MIGHT DUPLICATE CACHE unset req.http.Accept-Language; unset req.http.User-Agent; # PURGE if (req.method == "PURGE") { if (!client.ip ~ purge) { return(synth(405,"Not allowed.")); } return (purge); } if ( std.port(server.ip) == 6080) { set req.http.x-redir = "https://" + req.http.host + req.url; return (synth(750, "Moved permanently")); } # DROP COOKIES AND PARAMS FROM STATIC ASSET if (req.url ~ "\.(gif|jpg|jpeg|swf|ttf|css|js|flv|mp3|mp4|pdf|ico|png)(\?.*|)$") { unset req.http.cookie; set req.url = regsub(req.url, "\?.*$", ""); } # PASS COOKIES if (req.http.cookie) { if (req.http.cookie ~ "(exclude_)") { return(pass); } else { unset req.http.cookie; } } } sub vcl_backend_response { # RETRY BACKEND 3 TIMES IF DOWN if (beresp.status == 503 && bereq.retries < 3 ) { return(retry); } if (bereq.http.Cookie ~ "(UserID|_session)") { set beresp.http.X-Cacheable = "NO:Got Session"; set beresp.uncacheable = true; return (deliver); } elsif (beresp.ttl <= 0s) { set beresp.http.X-Cacheable = "YES"; } elsif (beresp.http.set-cookie) { set beresp.http.X-Cacheable = "YES"; set beresp.uncacheable = false; return (deliver); } elsif (beresp.http.Cache-Control ~ "private") { set beresp.http.X-Cacheable = "NO:Cache-Control=private"; set beresp.uncacheable = true; return (deliver); } else { set beresp.http.X-Cacheable = "YES"; unset beresp.http.expires; set beresp.http.cache-control = "max-age=900"; set beresp.ttl = 1w; set beresp.http.magicmarker = "1"; } # UNSET COOKIES if (!(bereq.url ~ "(exclude)")) { set beresp.http.X-UnsetCookies = "TRUE"; unset beresp.http.set-cookie; set beresp.ttl = 1h; } # YEAR LONG CACHE FILE TYPES if (bereq.url ~ "\.(gif|jpg|jpeg|png)(\?.*|)$") { set beresp.ttl = 365d; # MONTH LONG CACHE FILE TYPES if (bereq.url ~ "\.(css|js|flv|mp3|mp4|pdf|)(\?.*|)$") { set beresp.ttl = 30d; } } set beresp.grace = 1w; } sub vcl_hash { if ( req.http.X-Forwarded-Proto ) { hash_data( req.http.X-Forwarded-Proto ); } } sub vcl_backend_error { # DISPAY CUSTOM ERROR IF FAILS if (beresp.status == 503 && bereq.retries == 3) { synthetic(std.fileread("/etc/varnish/error503.html")); return(deliver); } } sub vcl_synth { # REDIRECT FOR HTTP if (resp.status == 750) { set resp.status = 301; set resp.http.Location = req.http.x-redir; return(deliver); } # DISPLAY CUSTOM PAGE IF BACKEND DOWN if (resp.status == 503) { synthetic(std.fileread("/etc/varnish/error503.html")); return(deliver); } } sub vcl_deliver { # RESTART IF BACKEND DOWN if (resp.status == 503) { return(restart); } if (resp.http.magicmarker) { # REMOVE MAGIC MARK unset resp.http.magicmarker; # FRESH OBJECT set resp.http.age = "0"; } if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } set resp.http.Access-Control-Allow-Origin = "*"; } sub vcl_hit { if (req.method == "PURGE") { return(synth(200,"OK")); } } sub vcl_miss { if (req.method == "PURGE") { return(synth(404,"Not cached")); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Wed Sep 20 10:21:22 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 20 Sep 2017 12:21:22 +0200 Subject: Handling HTML5 Video for iOS and Safari clients In-Reply-To: <37FA0EF7-C7B0-4AE3-AF41-326BF1CFD70E@shee.org> References: <19037858-010A-4C08-B3F5-168AB1A4C430@shee.org> <625FFD69-A031-47CA-A5DD-C0EC11643A96@shee.org> <9712A4CC-A880-41BC-A068-D798C06B716A@shee.org> <8ECF12EA-A42E-418B-BCFB-3850757727BE@shee.org> <37FA0EF7-C7B0-4AE3-AF41-326BF1CFD70E@shee.org> Message-ID: >> Did you try playing videos using HTTPS without enabling h2? As of 5.2.0 it is still experimental. > > > Yes, that is what I have deployed now. Without h2 enabled it works as expected > (hitch; alpn-protos = "http/1.1). Doing so I lose a bit of site performance but > the functional requirement playing media is higher scored. > > Right now rolling 5.2.0 packages, just to stay current (h2 stuff seems to be untouched). Thanks for confirming, so we narrowed it down to what looks like a range bug with h2. Can you open a github issue? We'll pick it up from there and try to reproduce it. Dridi From lagged at gmail.com Wed Sep 20 13:58:54 2017 From: lagged at gmail.com (Andrei) Date: Wed, 20 Sep 2017 08:58:54 -0500 Subject: Stuck with cookies and phpsessid In-Reply-To: References: Message-ID: Please provide the varnishlog output for a request seen leading to the described issue. There are multiple sections in which cookies are unset, where you could be triggering this behavior. On Wed, Sep 20, 2017 at 4:47 AM, Christopher Edwards < Christopher at hippomotorgroup.co.uk> wrote: > When a user tries to upload content via our CMS, we're getting a incorrect > permissions due to PHPSESSID not being sent. > > Here is my current vcl file, what would I have to change to resolve the > PHPSESSID error? > > As an alternative to resolving this issue (not ideal) set a section of the > site to not be cached by varnish but I'm also not sure of how to do that. > > vcl 4.0; > > import directors; > > import std; > > > > backend site1 { > > .host = "127.0.0.1"; > > .port = "8080"; > > } > > > > backend site2 { > > .host = "127.0.0.1"; > > .port = "8081"; > > } > > > > backend site3 { > > .host = "127.0.0.1"; > > .port = "8082"; > > } > > > > acl purge { > > "localhost"; > > "127.0.0.1"; > > } > > > > > > sub vcl_recv { > > # SINGLE BACKEND > > # set req.backend_hint= default; > > if (req.http.host == "www.site2.co.uk") { > > set req.backend_hint = site2; > > } > > else if (req.http.host == "www.site3.co.uk") { > > set req.backend_hint = site3; > > } > > else if (req.http.host == "site1.site2.co.uk") { > > set req.backend_hint = site1; > > } > > else { > > return (synth(404, "Host not found")); > > } > > > > # SET HTTP HEADERS > > set req.http.X-Forwarded-For = client.ip; > > set req.http.X-Forwarded-Proto = "https"; > > > > # REMOVE HEADERS THAT MIGHT DUPLICATE CACHE > > unset req.http.Accept-Language; > > unset req.http.User-Agent; > > > > # PURGE > > if (req.method == "PURGE") { > > if (!client.ip ~ purge) { > > return(synth(405,"Not allowed.")); > > } > > return (purge); > > } > > if ( std.port(server.ip) == 6080) { > > > > set req.http.x-redir = "https://" + req.http.host + req.url; > > return (synth(750, "Moved permanently")); > > } > > > > # DROP COOKIES AND PARAMS FROM STATIC ASSET > > if (req.url ~ "\.(gif|jpg|jpeg|swf|ttf|css| > js|flv|mp3|mp4|pdf|ico|png)(\?.*|)$") { > > unset req.http.cookie; > > set req.url = regsub(req.url, "\?.*$", ""); > > } > > > > # PASS COOKIES > > if (req.http.cookie) { > > if (req.http.cookie ~ "(exclude_)") { > > return(pass); > > } else { > > unset req.http.cookie; > > } > > } > > } > > > > > > > > sub vcl_backend_response { > > # RETRY BACKEND 3 TIMES IF DOWN > > if (beresp.status == 503 && bereq.retries < 3 ) { > > return(retry); > > } > > > > if (bereq.http.Cookie ~ "(UserID|_session)") { > > set beresp.http.X-Cacheable = "NO:Got Session"; > > set beresp.uncacheable = true; > > return (deliver); > > > > } elsif (beresp.ttl <= 0s) { > > set beresp.http.X-Cacheable = "YES"; > > > > } elsif (beresp.http.set-cookie) { > > set beresp.http.X-Cacheable = "YES"; > > set beresp.uncacheable = false; > > return (deliver); > > > > } elsif (beresp.http.Cache-Control ~ "private") { > > set beresp.http.X-Cacheable = "NO:Cache-Control=private"; > > set beresp.uncacheable = true; > > return (deliver); > > > > } else { > > set beresp.http.X-Cacheable = "YES"; > > > > unset beresp.http.expires; > > > > set beresp.http.cache-control = "max-age=900"; > > > > set beresp.ttl = 1w; > > > > set beresp.http.magicmarker = "1"; > > } > > > > # UNSET COOKIES > > if (!(bereq.url ~ "(exclude)")) { > > set beresp.http.X-UnsetCookies = "TRUE"; > > unset beresp.http.set-cookie; > > set beresp.ttl = 1h; > > } > > > > # YEAR LONG CACHE FILE TYPES > > if (bereq.url ~ "\.(gif|jpg|jpeg|png)(\?.*|)$") { > > set beresp.ttl = 365d; > > > > # MONTH LONG CACHE FILE TYPES > > if (bereq.url ~ "\.(css|js|flv|mp3|mp4|pdf|)(\?.*|)$") { > > set beresp.ttl = 30d; > > > > } > > > > } > > set beresp.grace = 1w; > > > > } > > > > sub vcl_hash { > > if ( req.http.X-Forwarded-Proto ) { > > hash_data( req.http.X-Forwarded-Proto ); > > } > > } > > > > sub vcl_backend_error { > > # DISPAY CUSTOM ERROR IF FAILS > > if (beresp.status == 503 && bereq.retries == 3) { > > synthetic(std.fileread("/etc/varnish/error503.html")); > > return(deliver); > > } > > } > > > > sub vcl_synth { > > # REDIRECT FOR HTTP > > if (resp.status == 750) { > > set resp.status = 301; > > set resp.http.Location = req.http.x-redir; > > return(deliver); > > } > > # DISPLAY CUSTOM PAGE IF BACKEND DOWN > > if (resp.status == 503) { > > synthetic(std.fileread("/etc/varnish/error503.html")); > > return(deliver); > > } > > } > > > > > > sub vcl_deliver { > > > > > > # RESTART IF BACKEND DOWN > > if (resp.status == 503) { > > return(restart); > > } > > if (resp.http.magicmarker) { > > # REMOVE MAGIC MARK > > unset resp.http.magicmarker; > > > > # FRESH OBJECT > > set resp.http.age = "0"; > > } > > if (obj.hits > 0) { > > set resp.http.X-Cache = "HIT"; > > } else { > > set resp.http.X-Cache = "MISS"; > > } > > set resp.http.Access-Control-Allow-Origin = "*"; > > } > > sub vcl_hit { > > if (req.method == "PURGE") { > > return(synth(200,"OK")); > > } > > } > > > > > > sub vcl_miss { > > if (req.method == "PURGE") { > > return(synth(404,"Not cached")); > > } > > } > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.staudinger at nyi.net Sun Sep 24 04:14:42 2017 From: mark.staudinger at nyi.net (Mark Staudinger) Date: Sun, 24 Sep 2017 00:14:42 -0400 Subject: libvmod / xkey Message-ID: Hi Folks, I'm evaluating the xkey module for use in my workflow and while I have tested successfully the basic functionality I am left with one question. Is there any way to provide criteria for matching keys? It seems that when specifying multiple space-separated tags during the purge, any matching key will cause a purge. Is there any way ( other than using regular ban ) to purge based based on matching two or more keys - logical AND instead of OR for the keys provided? Regards, Mark Staudinger From guillaume at varnish-software.com Sun Sep 24 08:33:13 2017 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Sun, 24 Sep 2017 10:33:13 +0200 Subject: Estimated Memory allocation In-Reply-To: <1503589280140.29379@measinc.com> References: <1503589280140.29379@measinc.com> Message-ID: Hi Rodney, The main factor regarding memory is really going to be the cache storage. To this you can add 1Kb of metadata per object stored (usually not an issue). If you have a large amount of thread, each one will have a workspace assigned to it, and that will consume a few dozens KB per threads. -- Guillaume Quintard On Thu, Aug 24, 2017 at 5:41 PM, Rodney Bizzell wrote: > Hello, > > I would like to know what is the best practices for estimating allocation > of memory for varnish is there minimum based off of the number of backend > web servers.Thanks! > > > This email (including any attachments) may contain confidential > information intended solely for acknowledged recipients. If you think you > have received this information in error, please reply to the sender and > delete all copies from your system. Please note that unauthorized use, > disclosure, or further distribution of this information is prohibited by > the sender. Note also that we may monitor email directed to or originating > from our network. Thank you for your consideration and assistance. | > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Sun Sep 24 08:36:39 2017 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Sun, 24 Sep 2017 10:36:39 +0200 Subject: Hit idle send timeout In-Reply-To: References: Message-ID: You client dropped the connection, not much you can do or worry about. -- Guillaume Quintard On Sat, Sep 2, 2017 at 10:15 PM, Andrei wrote: > Hello everyone, > > I'm running 4.1.8 as a frontend to a local Apache 2.4 and just recently > ran into a burst of the following "idle/write errors" without any > corresponding errors logged in Apache. Any suggestions on what to keep an > eye on or further review would be greatly appreciated. > > * << Request >> 482784125 > - Begin req 482784124 rxreq > - Timestamp Start: 1504382885.868717 0.000000 0.000000 > - Timestamp Req: 1504382885.868717 0.000000 0.000000 > - ReqStart [redacted.xfwd2IP] 35207 > - ReqMethod GET > - ReqURL /[redacted.url]/ > - ReqProtocol HTTP/1.1 > - ReqHeader Host: www.[redacted.domain.tld] > - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G920F > Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 > Mobile Safari/537.36 > - ReqHeader Accept: text/html,application/xhtml+ > xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 > - ReqHeader Accept-Language: ro-RO,ro;q=0.8,en-US;q=0.6,en;q=0.4 > - ReqHeader Cf-Connecting-Ip: [redacted.xfwd1IP] > - ReqHeader Cf-Ipcountry: RO > - ReqHeader Cf-Origin-Https: off > - ReqHeader Cf-Ray: 3983196ce0b87ea0-BUD > - ReqHeader Cf-Visitor: {"scheme":"http"} > - ReqHeader Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; > __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; > _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C34%2C11%7C35 > - ReqHeader Referer: https://www.google.ro/ > - ReqHeader Upgrade-Insecure-Requests: 1 > - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] > - ReqHeader X-Forwarded-Proto: http > - ReqHeader Accept-Encoding: gzip > - ReqHeader Connection: close > - ReqUnset X-Forwarded-For: [redacted.xfwd1IP] > - ReqHeader X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] > - VCL_call RECV > - VCL_acl MATCH cloudflare "172.64.0.0/13" > - ReqHeader X-Country: RO > - ReqHeader ignore_becache: 1 > - ReqUnset Host: www.[redacted.domain.tld] > - ReqHeader Host: www.[redacted.domain.tld] > - ReqUnset X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] > - ReqHeader X-Forwarded-For-Src: CloudFlare > - ReqHeader X-Real-IP: [redacted.xfwd1IP] > - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] > - ReqHeader X-Client: [redacted.xfwd2IP] > - VCL_acl NO_MATCH facebook > - ReqUnset X-Forwarded-Proto: http > - ReqHeader X-Forwarded-Proto: http > - ReqHeader X-Forwarded-HTTPS: off > - ReqHeader X-Port: 80 > - ReqHeader X-Forwarded-Port: 80 > - ReqHeader X-HTTPS: off > - VCL_acl NO_MATCH global_blacklist > - VCL_acl NO_MATCH tor_blacklist > - ReqHeader X-UA-Device: pc > - ReqUnset X-UA-Device: pc > - ReqHeader X-UA-Device: mobile-android > - ReqHeader X-My-Purge-Key: [redacted] > - ReqHeader X-Purge-Key-Auth: false > - ReqURL /[redacted.url]/ > - VCL_Log COOKIESTRIP:/[redacted.url]/ > - ReqUnset Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; > __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; > _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C34%2C11%7C35 > - ReqHeader allow_override: enabled > - ReqUnset Accept-Encoding: gzip > - ReqHeader Accept-Encoding: gzip > - ReqHeader Surrogate-Capability: key=ESI/1.0 > - ReqUnset X-My-Purge-Key: [redacted] > - ReqHeader X-TTL: 14400.000 > - ReqHeader X-Cacheable: YES:Dynamic cache, ttl: 14400.000 > - ReqHeader X-Req-Type: Cache:Dynamic > - VCL_return hash > - VCL_call HASH > - ReqHeader hash: /[redacted.url]/ > - ReqUnset hash: /[redacted.url]/ > - ReqHeader hash: www.[redacted.domain.tld]#/[redacted.url]/ > - ReqUnset hash: www.[redacted.domain.tld]#/[redacted.url]/ > - ReqHeader hash: http#mobile-android#www.[redacted.domain.tld]#/[ > redacted.url]/ > - VCL_return lookup > - Hit 482125483 > - VCL_call HIT > - VCL_Log OKHITDELIVER: obj.ttl:14065.370 obj.keep: 0.000 > obj.grace: 21600.000 > - VCL_return deliver > - RespProtocol HTTP/1.1 > - RespStatus 200 > - RespReason OK > - RespHeader Date: Sat, 02 Sep 2017 20:02:30 GMT > - RespHeader x-frame-options: SAMEORIGIN > - RespHeader X-XSS-Protection: 1; mode=block > - RespHeader X-Content-Type-Options: nosniff > - RespHeader X-Pingback: http://www.[redacted.domain.tld]/xmlrpc.php > - RespHeader Link: ; > rel=shortlink > - RespHeader Content-Type: text/html; charset=UTF-8 > - RespHeader X-Req-Type: Cache:Dynamic > - RespHeader Accept-Encoding: gzip > - RespHeader Vary: Accept-Encoding, X-UA-Device > - RespHeader X-UA-Device: mobile-android > - RespHeader X-Req-Host: www.[redacted.domain.tld] > - RespHeader X-Req-URL: /[redacted.url]/ > - RespHeader X-Req-URL-Base: /[redacted.url]/ > - RespHeader X-TTL: 14400.000 > - RespHeader X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 > - RespHeader X-Varnish: 482784125 482125483 > - RespHeader Age: 334 > - RespHeader Via: 1.1 varnish-v4 > - VCL_call DELIVER > - RespHeader X-Cache: HIT > - VCL_Log OKHITDELIVERY: obj.hits: 1 ttl:14400.000 > - RespUnset X-Req-Type: Cache:Dynamic > - RespUnset Age: 334 > - RespUnset X-Cache: HIT > - RespUnset X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 > - RespUnset X-TTL: 14400.000 > - RespUnset X-Req-Host: www.[redacted.domain.tld] > - RespUnset X-Req-URL: /[redacted.url]/ > - RespUnset X-Req-URL-Base: /[redacted.url]/ > - RespUnset X-Varnish: 482784125 482125483 > - RespUnset Via: 1.1 varnish-v4 > - RespUnset X-UA-Device: mobile-android > - VCL_return deliver > - Timestamp Process: 1504382885.868905 0.000188 0.000188 > - RespHeader Accept-Ranges: bytes > - RespHeader Content-Length: 63072 > - Debug "RES_MODE 2" > - RespHeader Connection: close > - Debug "Hit idle send timeout, wrote = 55480/63504; retrying" > - Debug "Write error, retval = -1, len = 8024, errno = Broken > pipe" > - Timestamp Resp: 1504382886.049021 0.180304 0.180115 > - ReqAcct 869 0 869 432 63072 63504 > - End > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Sun Sep 24 08:55:12 2017 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Sun, 24 Sep 2017 10:55:12 +0200 Subject: Service stall pages in case backends are sick In-Reply-To: <6b12b42e-7318-5d7f-14fa-a2de9f7097a6@onlab.xyz> References: <6b12b42e-7318-5d7f-14fa-a2de9f7097a6@onlab.xyz> Message-ID: Have you changed the default grace (10s)? -- Guillaume Quintard On Sun, Sep 17, 2017 at 8:36 PM, Vassilis Aretakis wrote: > I have a setup which was working on Varnish 3.0 but not with 4.1 > > The stale pages where servered in case the backends where sick. But I > cannot make this work with varnish 4. > Can you help me to make it serve the cached pages in case backends are > gone? > also session-cookies can be removed/ignored > > My config is: > > > vcl 4.0; > import directors; > import std; > > backend b1 { > .host = > .port = "80"; > .first_byte_timeout = 180s; > .between_bytes_timeout = 120s; > .probe = { > .url = "/healthy_check/d.php"; > .interval = 10s; > .timeout = 2 s; > .window = 7; > .threshold = 1; > } > } > > > backend b2 { > .host = > .port = "80"; > .first_byte_timeout = 180s; > .between_bytes_timeout = 120s; > .probe = { > .url = "/healthy_check/d.php"; > .interval = 10s; > .timeout = 2 s; > .window = 7; > .threshold = 1; > } > } > > > sub vcl_init { > new vdir = directors.round_robin(); > vdir.add_backend(b1); > vdir.add_backend(b2); > } > > sub vcl_recv { > > set req.backend_hint = vdir.backend(); > > #Ignore adminpanel > if (req.url == "^/adminpanel/.*" || > req.url == "^/adminApplication/.*" || > req.url ~ "^/adminApplication/" || > req.url ~ "^/adminpanel/" || > req.url ~ "^/newsfeed.php" || > req.url ~ "^/comment") { > return (pass); # unset req.http.Cookie; > } > > if (req.method != "GET" && > req.method != "HEAD" && > req.method != "PUT" && > req.method != "POST" && > req.method != "TRACE" && > req.method != "OPTIONS" && > req.method != "DELETE") { > /* Non-RFC2616 or CONNECT which is weird. */ > return (pipe); > } > if (req.method != "GET" && req.method != "HEAD") { > /* We only deal with GET and HEAD by default */ > return (pass); > } > #set req.http.grace = "none"; > > return (hash); > } > > sub vcl_pipe { > > return (pipe); > } > > sub vcl_pass { > return (fetch); > } > > sub vcl_hit { > if (obj.ttl >= 0s) { > # normal hit > return (deliver); > } > # We have no fresh fish. Lets look at the stale ones. > if (std.healthy(req.backend_hint)) { > # Backend is healthy. Limit age to 10s. > if (obj.ttl + 10s > 0s) { > set req.http.grace = "normal(limited)"; > return (deliver); > } else { > # No candidate for grace. Fetch a fresh object. > return(fetch); > } > } else { > # backend is sick - use full grace > if (obj.ttl + obj.grace > 0s) { > set req.http.grace = "full"; > return (deliver); > } else { > # no graced object. > return (fetch); > } > } > } > > sub vcl_miss { > return (fetch); > } > > sub vcl_backend_fetch { > set bereq.backend = vdir.backend(); > } > > sub vcl_backend_response { > # Happens after we have read the response headers from the backend. > # > # Here you clean the response headers, removing silly Set-Cookie headers > # and other mistakes your backend does. > unset beresp.http.set-cookie; set beresp.grace = 1h; > if (beresp.status > 500) { > return (retry); > } > if (bereq.url == "^/") { > set beresp.ttl = 60s; > } > > #jpeg caching (forced) > if (bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg|swf|css|js)$" || > bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg)&width.*" || > bereq.url ~ "\.(png|gif|PNG|JPG|JPEG|jpg|jpeg)?.*") { > set beresp.http.cache-control = "max-age = 2592000"; > } > return (deliver); > } > > sub vcl_hash { > hash_data(req.url); > if (req.http.host) { > hash_data(req.http.host); > } else { > hash_data(server.ip); > } > return (lookup); > } > > sub vcl_deliver { > set resp.http.grace = req.http.grace; > } > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From lagged at gmail.com Mon Sep 25 05:29:10 2017 From: lagged at gmail.com (Andrei) Date: Mon, 25 Sep 2017 08:29:10 +0300 Subject: Hit idle send timeout In-Reply-To: References: Message-ID: Hi Guillaume, Thanks for the update! :) Am I reading the log wrong, or is there a difference in Content-Length ( 63072), and the debug data which to me suggests it's expecting to send 63504 and only got as far as 55480? On Sun, Sep 24, 2017 at 11:36 AM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > You client dropped the connection, not much you can do or worry about. > > -- > Guillaume Quintard > > On Sat, Sep 2, 2017 at 10:15 PM, Andrei wrote: > >> Hello everyone, >> >> I'm running 4.1.8 as a frontend to a local Apache 2.4 and just recently >> ran into a burst of the following "idle/write errors" without any >> corresponding errors logged in Apache. Any suggestions on what to keep an >> eye on or further review would be greatly appreciated. >> >> * << Request >> 482784125 >> - Begin req 482784124 rxreq >> - Timestamp Start: 1504382885.868717 0.000000 0.000000 >> - Timestamp Req: 1504382885.868717 0.000000 0.000000 >> - ReqStart [redacted.xfwd2IP] 35207 >> - ReqMethod GET >> - ReqURL /[redacted.url]/ >> - ReqProtocol HTTP/1.1 >> - ReqHeader Host: www.[redacted.domain.tld] >> - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G920F >> Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 >> Mobile Safari/537.36 >> - ReqHeader Accept: text/html,application/xhtml+xm >> l,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 >> - ReqHeader Accept-Language: ro-RO,ro;q=0.8,en-US;q=0.6,en;q=0.4 >> - ReqHeader Cf-Connecting-Ip: [redacted.xfwd1IP] >> - ReqHeader Cf-Ipcountry: RO >> - ReqHeader Cf-Origin-Https: off >> - ReqHeader Cf-Ray: 3983196ce0b87ea0-BUD >> - ReqHeader Cf-Visitor: {"scheme":"http"} >> - ReqHeader Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >> 34%2C11%7C35 >> - ReqHeader Referer: https://www.google.ro/ >> - ReqHeader Upgrade-Insecure-Requests: 1 >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-Proto: http >> - ReqHeader Accept-Encoding: gzip >> - ReqHeader Connection: close >> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] >> - VCL_call RECV >> - VCL_acl MATCH cloudflare "172.64.0.0/13" >> - ReqHeader X-Country: RO >> - ReqHeader ignore_becache: 1 >> - ReqUnset Host: www.[redacted.domain.tld] >> - ReqHeader Host: www.[redacted.domain.tld] >> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] >> - ReqHeader X-Forwarded-For-Src: CloudFlare >> - ReqHeader X-Real-IP: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Client: [redacted.xfwd2IP] >> - VCL_acl NO_MATCH facebook >> - ReqUnset X-Forwarded-Proto: http >> - ReqHeader X-Forwarded-Proto: http >> - ReqHeader X-Forwarded-HTTPS: off >> - ReqHeader X-Port: 80 >> - ReqHeader X-Forwarded-Port: 80 >> - ReqHeader X-HTTPS: off >> - VCL_acl NO_MATCH global_blacklist >> - VCL_acl NO_MATCH tor_blacklist >> - ReqHeader X-UA-Device: pc >> - ReqUnset X-UA-Device: pc >> - ReqHeader X-UA-Device: mobile-android >> - ReqHeader X-My-Purge-Key: [redacted] >> - ReqHeader X-Purge-Key-Auth: false >> - ReqURL /[redacted.url]/ >> - VCL_Log COOKIESTRIP:/[redacted.url]/ >> - ReqUnset Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >> 34%2C11%7C35 >> - ReqHeader allow_override: enabled >> - ReqUnset Accept-Encoding: gzip >> - ReqHeader Accept-Encoding: gzip >> - ReqHeader Surrogate-Capability: key=ESI/1.0 >> - ReqUnset X-My-Purge-Key: [redacted] >> - ReqHeader X-TTL: 14400.000 >> - ReqHeader X-Cacheable: YES:Dynamic cache, ttl: 14400.000 >> - ReqHeader X-Req-Type: Cache:Dynamic >> - VCL_return hash >> - VCL_call HASH >> - ReqHeader hash: /[redacted.url]/ >> - ReqUnset hash: /[redacted.url]/ >> - ReqHeader hash: www.[redacted.domain.tld]#/[redacted.url]/ >> - ReqUnset hash: www.[redacted.domain.tld]#/[redacted.url]/ >> - ReqHeader hash: http#mobile-android#www.[redac >> ted.domain.tld]#/[redacted.url]/ >> - VCL_return lookup >> - Hit 482125483 >> - VCL_call HIT >> - VCL_Log OKHITDELIVER: obj.ttl:14065.370 obj.keep: 0.000 >> obj.grace: 21600.000 >> - VCL_return deliver >> - RespProtocol HTTP/1.1 >> - RespStatus 200 >> - RespReason OK >> - RespHeader Date: Sat, 02 Sep 2017 20:02:30 GMT >> - RespHeader x-frame-options: SAMEORIGIN >> - RespHeader X-XSS-Protection: 1; mode=block >> - RespHeader X-Content-Type-Options: nosniff >> - RespHeader X-Pingback: http://www.[redacted.domain.tl >> d]/xmlrpc.php >> - RespHeader Link: ; >> rel=shortlink >> - RespHeader Content-Type: text/html; charset=UTF-8 >> - RespHeader X-Req-Type: Cache:Dynamic >> - RespHeader Accept-Encoding: gzip >> - RespHeader Vary: Accept-Encoding, X-UA-Device >> - RespHeader X-UA-Device: mobile-android >> - RespHeader X-Req-Host: www.[redacted.domain.tld] >> - RespHeader X-Req-URL: /[redacted.url]/ >> - RespHeader X-Req-URL-Base: /[redacted.url]/ >> - RespHeader X-TTL: 14400.000 >> - RespHeader X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >> - RespHeader X-Varnish: 482784125 482125483 >> - RespHeader Age: 334 >> - RespHeader Via: 1.1 varnish-v4 >> - VCL_call DELIVER >> - RespHeader X-Cache: HIT >> - VCL_Log OKHITDELIVERY: obj.hits: 1 ttl:14400.000 >> - RespUnset X-Req-Type: Cache:Dynamic >> - RespUnset Age: 334 >> - RespUnset X-Cache: HIT >> - RespUnset X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >> - RespUnset X-TTL: 14400.000 >> - RespUnset X-Req-Host: www.[redacted.domain.tld] >> - RespUnset X-Req-URL: /[redacted.url]/ >> - RespUnset X-Req-URL-Base: /[redacted.url]/ >> - RespUnset X-Varnish: 482784125 482125483 >> - RespUnset Via: 1.1 varnish-v4 >> - RespUnset X-UA-Device: mobile-android >> - VCL_return deliver >> - Timestamp Process: 1504382885.868905 0.000188 0.000188 >> - RespHeader Accept-Ranges: bytes >> - RespHeader Content-Length: 63072 >> - Debug "RES_MODE 2" >> - RespHeader Connection: close >> - Debug "Hit idle send timeout, wrote = 55480/63504; retrying" >> - Debug "Write error, retval = -1, len = 8024, errno = Broken >> pipe" >> - Timestamp Resp: 1504382886.049021 0.180304 0.180115 >> - ReqAcct 869 0 869 432 63072 63504 >> - End >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Mon Sep 25 07:21:41 2017 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Mon, 25 Sep 2017 09:21:41 +0200 Subject: Hit idle send timeout In-Reply-To: References: Message-ID: 63504 is the total size (headers+body), and 55480 is what could be pushed to the kernel. You don't really know if it was really sent (or received, for that matter). -- Guillaume Quintard On Sep 25, 2017 07:29, "Andrei" wrote: Hi Guillaume, Thanks for the update! :) Am I reading the log wrong, or is there a difference in Content-Length ( 63072), and the debug data which to me suggests it's expecting to send 63504 and only got as far as 55480? On Sun, Sep 24, 2017 at 11:36 AM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > You client dropped the connection, not much you can do or worry about. > > -- > Guillaume Quintard > > On Sat, Sep 2, 2017 at 10:15 PM, Andrei wrote: > >> Hello everyone, >> >> I'm running 4.1.8 as a frontend to a local Apache 2.4 and just recently >> ran into a burst of the following "idle/write errors" without any >> corresponding errors logged in Apache. Any suggestions on what to keep an >> eye on or further review would be greatly appreciated. >> >> * << Request >> 482784125 >> - Begin req 482784124 rxreq >> - Timestamp Start: 1504382885.868717 0.000000 0.000000 >> - Timestamp Req: 1504382885.868717 0.000000 0.000000 >> - ReqStart [redacted.xfwd2IP] 35207 >> - ReqMethod GET >> - ReqURL /[redacted.url]/ >> - ReqProtocol HTTP/1.1 >> - ReqHeader Host: www.[redacted.domain.tld] >> - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G920F >> Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 >> Mobile Safari/537.36 >> - ReqHeader Accept: text/html,application/xhtml+xm >> l,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 >> - ReqHeader Accept-Language: ro-RO,ro;q=0.8,en-US;q=0.6,en;q=0.4 >> - ReqHeader Cf-Connecting-Ip: [redacted.xfwd1IP] >> - ReqHeader Cf-Ipcountry: RO >> - ReqHeader Cf-Origin-Https: off >> - ReqHeader Cf-Ray: 3983196ce0b87ea0-BUD >> - ReqHeader Cf-Visitor: {"scheme":"http"} >> - ReqHeader Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >> 34%2C11%7C35 >> - ReqHeader Referer: https://www.google.ro/ >> - ReqHeader Upgrade-Insecure-Requests: 1 >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-Proto: http >> - ReqHeader Accept-Encoding: gzip >> - ReqHeader Connection: close >> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] >> - VCL_call RECV >> - VCL_acl MATCH cloudflare "172.64.0.0/13" >> - ReqHeader X-Country: RO >> - ReqHeader ignore_becache: 1 >> - ReqUnset Host: www.[redacted.domain.tld] >> - ReqHeader Host: www.[redacted.domain.tld] >> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP], [redacted.xfwd2IP] >> - ReqHeader X-Forwarded-For-Src: CloudFlare >> - ReqHeader X-Real-IP: [redacted.xfwd1IP] >> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >> - ReqHeader X-Client: [redacted.xfwd2IP] >> - VCL_acl NO_MATCH facebook >> - ReqUnset X-Forwarded-Proto: http >> - ReqHeader X-Forwarded-Proto: http >> - ReqHeader X-Forwarded-HTTPS: off >> - ReqHeader X-Port: 80 >> - ReqHeader X-Forwarded-Port: 80 >> - ReqHeader X-HTTPS: off >> - VCL_acl NO_MATCH global_blacklist >> - VCL_acl NO_MATCH tor_blacklist >> - ReqHeader X-UA-Device: pc >> - ReqUnset X-UA-Device: pc >> - ReqHeader X-UA-Device: mobile-android >> - ReqHeader X-My-Purge-Key: [redacted] >> - ReqHeader X-Purge-Key-Auth: false >> - ReqURL /[redacted.url]/ >> - VCL_Log COOKIESTRIP:/[redacted.url]/ >> - ReqUnset Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >> 34%2C11%7C35 >> - ReqHeader allow_override: enabled >> - ReqUnset Accept-Encoding: gzip >> - ReqHeader Accept-Encoding: gzip >> - ReqHeader Surrogate-Capability: key=ESI/1.0 >> - ReqUnset X-My-Purge-Key: [redacted] >> - ReqHeader X-TTL: 14400.000 >> - ReqHeader X-Cacheable: YES:Dynamic cache, ttl: 14400.000 >> - ReqHeader X-Req-Type: Cache:Dynamic >> - VCL_return hash >> - VCL_call HASH >> - ReqHeader hash: /[redacted.url]/ >> - ReqUnset hash: /[redacted.url]/ >> - ReqHeader hash: www.[redacted.domain.tld]#/[redacted.url]/ >> - ReqUnset hash: www.[redacted.domain.tld]#/[redacted.url]/ >> - ReqHeader hash: http#mobile-android#www.[redac >> ted.domain.tld]#/[redacted.url]/ >> - VCL_return lookup >> - Hit 482125483 >> - VCL_call HIT >> - VCL_Log OKHITDELIVER: obj.ttl:14065.370 obj.keep: 0.000 >> obj.grace: 21600.000 >> - VCL_return deliver >> - RespProtocol HTTP/1.1 >> - RespStatus 200 >> - RespReason OK >> - RespHeader Date: Sat, 02 Sep 2017 20:02:30 GMT >> - RespHeader x-frame-options: SAMEORIGIN >> - RespHeader X-XSS-Protection: 1; mode=block >> - RespHeader X-Content-Type-Options: nosniff >> - RespHeader X-Pingback: http://www.[redacted.domain.tl >> d]/xmlrpc.php >> - RespHeader Link: ; >> rel=shortlink >> - RespHeader Content-Type: text/html; charset=UTF-8 >> - RespHeader X-Req-Type: Cache:Dynamic >> - RespHeader Accept-Encoding: gzip >> - RespHeader Vary: Accept-Encoding, X-UA-Device >> - RespHeader X-UA-Device: mobile-android >> - RespHeader X-Req-Host: www.[redacted.domain.tld] >> - RespHeader X-Req-URL: /[redacted.url]/ >> - RespHeader X-Req-URL-Base: /[redacted.url]/ >> - RespHeader X-TTL: 14400.000 >> - RespHeader X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >> - RespHeader X-Varnish: 482784125 482125483 >> - RespHeader Age: 334 >> - RespHeader Via: 1.1 varnish-v4 >> - VCL_call DELIVER >> - RespHeader X-Cache: HIT >> - VCL_Log OKHITDELIVERY: obj.hits: 1 ttl:14400.000 >> - RespUnset X-Req-Type: Cache:Dynamic >> - RespUnset Age: 334 >> - RespUnset X-Cache: HIT >> - RespUnset X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >> - RespUnset X-TTL: 14400.000 >> - RespUnset X-Req-Host: www.[redacted.domain.tld] >> - RespUnset X-Req-URL: /[redacted.url]/ >> - RespUnset X-Req-URL-Base: /[redacted.url]/ >> - RespUnset X-Varnish: 482784125 482125483 >> - RespUnset Via: 1.1 varnish-v4 >> - RespUnset X-UA-Device: mobile-android >> - VCL_return deliver >> - Timestamp Process: 1504382885.868905 0.000188 0.000188 >> - RespHeader Accept-Ranges: bytes >> - RespHeader Content-Length: 63072 >> - Debug "RES_MODE 2" >> - RespHeader Connection: close >> - Debug "Hit idle send timeout, wrote = 55480/63504; retrying" >> - Debug "Write error, retval = -1, len = 8024, errno = Broken >> pipe" >> - Timestamp Resp: 1504382886.049021 0.180304 0.180115 >> - ReqAcct 869 0 869 432 63072 63504 >> - End >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Mon Sep 25 07:31:25 2017 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 25 Sep 2017 09:31:25 +0200 Subject: libvmod / xkey In-Reply-To: References: Message-ID: On Sun, Sep 24, 2017 at 6:14 AM, Mark Staudinger wrote: > Hi Folks, > > I'm evaluating the xkey module for use in my workflow and while I have > tested successfully the basic functionality I am left with one question. > > Is there any way to provide criteria for matching keys? It seems that when > specifying multiple space-separated tags during the purge, any matching key > will cause a purge. Is there any way ( other than using regular ban ) to > purge based based on matching two or more keys - logical AND instead of OR > for the keys provided? Hi Mark, This is currently not possible, and that use case would definitely make sense. We could have a parameter of type ENUM {union, intersection} defaulting to union (the current behavior). This is currently not on our roadmap, but we would gladly review patches for this feature. Dridi From lagged at gmail.com Mon Sep 25 08:04:24 2017 From: lagged at gmail.com (Andrei) Date: Mon, 25 Sep 2017 11:04:24 +0300 Subject: Hit idle send timeout In-Reply-To: References: Message-ID: Gotcha, thanks for the clarification! On Mon, Sep 25, 2017 at 10:21 AM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > 63504 is the total size (headers+body), and 55480 is what could be pushed > to the kernel. You don't really know if it was really sent (or received, > for that matter). > > -- > Guillaume Quintard > > On Sep 25, 2017 07:29, "Andrei" wrote: > > Hi Guillaume, > > Thanks for the update! :) > Am I reading the log wrong, or is there a difference in Content-Length ( > 63072), and the debug data which to me suggests it's expecting to send > 63504 and only got as far as 55480? > > On Sun, Sep 24, 2017 at 11:36 AM, Guillaume Quintard < > guillaume at varnish-software.com> wrote: > >> You client dropped the connection, not much you can do or worry about. >> >> -- >> Guillaume Quintard >> >> On Sat, Sep 2, 2017 at 10:15 PM, Andrei wrote: >> >>> Hello everyone, >>> >>> I'm running 4.1.8 as a frontend to a local Apache 2.4 and just recently >>> ran into a burst of the following "idle/write errors" without any >>> corresponding errors logged in Apache. Any suggestions on what to keep an >>> eye on or further review would be greatly appreciated. >>> >>> * << Request >> 482784125 >>> - Begin req 482784124 rxreq >>> - Timestamp Start: 1504382885.868717 0.000000 0.000000 >>> - Timestamp Req: 1504382885.868717 0.000000 0.000000 >>> - ReqStart [redacted.xfwd2IP] 35207 >>> - ReqMethod GET >>> - ReqURL /[redacted.url]/ >>> - ReqProtocol HTTP/1.1 >>> - ReqHeader Host: www.[redacted.domain.tld] >>> - ReqHeader User-Agent: Mozilla/5.0 (Linux; Android 7.0; SM-G920F >>> Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 >>> Mobile Safari/537.36 >>> - ReqHeader Accept: text/html,application/xhtml+xm >>> l,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 >>> - ReqHeader Accept-Language: ro-RO,ro;q=0.8,en-US;q=0.6,en;q=0.4 >>> - ReqHeader Cf-Connecting-Ip: [redacted.xfwd1IP] >>> - ReqHeader Cf-Ipcountry: RO >>> - ReqHeader Cf-Origin-Https: off >>> - ReqHeader Cf-Ray: 3983196ce0b87ea0-BUD >>> - ReqHeader Cf-Visitor: {"scheme":"http"} >>> - ReqHeader Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >>> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >>> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >>> 34%2C11%7C35 >>> - ReqHeader Referer: https://www.google.ro/ >>> - ReqHeader Upgrade-Insecure-Requests: 1 >>> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >>> - ReqHeader X-Forwarded-Proto: http >>> - ReqHeader Accept-Encoding: gzip >>> - ReqHeader Connection: close >>> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP] >>> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP], >>> [redacted.xfwd2IP] >>> - VCL_call RECV >>> - VCL_acl MATCH cloudflare "172.64.0.0/13" >>> - ReqHeader X-Country: RO >>> - ReqHeader ignore_becache: 1 >>> - ReqUnset Host: www.[redacted.domain.tld] >>> - ReqHeader Host: www.[redacted.domain.tld] >>> - ReqUnset X-Forwarded-For: [redacted.xfwd1IP], >>> [redacted.xfwd2IP] >>> - ReqHeader X-Forwarded-For-Src: CloudFlare >>> - ReqHeader X-Real-IP: [redacted.xfwd1IP] >>> - ReqHeader X-Forwarded-For: [redacted.xfwd1IP] >>> - ReqHeader X-Client: [redacted.xfwd2IP] >>> - VCL_acl NO_MATCH facebook >>> - ReqUnset X-Forwarded-Proto: http >>> - ReqHeader X-Forwarded-Proto: http >>> - ReqHeader X-Forwarded-HTTPS: off >>> - ReqHeader X-Port: 80 >>> - ReqHeader X-Forwarded-Port: 80 >>> - ReqHeader X-HTTPS: off >>> - VCL_acl NO_MATCH global_blacklist >>> - VCL_acl NO_MATCH tor_blacklist >>> - ReqHeader X-UA-Device: pc >>> - ReqUnset X-UA-Device: pc >>> - ReqHeader X-UA-Device: mobile-android >>> - ReqHeader X-My-Purge-Key: [redacted] >>> - ReqHeader X-Purge-Key-Auth: false >>> - ReqURL /[redacted.url]/ >>> - VCL_Log COOKIESTRIP:/[redacted.url]/ >>> - ReqUnset Cookie: __cfduid=da15bbd5734efa927910bae7091f5c3c81501871885; >>> __PPU_SESSION_1_1335313_false=1504207577718|3|1504207684422|3|1; >>> _ga=GA1.2.606320764.1502399957; __atuvc=2%7C32%2C0%7C33%2C4%7C >>> 34%2C11%7C35 >>> - ReqHeader allow_override: enabled >>> - ReqUnset Accept-Encoding: gzip >>> - ReqHeader Accept-Encoding: gzip >>> - ReqHeader Surrogate-Capability: key=ESI/1.0 >>> - ReqUnset X-My-Purge-Key: [redacted] >>> - ReqHeader X-TTL: 14400.000 >>> - ReqHeader X-Cacheable: YES:Dynamic cache, ttl: 14400.000 >>> - ReqHeader X-Req-Type: Cache:Dynamic >>> - VCL_return hash >>> - VCL_call HASH >>> - ReqHeader hash: /[redacted.url]/ >>> - ReqUnset hash: /[redacted.url]/ >>> - ReqHeader hash: www.[redacted.domain.tld]#/[redacted.url]/ >>> - ReqUnset hash: www.[redacted.domain.tld]#/[redacted.url]/ >>> - ReqHeader hash: http#mobile-android#www.[redac >>> ted.domain.tld]#/[redacted.url]/ >>> - VCL_return lookup >>> - Hit 482125483 >>> - VCL_call HIT >>> - VCL_Log OKHITDELIVER: obj.ttl:14065.370 obj.keep: 0.000 >>> obj.grace: 21600.000 >>> - VCL_return deliver >>> - RespProtocol HTTP/1.1 >>> - RespStatus 200 >>> - RespReason OK >>> - RespHeader Date: Sat, 02 Sep 2017 20:02:30 GMT >>> - RespHeader x-frame-options: SAMEORIGIN >>> - RespHeader X-XSS-Protection: 1; mode=block >>> - RespHeader X-Content-Type-Options: nosniff >>> - RespHeader X-Pingback: http://www.[redacted.domain.tl >>> d]/xmlrpc.php >>> - RespHeader Link: ; >>> rel=shortlink >>> - RespHeader Content-Type: text/html; charset=UTF-8 >>> - RespHeader X-Req-Type: Cache:Dynamic >>> - RespHeader Accept-Encoding: gzip >>> - RespHeader Vary: Accept-Encoding, X-UA-Device >>> - RespHeader X-UA-Device: mobile-android >>> - RespHeader X-Req-Host: www.[redacted.domain.tld] >>> - RespHeader X-Req-URL: /[redacted.url]/ >>> - RespHeader X-Req-URL-Base: /[redacted.url]/ >>> - RespHeader X-TTL: 14400.000 >>> - RespHeader X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >>> - RespHeader X-Varnish: 482784125 482125483 >>> - RespHeader Age: 334 >>> - RespHeader Via: 1.1 varnish-v4 >>> - VCL_call DELIVER >>> - RespHeader X-Cache: HIT >>> - VCL_Log OKHITDELIVERY: obj.hits: 1 ttl:14400.000 >>> - RespUnset X-Req-Type: Cache:Dynamic >>> - RespUnset Age: 334 >>> - RespUnset X-Cache: HIT >>> - RespUnset X-Cacheable: YES:Cacheable dynamic, ttl: 14400.000 >>> - RespUnset X-TTL: 14400.000 >>> - RespUnset X-Req-Host: www.[redacted.domain.tld] >>> - RespUnset X-Req-URL: /[redacted.url]/ >>> - RespUnset X-Req-URL-Base: /[redacted.url]/ >>> - RespUnset X-Varnish: 482784125 482125483 >>> - RespUnset Via: 1.1 varnish-v4 >>> - RespUnset X-UA-Device: mobile-android >>> - VCL_return deliver >>> - Timestamp Process: 1504382885.868905 0.000188 0.000188 >>> - RespHeader Accept-Ranges: bytes >>> - RespHeader Content-Length: 63072 >>> - Debug "RES_MODE 2" >>> - RespHeader Connection: close >>> - Debug "Hit idle send timeout, wrote = 55480/63504; retrying" >>> - Debug "Write error, retval = -1, len = 8024, errno = Broken >>> pipe" >>> - Timestamp Resp: 1504382886.049021 0.180304 0.180115 >>> - ReqAcct 869 0 869 432 63072 63504 >>> - End >>> >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdgregg at pitt.edu Thu Sep 28 01:37:31 2017 From: bdgregg at pitt.edu (Brian D. Gregg) Date: Thu, 28 Sep 2017 01:37:31 +0000 Subject: Package repo at packagecloud.io not showing any packages. Message-ID: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> All, I was just trying to access the new package repo on packagecloud.io and no matter what parameters I give for OS and Arch to the script that generates the varnishcache_varnish5.repo file I am unable to perform a 'yum search' or 'yum install' of the varnish cache packages. Here is the .repo file: [varnishcache_varnish5] name=varnishcache_varnish5 baseurl=https://packagecloud.io/varnishcache/varnish5/ol/6/$basearch repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packagecloud.io/varnishcache/varnish5/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 [varnishcache_varnish5-source] name=varnishcache_varnish5-source baseurl=https://packagecloud.io/varnishcache/varnish5/ol/6/SRPMS repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packagecloud.io/varnishcache/varnish5/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 Visiting https://packagecloud.io/varnishcache/varnish5/ol/6/x86_64 should show some packages correct? But it is not. I changed it to: https://packagecloud.io/varnishcache/varnish5/el/6/x86_64 - This does not show packages either. But ? packages are listed here: https://packagecloud.io/varnishcache/varnish52 just not in any repo format. Any help on getting yum to work properly using the varnish cache packages on packagecloud.io? Eventually I'll want to add this to our spacewalk system to distribute varnish cache to our installations, but obviously cannot do so with this not working. Thanks. -Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at varnish-software.com Thu Sep 28 09:15:00 2017 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 28 Sep 2017 11:15:00 +0200 Subject: Package repo at packagecloud.io not showing any packages. In-Reply-To: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> References: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> Message-ID: Hi Brian, Oracle Linux is not on the Varnish project's list of supported plattforms, and we do not publish packages for it. That is why the repo file as you have configured it doesn't give you any packages. The normal RedHat/Centos packages might work fine on Oracle Linux, though we do not test that. Changing your baseurl to this should give you the published RPMs (notice changing 'ol' to 'el'): baseurl=https://packagecloud.io/varnishcache/varnish5/el/6/$basearch > I changed it to: https://packagecloud.io/varnishcache/varnish5/el/6/x86_64 - > This does not show packages either. > Packagecloud does not implement the kind of directory listing you often see see when a web server is pointed at a directory hierarchy based package repository, so you will not get a directory listing by browsing the RPM repository URLs. But the index files that yum reads are answered and it will work when pointing yum to that URL. Regards, Martin Blix Grydeland -- *Martin Blix Grydeland* Senior Developer | Varnish Software AS Mobile: +47 992 74 756 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From noelle at uni-wuppertal.de Thu Sep 28 10:39:34 2017 From: noelle at uni-wuppertal.de (=?UTF-8?Q?Christian_N=c3=b6lle?=) Date: Thu, 28 Sep 2017 12:39:34 +0200 Subject: munin plugin not working with 5.2 Message-ID: Hi everybody, after upgrading to 5.2 from 5.1.x our munin plugin stopped working. Are the changes to the stats system - announced in the release notes for 5.2 - the cause? Does anyone know where to get a working version? Greetings! -- -c -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5397 bytes Desc: S/MIME Cryptographic Signature URL: From bdgregg at pitt.edu Thu Sep 28 10:57:37 2017 From: bdgregg at pitt.edu (Brian D. Gregg) Date: Thu, 28 Sep 2017 10:57:37 +0000 Subject: Package repo at packagecloud.io not showing any packages. In-Reply-To: References: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> Message-ID: <4F7B03D3-4B91-4164-8396-736763071E27@pitt.edu> Martin, I understand, and yes normally OL will use EL package without error. I?ll make a change to the .repo file on the system to use el instead of ol and try again, but I was sure I tried this as well. I?ll follow up with the results. BTW ? Is there a web page indicating the supported platforms? -Brian. From: Martin Blix Grydeland Date: Thursday, September 28, 2017 at 5:15 AM To: Brian Gregg Cc: "varnish-misc at varnish-cache.org" Subject: Re: Package repo at packagecloud.io not showing any packages. Hi Brian, Oracle Linux is not on the Varnish project's list of supported plattforms, and we do not publish packages for it. That is why the repo file as you have configured it doesn't give you any packages. The normal RedHat/Centos packages might work fine on Oracle Linux, though we do not test that. Changing your baseurl to this should give you the published RPMs (notice changing 'ol' to 'el'): baseurl=https://packagecloud.io/varnishcache/varnish5/el/6/$basearch I changed it to: https://packagecloud.io/varnishcache/varnish5/el/6/x86_64 - This does not show packages either. Packagecloud does not implement the kind of directory listing you often see see when a web server is pointed at a directory hierarchy based package repository, so you will not get a directory listing by browsing the RPM repository URLs. But the index files that yum reads are answered and it will work when pointing yum to that URL. Regards, Martin Blix Grydeland -- [http://www.varnish-software.com/static/media/logo-email.png] Martin Blix Grydeland Senior Developer | Varnish Software AS Mobile: +47 992 74 756 We Make Websites Fly! -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at varnish-software.com Thu Sep 28 11:08:18 2017 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Thu, 28 Sep 2017 11:08:18 +0000 Subject: Package repo at packagecloud.io not showing any packages. In-Reply-To: <4F7B03D3-4B91-4164-8396-736763071E27@pitt.edu> References: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> <4F7B03D3-4B91-4164-8396-736763071E27@pitt.edu> Message-ID: On Thu, 28 Sep 2017 at 12:57 Brian D. Gregg wrote: > BTW ? Is there a web page indicating the supported platforms? > http://varnish-cache.org/releases/index.html Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdgregg at pitt.edu Thu Sep 28 19:03:05 2017 From: bdgregg at pitt.edu (Brian D. Gregg) Date: Thu, 28 Sep 2017 19:03:05 +0000 Subject: Package repo at packagecloud.io not showing any packages. In-Reply-To: References: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> <4F7B03D3-4B91-4164-8396-736763071E27@pitt.edu> Message-ID: Martin, Confirmed that indeed changing the varnishcache_varnish5.repo file to the following did indeed work (change 'ol' to 'el' in the baseurl): [varnishcache_varnish5] name=varnishcache_varnish5 baseurl=https://packagecloud.io/varnishcache/varnish5/el/6/$basearch repo_gpgcheck=1 gpgcheck=0 enabled=1 gpgkey=https://packagecloud.io/varnishcache/varnish5/gpgkey sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 But to also use along with the EPEL repository I needed to add the line 'exclude=varnish*' to the epel.repo file. If not you may end up with varnish 2.1.5 (currently) from EPEL. Thanks, -Brian. From: Martin Blix Grydeland [mailto:martin at varnish-software.com] Sent: Thursday, September 28, 2017 7:08 AM To: Brian D. Gregg Cc: varnish-misc at varnish-cache.org Subject: Re: Package repo at packagecloud.io not showing any packages. On Thu, 28 Sep 2017 at 12:57 Brian D. Gregg > wrote: BTW ? Is there a web page indicating the supported platforms? http://varnish-cache.org/releases/index.html Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis at varnish-software.com Thu Sep 28 20:52:30 2017 From: denis at varnish-software.com (=?UTF-8?Q?Denis_Br=C3=A6khus?=) Date: Thu, 28 Sep 2017 20:52:30 +0000 Subject: Package repo at packagecloud.io not showing any packages. In-Reply-To: References: <6D19BA3C-26EA-4950-A64E-DA642606A639@pitt.edu> <4F7B03D3-4B91-4164-8396-736763071E27@pitt.edu> Message-ID: That should not be necessary. At least it?s not required for proper RHEL/CentOS 6 or 7. As long as the varnish version in the project (packagecloud) repo is newer than in EPEL, you should get the newest one. On Thu, 28 Sep 2017 at 21:04, Brian D. Gregg wrote: > Martin, > > > > Confirmed that indeed changing the varnishcache_varnish5.repo file to the > following did indeed work (change 'ol' to 'el' in the baseurl): > > > > [varnishcache_varnish5] > > name=varnishcache_varnish5 > > baseurl=https://packagecloud.io/varnishcache/varnish5/el/6/$basearch > > repo_gpgcheck=1 > > gpgcheck=0 > > enabled=1 > > gpgkey=https://packagecloud.io/varnishcache/varnish5/gpgkey > > sslverify=1 > > sslcacert=/etc/pki/tls/certs/ca-bundle.crt > > metadata_expire=300 > > > > But to also use along with the EPEL repository I needed to add the line > 'exclude=varnish*' to the epel.repo file. > > If not you may end up with varnish 2.1.5 (currently) from EPEL. > > > > Thanks, > > -Brian. > > > > *From:* Martin Blix Grydeland [mailto:martin at varnish-software.com] > *Sent:* Thursday, September 28, 2017 7:08 AM > *To:* Brian D. Gregg > *Cc:* varnish-misc at varnish-cache.org > > > *Subject:* Re: Package repo at packagecloud.io not showing any packages. > > > > On Thu, 28 Sep 2017 at 12:57 Brian D. Gregg wrote: > > BTW ? Is there a web page indicating the supported platforms? > > http://varnish-cache.org/releases/index.html > > > > > > Martin > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc -- Denis Br?khus Senior Engineer | Varnish Software AS We Make Websites Fly! www.varnish-software.com -------------- next part -------------- An HTML attachment was scrubbed... URL: