Commit 97806556 authored by Tollef Fog Heen's avatar Tollef Fog Heen

Merge r5167: rewrite beresp/obj.cacheable (thanks DocWilco) and fixed some formatting errors


git-svn-id: http://www.varnish-cache.org/svn/branches/2.1@5342 d4fa192b-c00b-0410-8231-f00ffab90ce4
parent 4a28167c
......@@ -33,7 +33,7 @@ OPTIONS
=======
-a address[:port][,address[:port][...]
Listen for client requests on the specified address and port. The address can be a host
Listen for client requests on the specified address and port. The address can be a host
name (“localhost”), an IPv4 dotted-quad (“127.0.0.1”), or an IPv6 address enclosed in
square brackets (“[::1]”). If address is not specified, varnishd will listen on all
available IPv4 and IPv6 interfaces. If port is not specified, the default HTTP port as
......@@ -93,24 +93,30 @@ OPTIONS
Offer a management interface on the specified address and port. See Management
Interface for a list of management commands.
-t ttl Specifies a hard minimum time to live for cached documents. This is a shortcut for
-t ttl
Specifies a hard minimum time to live for cached documents. This is a shortcut for
specifying the default_ttl run-time parameter.
-u user Specifies the name of an unprivileged user to which the child process should switch
before it starts accepting connections. This is a shortcut for specifying the user run-
time parameter.
-u user Specifies the name of an unprivileged user to which the child
process should switch before it starts accepting
connections. This is a shortcut for specifying the user
run- time parameter.
If specifying both a user and a group, the user should be specified first.
If specifying both a user and a group, the user should be
specified first.
-V Display the version number and exit.
-w min[,max[,timeout]]
Start at least min but no more than max worker threads with the specified idle timeout.
This is a shortcut for specifying the thread_pool_min, thread_pool_max and
Start at least min but no more than max worker threads
with the specified idle timeout. This is a shortcut for
specifying the thread_pool_min, thread_pool_max and
thread_pool_timeout run-time parameters.
If only one number is specified, thread_pool_min and thread_pool_max are both set to
this number, and thread_pool_timeout has no effect.
If only one number is specified, thread_pool_min and
thread_pool_max are both set to this number, and
thread_pool_timeout has no effect.
......
......@@ -23,7 +23,7 @@ The varnishtest program is a script driven program used to test the
varnish HTTP accelerator.
The varnishtest program, when started and given one or more script
files, can create a number of threads repre senting backends, some
files, can create a number of threads representing backends, some
threads representing clients, and a varnishd process.
The following options are available:
......
......@@ -515,19 +515,20 @@ beresp.status
The HTTP status code returned by the server.
beresp.response
The HTTP status message returned by the server.
The HTTP status message returned by the server.
beresp.cacheable
True if the request resulted in a cacheable response. A response is
considered cacheable if it is valid (see above), and the HTTP status
code is 200, 203, 300, 301, 302, 404 or 410.
considered cacheable if it has no Set-Cookies or Authentication,
and the HTTP status code is 200, 203, 300, 301, 302, 404 or 410.
beresp.cacheable is writable.
beresp.ttl
The object's remaining time to live, in seconds.
The object's remaining time to live, in seconds. beresp.ttl is writable.
After the object is entered into the cache, the following (mostyl
After the object is entered into the cache, the following (mostly
read-only) variables are available when the object has been located in
cache:
cache, typically in vcl_hit and vcl_deliver.
obj.proto
The HTTP protocol version used when the object was retrieved.
......@@ -536,15 +537,14 @@ obj.status
The HTTP status code returned by the server.
obj.response
The HTTP status message returned by the server.
The HTTP status message returned by the server.
obj.cacheable
True if the request resulted in a cacheable response. A response is
considered cacheable if it is valid (see above), and the HTTP status
code is 200, 203, 300, 301, 302, 404 or 410.
True if the object had beresp.cacheable. Unless you've forced delivery
in your VCL obj.cacheable will always be true.
obj.ttl
The object's remaining time to live, in seconds.
The object's remaining time to live, in seconds. obj.ttl is writable.
obj.lastuse
The approximate time elapsed since the object was last requests, in
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment