How to enable and test CQ’s permission sensitive caching

How to enable and test CQ’s permission sensitive caching:
In this blog post I would like to extend on the permission sensitive caching knowledge base item documented at:
http://dev.day.com/content/kb/home/cq5/CQ5SystemAdministration/PSCachingDelivery.html
One thing to note is that the auth_checker configuration should be placed under the site configuration (usually under the farm entry). Here’s an example:

# each farm configures a set off (loadbalanced) renders
/farms
  {
  # first farm entry (label is not important, just for your convenience)
  /website
    {
    # Authorization checker: before a page in the cache is delivered, a HEAD
    # request is sent to the URL specified in 'url' with the query string
    # '?uri='. If the response status is 200 (OK), the page is returned
    # from the cache. Otherwise, the request is forwarded to the render and
    # its response returned.
    /auth_checker
      {
      # request is sent to this URL with '?uri=' appended
      /url "/bin/permissioncheck.html"

      # only the requested pages matching the filter section below are checked,
      # all other pages get delivered unchecked
      /filter
        {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "*.html"
          /type "allow"
          }
        }
      # any header line returned from the auth_checker's HEAD request matching
      # the section below will be returned as well
      /headers
        {
        /0000
          {
          /glob "*"
          /type "deny"
          }
        /0001
          {
          /glob "Set-Cookie:*"
          /type "allow"
          }
        }
      }
      # client headers which should be passed through to the render instances
      # (feature supported since dispatcher build 2.6.3.5222)
      /clientheaders
        {
...

Testing
To test the PermissionHeadServlet created for permission sensitive caching delivery purposes, the curl command would be your friend. Here are some examples of the commands to retrieve the authentication status on a “locked-down” item in DAM:
[Without Proper Authentication]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf

And here’s the result:

HTTP/1.1 403 Forbidden
Connection: Close
Server: Day-Servlet-Engine/4.1.17
Content-Type: text/plain;charset=UTF-8
Date: Sat, 19 May 2012 18:17:36 GMT
Transfer-Encoding: chunked
X-Reason: Authentication Failed
Set-Cookie: JSESSIONID=c6a8de36-be69-4e9d-8706-df4bd79c3062; Path=/; HttpOnly

[With Proper username/password]:

$ curl --head http://_pubserver_:_port_/content/dam/testsite/documents/sensitive_doc.pdf --user admin:admin

And here’s the result:

HTTP/1.1 200 OK
Connection: Keep-Alive
Server: Day-Servlet-Engine/4.1.17
Content-Type: application/pdf
Content-Length: 758951
Date: Sat, 19 May 2012 18:25:07 GMT
Last-Modified: Wed, 07 Mar 2012 00:14:39 GMT

DIGITAL JUICE