From fgsch at lodoss.net Sun Jan 3 19:21:04 2016 From: fgsch at lodoss.net (Federico Schwindt) Date: Sun, 3 Jan 2016 19:21:04 +0000 Subject: [PATCH] Do not send a zero Content-Length for 204 and 304 Message-ID: Hi, In the 304 case we were already skipping it for non-zero C-L. For 204 responses this was introduced as a side effect of 271e1c52. Comments? OK? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Do-not-send-a-zero-Content-Length-for-204-and-304.patch Type: text/x-diff Size: 2673 bytes Desc: not available URL: From guillaume at varnish-software.com Tue Jan 5 08:26:27 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Tue, 5 Jan 2016 09:26:27 +0100 Subject: [PATCH] Do not send a zero Content-Length for 204 and 304 In-Reply-To: References: Message-ID: On Sun, Jan 3, 2016 at 8:21 PM, Federico Schwindt wrote: > Hi, > > In the 304 case we were already skipping it for non-zero C-L. > For 204 responses this was introduced as a side effect of 271e1c52. > > Comments? OK? > Looks OK to me. -- Guillaume Quintard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Tue Jan 5 16:23:17 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 5 Jan 2016 17:23:17 +0100 Subject: [PATCH] Do not send a zero Content-Length for 204 and 304 In-Reply-To: References:

Message-ID: On Tue, Jan 5, 2016 at 9:26 AM, Guillaume Quintard wrote: > On Sun, Jan 3, 2016 at 8:21 PM, Federico Schwindt wrote: >> >> Hi, >> >> In the 304 case we were already skipping it for non-zero C-L. >> For 204 responses this was introduced as a side effect of 271e1c52. >> >> Comments? OK? > > > Looks OK to me. +1 for the one-liner From eric.lewis at nytimes.com Tue Jan 5 18:21:15 2016 From: eric.lewis at nytimes.com (Lewis, Eric) Date: Tue, 5 Jan 2016 13:21:15 -0500 Subject: An Official Varnish Docker Repository Message-ID: Hi, we recently open sourced our Varnish Dockerfile , and would like to make it the basis for the official Docker repository for Varnish. We've already made a proposal , but it was suggested we check in with the Varnish project owner's first. Preferably official Docker repos are maintained by "upstream," i.e. someone from the Varnish project. Here's more on Official Docker repos . Would anyone from the Varnish project be interested in maintaining the repository? If not, do you mind if we continue with this effort? Thanks, Eric Lewis Web Developer, Interactive News The New York Times 620 Eighth Avenue, 2nd Floor New York, NY 10018 Office: (212) 556-2081 Cell: (610) 715-8560 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgsch at lodoss.net Wed Jan 6 00:10:12 2016 From: fgsch at lodoss.net (Federico Schwindt) Date: Wed, 6 Jan 2016 00:10:12 +0000 Subject: An Official Varnish Docker Repository In-Reply-To: References: Message-ID: Hi Eric, It's good to finally see a docker image from the community! That said, personally if the image is official I'd expect it to be done by the people running the project. Call me paranoid but I'd feel more reassured knowing it's coming from the same source. OTOH, I don't see any issues having a non-official image for anyone to use. Regarding the Dockerfile itself, as you are aware since Varnish 4.0 you don't need the sources to build VMODs. If a VMOD still requires the sources it extremely likely it won't build with 4.0 and having the sources won't change that. BR. On Tue, Jan 5, 2016 at 6:21 PM, Lewis, Eric wrote: > Hi, > > we recently open sourced our Varnish Dockerfile > , and would like to make it > the basis for the official Docker repository for Varnish. We've already > made a proposal > , but it was > suggested we check in with the Varnish project owner's first. > > Preferably official Docker repos are maintained by "upstream," i.e. > someone from the Varnish project. Here's more on Official Docker repos > . > > Would anyone from the Varnish project be interested in maintaining the > repository? If not, do you mind if we continue with this effort? > > Thanks, > > Eric Lewis > Web Developer, Interactive News > The New York Times > 620 Eighth Avenue, 2nd Floor > New York, NY 10018 > Office: (212) 556-2081 > Cell: (610) 715-8560 > > _______________________________________________ > varnish-dev mailing list > varnish-dev at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.lewis at nytimes.com Wed Jan 6 17:24:29 2016 From: eric.lewis at nytimes.com (Lewis, Eric) Date: Wed, 6 Jan 2016 12:24:29 -0500 Subject: An Official Varnish Docker Repository In-Reply-To: References:

Message-ID: On Tue, Jan 5, 2016 at 7:10 PM, Federico Schwindt wrote: > > Call me paranoid but I'd feel more reassured knowing it's coming from the > same source. > I can understand that. I'll say there is review for official images by Docker repository leaders, so not just any image that installs Varnish would be accepted. Also, we welcome anyone running the Varnish project to take the reigns here, collaborate with us, or offer feedback. :) On Tue, Jan 5, 2016 at 7:10 PM, Federico Schwindt wrote: > Regarding the Dockerfile itself, as you are aware since Varnish 4.0 you > don't need the sources to build VMODs. > If a VMOD still requires the sources it extremely likely it won't build > with 4.0 and having the sources won't change that. > This feedback came up in a conversation on varnish-misc about the Dockerfile. libvmod-querystring doesn't support the 4.0 installation process , which I've successfully built and used with 4.0. For now, installing from source is a good default for backwards compatibility and offers a simple upgrade path. Is there a resource for describing to vmod authors how to use the new 4.0 installation process? If the Varnish project would like to see vmod authors use the new 4.0 installation process, we should do an audit on the official vmod directory to see which vmods don't use it, and usher them along on the path to adopting. Eric Lewis Web Developer, Interactive News The New York Times 620 Eighth Avenue, 2nd Floor New York, NY 10018 Office: (212) 556-2081 Cell: (610) 715-8560 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Fri Jan 8 10:23:52 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Fri, 8 Jan 2016 11:23:52 +0100 Subject: [PATCH] VCL temperature improvements In-Reply-To: References:

Message-ID: On Thu, Dec 10, 2015 at 4:30 PM, Dridi Boukelmoune wrote: >> Hi, >> >> Here is a new batch of patches fix changes requested from a first >> review. There's one more commit this time, it's number 3. > > One more update for the first review, I forgot to update patch number 1. Hi, Same patches as last time, rebased against current master. I sneaked in a trivial patch (0001) taking advantage of the review. Cheers, Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Display-the-WRONG-message-in-VAS_Fail_default.patch Type: text/x-patch Size: 1452 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Turn-VCL-state-magic-numbers-into-an-enum.patch Type: text/x-patch Size: 4251 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Make-vcl_set_state-accept-a-ctx-instead-of-a-vcl.patch Type: text/x-patch Size: 3457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Wrap-VCL-event-calls-in-a-dedicated-function.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Allow-VMODs-to-fail-a-warm-up.patch Type: text/x-patch Size: 5668 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Make-VMODs-actually-fail-warm-ups.patch Type: text/x-patch Size: 7834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Catch-a-vcl.state-failure-on-the-manager-side.patch Type: text/x-patch Size: 6642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Simplify-vcl.use-by-making-it-failsafe.patch Type: text/x-patch Size: 3115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Replace-the-VCL-refcount-by-a-self-desribing-list.patch Type: text/x-patch Size: 10965 bytes Desc: not available URL: From phk at phk.freebsd.dk Fri Jan 8 23:10:11 2016 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 08 Jan 2016 23:10:11 +0000 Subject: vcl_dir/vmod_dir are now paths, and include "./xxx" works Message-ID: <17186.1452294611@critter.freebsd.dk> I've implemented these two features today, and because of some synergy between then, I ended up not using Kacpers patch for the "./" stuff, but I did use his VTC. Big Thanks! I belive this is backwards compatible, except for "./" now having a special meaning. There is one weird and one reasonable cornercase. The weird one is that a "-f vclfile" argument is opened and read with command-line privs, but the includes in that file are resolved using the VCC privs which could be a fair bit lower, so the includes may in fact not be readable. The reasonable one is that if the -f argument is not an absolute filename, including "./" relative to it will error out. vcc_unsafe_path now bans any '/' in filenames inside VCL (ie: 'include ...' and 'import ... from ...') I'm wondering if that check should really be ".." instead (more precisly: '^../' or '/../'). Input ? I made it possible to do import std from "/some/dir/"; If the filename ends in '/' the default .so filename will automatically be appended. Finally, note that with the path functionality, you can do things like; param.set vcl_dir "/something:/foo/bar:/other" include "foopkg/bar.vcl"; And get hold of the file "/foo/bar/foopkg/bar.vcl". This is intentional. -- 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 dridi at varni.sh Mon Jan 11 11:11:00 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 11 Jan 2016 12:11:00 +0100 Subject: [PATCH] VCL temperature improvements In-Reply-To: References:

Message-ID: > Same patches as last time, rebased against current master. I sneaked > in a trivial patch (0001) taking advantage of the review. Hi, As requested I pushed the patches 1 to 4 from the previous batch. The patch 2 was slightly amended to have peuso-enum symbols in upper case, I have pushed another similar change (see ad8d91f). The patch 4 was also amended to introduce two functions with distinct signatures instead of a single catch-all. Please find attached the remaining patches for the next review. The patches that have been accepted so far are only the prep work, actual fixes ahead! Cheers, Dridi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-VMODs-to-fail-a-warm-up.patch Type: text/x-patch Size: 5737 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Make-VMODs-actually-fail-warm-ups.patch Type: text/x-patch Size: 7834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Catch-a-vcl.state-failure-on-the-manager-side.patch Type: text/x-patch Size: 6660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Simplify-vcl.use-by-making-it-failsafe.patch Type: text/x-patch Size: 3482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Replace-the-VCL-refcount-by-a-self-desribing-list.patch Type: text/x-patch Size: 11024 bytes Desc: not available URL: From dridi at varni.sh Mon Jan 11 15:21:45 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 11 Jan 2016 16:21:45 +0100 Subject: [master] f4895da Split VCL event sender functions out individually. In-Reply-To: References: Message-ID: On Mon, Jan 11, 2016 at 3:54 PM, Poul-Henning Kamp wrote: > > commit f4895da5b08b83c2190ff96e2a6364e4699e962f > Author: Poul-Henning Kamp > Date: Mon Jan 11 14:53:48 2016 +0000 > > Split VCL event sender functions out individually. > > Dridi: Not XXX comments Please find answers below XXX comments. > static int > -vcl_setup_event(VRT_CTX, enum vcl_event_e ev) > +vcl_event_warm(VRT_CTX) > { > - > CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); > AN(ctx->handling); > AN(ctx->vcl); > - assert(ev == VCL_EVENT_LOAD || ev == VCL_EVENT_WARM || > - ev == VCL_EVENT_USE); > - > - if (ev == VCL_EVENT_LOAD) > - AN(ctx->msg); > + // AN/AZ(ctx->msg); // XXX: Dridi: which is it ? > + return (ctx->vcl->conf->event_vcl(ctx, VCL_EVENT_WARM)); > +} Currently only the LOAD event can fail so I check the availability of ctx->msg only in this case, so it's AN. > static void > -vcl_failsafe_event(VRT_CTX, enum vcl_event_e ev) > +vcl_event_cold(VRT_CTX) > { > + CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); > + AN(ctx->handling); > + AN(ctx->vcl); > + AZ(ctx->msg); > + AZ(ctx->vcl->conf->event_vcl(ctx, VCL_EVENT_COLD)); > +} During the VDD15Q4 discussions you asked me to use the WRONG macro to provide a human-friendly message instead of using AZ. > +static void > +vcl_event_discard(VRT_CTX) > +{ > CHECK_OBJ_NOTNULL(ctx, VRT_CTX_MAGIC); > AN(ctx->handling); > AN(ctx->vcl); > - assert(ev == VCL_EVENT_COLD || ev == VCL_EVENT_DISCARD); > + // AN/AZ(ctx->msg); // XXX: Dridi: which is it ? > + AZ(ctx->vcl->conf->event_vcl(ctx, VCL_EVENT_DISCARD)); > +} I did not test ctx->msg in the previous vcl_failsafe_event function because VMODs are not supposed to either fail or talk back to the CLI for these events. I'd say AZ but again, I'm not sure all code paths to cold/dispatch event handling *don't* allocate a vsb. > /* The VCL must first reach a stable cold state */ > else if (vcl->temp != VCL_TEMP_COOLING) { > vcl->temp = VCL_TEMP_WARM; > - (void)vcl_setup_event(ctx, VCL_EVENT_WARM); > + vcl_event_warm(ctx); // XXX: Dridi: what if it fails? > vcl_BackendEvent(vcl, VCL_EVENT_WARM); > } > break; It doesn't currently fail. This is handled in the next patch from the pending review we didn't have time to finish. As I said in today's email, this commit is only part of the prep work for fixing VCL temperature in 4.1 and master. It only breaks down code before the changes that will actually fix known issues and changes in behavior decided during the last two VDDs. The single decided change I didn't apply in the patch-set is the altogether removal of the USE event because this is meant for 4.1.x too. With regards to splitting the event dispatching into 5 different functions, I didn't see much value since I essentially see two kinds of events: the setup ones, and the ones that must not fail. Best, Dridi From dridi at varni.sh Mon Jan 11 17:38:16 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 11 Jan 2016 18:38:16 +0100 Subject: [PATCH] VCL temperature improvements In-Reply-To: References:

Message-ID: > Please find attached the remaining patches for the next review. The > patches that have been accepted so far are only the prep work, actual > fixes ahead! Following discussions on IRC, on top of these patches we want to enforce the presence or absence of (struct vrt_ctx).msg in the event sending functions. First things first, bug fixes and changes in semantics. Cheers, Dridi From guillaume at varnish-software.com Tue Jan 12 11:32:44 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Tue, 12 Jan 2016 12:32:44 +0100 Subject: H/2 VTC draft In-Reply-To: References: Message-ID: -- Guillaume Quintard On Fri, Dec 4, 2015 at 10:20 AM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > Hi all, > > One step toward H2/ in varnish is having a way to test it. So, here's a > draft proposal for the H/2 handling in varnishtest: > > https://github.com/gquintard/h2vtcspec/blob/master/h2_vtc.rst > > Hi all, and happy new year. I progressed on the implementation of H/2 in varnishtest. And while I'm still missing a few things, it seems to (mostly) work. I'm cleaning the code this week to publish something reviewable next week. In the meantime, I updated the draft proposal, that is now more of a documentation as most of it is implemented. But, I still have a big problem with the headers UI, so it would be good if some people could look at the document, be terribly frightened, and propose something saner. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dho at fastly.com Sat Jan 23 03:00:38 2016 From: dho at fastly.com (Devon H. O'Dell) Date: Sat, 23 Jan 2016 03:00:38 +0000 Subject: EINTR, vev, and mgt_cli Message-ID: I came across a rather interesting (but probably super low priority) bug in our Varnish tree recently while integrating some monitoring tools, and it appears to still be present in Varnish 4. In particular, if the manager receives a signal that is handled by the vev interface while it is waiting for a CLI response from a blocked child, it is possible that the manager blocks forever. This can happen when the following events occur: Manager goes into mgt_cli_askchild, which calls VCLI_ReadResult. This calls read_tmo, which calls poll(2), waiting for the child to put data on the fd. The child gets the CLI request, and this causes the child to go catatonic without crashing for whatever reason (let's say it's blocked in a syscall as a strawman). The manager receives a signal (let's say SIGTERM or SIGINT, since those have vev handlers associated) before poll(2) times out. Vev's signal handler is run, setting up the signal for asynchronous processing. After exiting the signal handler, poll(2) returns -1 with errno being EINTR (but poll(2) is not restartable, so SA_RESTART doesn't help the situation). Read_tmo does not check poll(2) returning an error, and so it happily continues into the read(2) call, which will never return because the child will never write data onto the fd because its CLI thread is stuck. In the meanwhile, all other threads in the child that are not blocked continue happily, so traffic is still served (which could be a bad thing; maybe you urgently need to ban an object). Even worse, the manager will not be able to restart the child without taking another signal to get it out of the read(2), which is at least non-obvious. But a frustrated administrator might simply SIGKILL the manager and child. I get that the normal use case of Varnish is unlikely to see this issue, but debugging it isn't likely to be easy for an administrator. I think therefore it's worth fixing, but I'm not entirely sure what the correct fix is for upstream purposes. What I've done in our tree is manage the timeout outside of poll(2) when it returns EINTR, and either restart for the remainder of the time, or simply return -1 with ETIMEDOUT. But there are two problems: * When the timeout is zero, we theoretically bock indefinitely. The problem here is that restarting the poll(2) will exhibit the same behavior of blocking forever as long as the child CLI continues not to produce data. However, treating EINTR as an error here has the possibility of desynchronizing the manager from the child if the child ever produces a result. (However, if it does not, at least the manager will reap it when its next ping fails.) * It is unclear whether there are any consumers of libvarnish not using vev who expect this behavior in read_tmo (though I struggle to come up with a practical case that relies on continuing into read(2) after EINTR). Does upstream Varnish even consider this a problem? if so, does anybody have ideas for a better solution if the one I've implemented is not desirable? (I've implemented the time delta check in our Varnish since we don't have cases that do not time out, and we have infrastructure for resynchronizing the CLI channel with a cookie.) --dho -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at varnish-software.com Sun Jan 24 14:14:48 2016 From: guillaume at varnish-software.com (Guillaume Quintard) Date: Sun, 24 Jan 2016 15:14:48 +0100 Subject: H/2 VTC draft In-Reply-To: References:

Message-ID: If people want to look at my current varnishtest/h2 code, the branch is here: https://github.com/gquintard/Varnish-Cache/tree/WIP/h2test A few things are still missing, but I'm interested in some feedback. You can find some syntax examples in bin/varnishtest/h2tests for a quick overview. -- Guillaume Quintard On Tue, Jan 12, 2016 at 12:32 PM, Guillaume Quintard < guillaume at varnish-software.com> wrote: > > > -- > Guillaume Quintard > > On Fri, Dec 4, 2015 at 10:20 AM, Guillaume Quintard < > guillaume at varnish-software.com> wrote: > >> Hi all, >> >> One step toward H2/ in varnish is having a way to test it. So, here's a >> draft proposal for the H/2 handling in varnishtest: >> >> https://github.com/gquintard/h2vtcspec/blob/master/h2_vtc.rst >> >> Hi all, and happy new year. > > I progressed on the implementation of H/2 in varnishtest. And while I'm > still missing a few things, it seems to (mostly) work. I'm cleaning the > code this week to publish something reviewable next week. In the meantime, > I updated the draft proposal, that is now more of a documentation as most > of it is implemented. > > But, I still have a big problem with the headers UI, so it would be good > if some people could look at the document, be terribly frightened, and > propose something saner. > > Cheers! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi at varni.sh Thu Jan 28 11:20:30 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 28 Jan 2016 12:20:30 +0100 Subject: New (be)req fields: path scheme and authority Message-ID: Hi all, I'm starting a discussion that will hopefully lead to a VIP. I have pondered this one for quite a while now and trac #1847 convinced me that I should share this with the -dev list. I predict it will be one of those long emails I'm very good at not synthesizing. The proposal is to have new request fields: - req.path (the absolute path) - req.host (the virtual host) - req.authority This is based on my understanding of HTTP/1.1 and it seems like it'd play nicely with HTTP/2 but I'm not done studying the latter. In HTTP/1.1 a request starts[1] with a request-line: method SP request-target SP HTTP/1.1 CRLF The request-target is a URI[2] that can take several forms: request-target = origin-form => the path, /something / absolute-form => [scheme]://[authority][path] / authority-form => host name for CONNECT / asterisk-form => an actual * for OPTIONS The problem with the absolute-form is that Varnish is not supposed to receive this kind of request because they are meant for forward proxies, but it MUST [5] be handled regardless. The good thing with the absolute-form is that it integrates nicely with HTTP/2 [3] since all its components map to pseudo headers. The other thing that Varnish should do with absolute-form URIs is to ignore[4] host headers and use the absolute-form authority as such. One may ask where we should store the asterisk-form, and HTTP/2 says it belongs in the path[3]. How would it work? For HTTP/1.1 Varnish would dissect the request and populate the following fields: - req.url => request-target - req.path => origin form OR asterisk-form OR path from absolute-form - req.authority => authority-form OR authority from absolute-form OR host header - req.scheme => scheme from absolute-form OR "http" For HTTP/2 I suppose we could reconstruct an absolute-form with the pseudo headers from the new fields, since we'd get them as pseudo headers[3]. Changes in the built-in VCL: sed -e s/req.url/req.path/ -e s/req.http.host/req.authority/ Security concerns: Mainly, how to deal with an "https" scheme? And for that I'd shift the responsibility to the user/documentation. If you have a trusted TLS or HTTPS proxy you can always route the decrypted traffic to a different port and check it when req.scheme == "https". Breaking changes: On top of the breaking changes (only the built-in VCL, i thnik) I wouldn't mind renaming req.url to req.target but not because I like to break things for the sake of breaking them (but I do like breaking stuff). The rationale is that since the request-target is not necessarily a URL, that would be the occasion of getting better semantics wrt to the RFCs (like req.request that became req.method) and also make sure that VCL wouldn't compile and give you subtle bugs because of changes in the built-in VCL. Thoughts? Best, Dridi [1] https://tools.ietf.org/html/rfc7230#section-3.1.1 [2] https://tools.ietf.org/html/rfc7230#section-5.3 [3] https://tools.ietf.org/html/rfc7540#section-8.1.2.3 [4] https://tools.ietf.org/html/rfc7230#section-5.4 [5] https://tools.ietf.org/html/rfc7230#section-5.3.2 From lkarsten at varnish-software.com Thu Jan 28 12:56:38 2016 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Thu, 28 Jan 2016 13:56:38 +0100 Subject: Release procedure documented in the wiki. Message-ID: <20160128125636.GA5462@immer.varnish-software.com> Hi. As requested, I've written down the steps necessary for doing a release in the wiki. Not that I personally care much about this after (slash if)) I'm hit by a bus and can't do the releases any more, but maybe some of you do. :-) I've left out the signing parts since this is a public document. Link follows: https://www.varnish-cache.org/trac/wiki/Release_procedure -- Lasse Karstensen Varnish Software AS From dridi at varni.sh Thu Jan 28 13:56:55 2016 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 28 Jan 2016 14:56:55 +0100 Subject: New (be)req fields: path scheme and authority In-Reply-To: References: Message-ID: > The proposal is to have new request fields: > - req.path (the absolute path) > - req.host (the virtual host) > - req.authority Guillaume pointed out that as we say in French I tangled my brushes up. What I meant was: - req.path (the absolute path) - req.scheme (http or https) - req.authority (the virtual host) Sorry about that, I was writing the previous message in a hurry and I missed it when I reviewed it before pressing the send button. All the best, Dridi From fgsch at lodoss.net Thu Jan 28 18:12:11 2016 From: fgsch at lodoss.net (Federico Schwindt) Date: Thu, 28 Jan 2016 18:12:11 +0000 Subject: [PATCH] Add support for REAL [+-] REAL operations Message-ID: Hi, Someone on #varnish mentioned the need for this. Personally I can't think of any reason for not allowing it. Comments? OK? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-REAL-REAL-operations.patch Type: text/x-patch Size: 1221 bytes Desc: not available URL: