HTTPie: a CLI, cURL-like tool for humans

Loading

HTTPie is available on Linux, Mac OS X and Windows. On a Debian or Ubuntu system HTTPie can be installed with apt-get install httpie. For other platforms, see http://httpie.org.

Testing httpie is simple:

http -p Hh http://www.atomictag.com
GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: www.atomictag.com
User-Agent: HTTPie/0.9.2
   
HTTP/1.1 200 OK
CF-RAY: 250beb7295742666-FRA
Cache-Control: max-age=0, public
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Sun, 06 Dec 2015 23:55:06 GMT
ETag: W/"7524-526422bb3df6c"
Expires: Sun, 06 Dec 2015 23:55:06 GMT
Last-Modified: Sun, 06 Dec 2015 22:22:06 GMT
Pragma: public
Server: cloudflare-nginx
Set-Cookie: __cfduid=dad70ed346cbd17091806e91a67d56c1f1449446106; expires=Mon, 05-Dec-16 23:55:06 GMT; path=/; domain=.atomictag.com; HttpOnly
Transfer-Encoding: chunked
Vary: Accept-Encoding,Cookie

The -p option to http can be used to control output. Specifically:

-p H will print request headers.
-p h will print response headers.
-p B will print request body.
-p b will print response body.

 

Varnish Cache update 4.1

Loading

Improved Security and Proxy Support Complement Streaming Architecture, Which Cuts Down of Delivery Times for Larger Objects and Decreased Latency When Accessing Content Through Cache Hierarchies

Updates to Varnish Cache 4.1 include:

Proactive security features

  • Support for different kinds of privilege separation methods, collectively described as jails.
  • Ability for Varnish parent process on most systems to drop effective privileges to normal user mode when not doing operations needing special access;
  • Varnish worker child is enabled to run as a separate vcache user;
  • varnishlog, varnishncsa and other Varnish shared log utilities now must be run in a context with varnish group membership.

PROXY protocol support

  • Socket support for PROXY protocol connections has been added whereby PROXY defines a short preamble on the TCP connection where (usually) a SSL/TLS terminating proxy can signal the real client address.
  • The -a startup argument syntax has been expanded to allow for this: $ varnishd -f /etc/varnish/default.vcl -a :6081 -a 127.0.0.1:6086,PROXY.
  • Both PROXY1 and PROXY2 protocols are supported on the resulting listening socket.
  • For connections coming in over a PROXY socket, client.ip and server.ip will contain the addresses given to Varnish in the PROXY header/preamble (the “real” IPs).
  • The new VCL variables remote.ip and local.ip contains the local TCP connection endpoints. On non-PROXY connections these will be identical to client.ip and server.ip.
  • An expected pattern following this is if (std.port(local.ip) == 80) { } in vcl_recv to see if traffic came in over the HTTP listening socket (so a client redirect to HTTPS can be served).

Warm and cold VCL configurations — Traditionally Varnish has had the concept of active and inactive loaded VCLs. Any loaded VCL lead to state being kept, and a separate set of health checks (if configured) were being run against the backends. To avoid the extra state and backend polling, a loaded VCL is now either warm or cold. Runtime state (incl. backend counters) and health checks are not present for cold VCLs. A warm VCL will automatically be set to cold after vcl cool down seconds.

VMOD backends – Before Varnish 4.1, backends could only be declared in native VCL. Varnish 4.0 moved directors from VCL to VMODs, and VMODs can now also create backends. It is possible to both create the same backends as VCL but dynamically, or create backends that don’t necessarily speak HTTP/1 over TCP to fetch resources.

Backend connection timeout – Backend connections will now be closed by Varnish after backend idle timeout seconds of inactivity. Previously they were kept around forever and the backend servers would close the connection without Varnish noticing it. On the next traffic spike needing these extra backend connections, the request would fail, perhaps multiple times, before a working backend connection was found/created.

Varnish Cache is open source, available under a two-clause BSD license. Varnish Software also delivers additional software and support for more advanced users via subscriptions for Varnish Plus, its premium product. See here.

Online resources

You can download Varnish Cache 4.1 here.

Further details on Varnish Cache 4.1 can be found here.

Partner Event in Milan: all things Varnish and how Conde Nast uses Varnish Plus

Loading

The Varnish Software and Fulltechnology Partner Conference on 17th September in Milan, Italy is fast approaching! Here are some highlights we want to share with you.

You will have the opportunity to meet both Lars Larsson, CEO of Varnish Software, and Francesco Meani, CEO of Fulltechnology at the conference.

We are also excited to announce that the leading global mass media giant Conde Nast will speak at the event and share their user experience with Varnish Plus. Conde Nast Italy’s CTO, Giuseppe Serrecchia, will present real-life examples of how Conde Nast has developed and used Varnish Plus to meet their specific needs and what the outcomes were. Read more about in our blog post.

If you’re curious about the more technical aspects of Varnish Plus in action including tips and tricks for using Varnish Plus as an advanced load balancer and administration console (Varnish Administration Console), this event is your chance to learn. Fulltechnology, a leading interactive and technology player that designs, builds and executes software platforms, will augment the real-world Varnish Plus information with its own commercial and technical insights.

The program includes:

  • Tips & tricks for using Varnish as an advanced load-balancer and VAC
  • The benefits of Varnish Plus and its latest addition SSL/TLS
  • Commercial and technical insights from Fulltechnology
  • Condé Nast business case study and their user experience with Varnish
  • After event drinks and networking


Space is limited, so sign up now to participate at this conference.

Add to my calendar

To receive updates about the event and information about guest speakers, you can follow our blog here.

We are looking forward to meeting you in Milan!

Force redirect in Varnish

Loading

Sometimes in certain occasion you need to manage a complete redirection to an external site directly from Varnish.

Following you will find how to implement this using Varnish 4.0 and some specific rules in the VCL.


sub force_redirect {
   set req.http.host = "www.atomictag.com";
   return(synth(750, "Force redirection to external site."));
}

sub vcl_recv {
   # Force redirect
   call force_redirect;
   # Everything else will be ignored
}

sub vcl_synth {
   # Managing redirection
   if (resp.status == 750) {
      set resp.status = 301;
      set resp.http.Location = "http://www.atomictag.com/";
      return(deliver);
   }
}

Of course you can easily add more intelligence to the VCL, e.g.: by evaluating the redirection based on the http referrer or on a specific hostname.

SSL in Varnish Cache Plus

Loading

Varnish Software announced that they finished implementing SSL in Varnish Cache Plus.

The release will happen at at Varnish summit in Silicon Valley in early June.

Varnish Cache Plus is both a HTTP server and a HTTP client and both implementations will have SSL enabled. The HTTP Server, ie the client facing SSL is perhaps the most significant one, enabling Varnish Cache Plus to encrypt traffic between the client and Varnish.

Read more at: SSL in Varnish Cache Plus

Enable VCL variables logging

Loading

Varnish Cache offers several ways to log and most of the documentation is related to varnishlog which includes several information related to request, response and backend response. Now what’s happen if we need to log our own variables or message to a file?

The key function is std.syslog enabled via std (standard) Varnish module, which is the only built-in “vmod” and is thus natively available and doesn’t have to be compiled.

 import std; 

then you can easily add into your VCL the following line:


std.syslog(180, "log description");

The first parameter, 180, is the priority value. If you want to add some variables to your log message:


std.syslog(180, "log description" + beresp.ttl);

This will logo the message to general system log, which is often, in a Linux system, is located in /var/log/messages.

Monitoring heart beat in Varnish Cache

Loading

In order to know Varnish Cache if is running and able to handle HTTP requests properly, without having the backends as part the equation please add the following VCL snippet makes sure that the URL /heart-beat always returns 200:

Varnish 4 equivalent:


sub vcl_recv {
if (req.method == "GET" && req.url == “/heart-beat") {
   return(synth(200, "OK"));
   }
}

Varnish 3 equivalent:


sub vcl_recv {
if (req.request == "GET" && req.url == "/heart-beat") {
    error 200 "OK";
   }
}

You may want to protect the URL by using ACLs if you don’t want to expose /heart-beat to the public.

Please see original page: https://www.varnish-software.com/blog/blog-sysadmin-monitoring-health-varnish-cache

vclFiddle for Varnish Cache

Loading

vclFiddle, is a free online tool for experimenting with the Varnish Cache HTTP reverse-proxy in a sandboxed environment where you can reproduce a website caching scenario for testing, collaborative debugging, or just trying new ideas, with the least friction possible.

You can use it now at http://www.vclfiddle.net and it is open-sourced on GitHub too.

vcl-fiddle

vcl-fiddle