Synthetic objects

[Dridi Boukelmoune]

Hi,

I'm not sure I understand the purpose, is it for a separations of:
- true errors (from backends/varnish or hand made)
- on-the-fly static responses (redirects, static files...)

In this case it could be interesting to jump to vcl_backend_synth from vcl_recv:
if (req.url ~ "...") {
  return(synth(42302));
}

The syntax looks inconsistent, I'd rather have something like:
return(transition [, args])

Examples:
return(lookup);
return(synth, 10001404);
return(error, 10001503);
return(error, 10001503, "message");

It would also help to have constants for magic status codes:
===
// outside of sub functions
const BACKEND_DOWN = 503;
const MAINTENANCE = 1503;

sub vcl_backend_response {
  if (beresp looks maintenance-ish) {
    return(error, MAINTENANCE);
  }
}

sub vcl_error {
  if (obj.status == BACKEND_DOWN) {
    synthetic "dammit";
  }
  if (obj.status == MAINTENANCE) {
    synthetic std.fileread("maintenance.html");
  }
}
===

About Varnish turning into a web server, there's nothing to worry
about with just that, synthetic+std.fileread can't handle most
binary files.

Best Regards,
Dridi

On Wed, Jul 3, 2013 at 2:39 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <CANTTouWnQnqtL6N5z=roCe-zxju=wdtOie-a7xwkmo1=CijKtw at mail.gmail.com>
> , "Rogier 'DocWilco' Mulhuijzen" writes:
>
>>If we're changing things, it would be useful to have something in synth
>>other than a 3 digit status code.
>
> We came up with an idea for this in the IRC channel:
>
> We'll allow any number of digits (up to 32bits) but only the last
> three will be used for the HTTP status code.
>
> So you could for instance do
>         return (synth(10001404));
>
> and that would become a 404, but you get extra bits for your
> own purposes.
>
> Also, please notice that you have bereq to look at.
>
>
> --
> 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-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev