[Varnish] #233: Backend responses with no Content-Length header

[Varnish]

#233: Backend responses with no Content-Length header
----------------------------+-----------------------------------------------
 Reporter:  afnid           |        Owner:  phk  
     Type:  defect          |       Status:  new  
 Priority:  normal          |    Milestone:       
Component:  varnishd        |      Version:  1.1.2
 Severity:  normal          |   Resolution:       
 Keywords:  Content-Length  |  
----------------------------+-----------------------------------------------
Old description:

> When the content-length header is missing, the length defaults to zero
> and the object does not get cached or sent to the client.
>
> If I set the state to pipe in the vcl.conf, the content get's passed to
> the client correctly.
>
> So why is there no Content-Length header?  In my case I have a Java
> application server that does will dynamically generate a resized image
> from a master image based on the request, and using varnish to cache the
> resized images.  When possible, the application server uses 'convert' to
> create the image and pass it through to the client, so the content length
> is not known ahead of time.  If I buffer the images in my app-server and
> set a correct Content-Length header and everything works as expected.
>
> Viewing the image through a direct connection to the app server using
> firefox worked fine, so did viewing the image through a pound server that
> bypassed varnish.  I have a work-around, just not as memory efficient as
> I would like, and if I was dealing with larger images, I would have to
> cache them to disk, and would defeat any reason to use varnish at all.
>

> Here is the tail-end of the log:
>
>    17 ObjProtocol  c HTTP/1.1
>    17 ObjStatus    c 200
>    17 ObjResponse  c OK
>    17 ObjHeader    c Server: Winstone Servlet Engine v0.9.10
>    17 ObjHeader    c Expires: Wed, 30 Apr 2008 18:06:28 GMT
>    17 ObjHeader    c Content-Type: image/jpeg
>    17 ObjHeader    c Date: Sun, 27 Apr 2008 18:06:28 GMT
>    17 ObjHeader    c X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
>    17 TTL          c 1336541393 RFC 259199 1209319588 1209319588
> 1209578788 0 0
>    17 VCL_call     c fetch insert
>    17 Length       c 0
>    17 VCL_call     c deliver deliver
>    17 TxProtocol   c HTTP/1.1
>    17 TxStatus     c 200
>    17 TxResponse   c OK
>    17 TxHeader     c Server: Winstone Servlet Engine v0.9.10
>    17 TxHeader     c Expires: Wed, 30 Apr 2008 18:06:28 GMT
>    17 TxHeader     c Content-Type: image/jpeg
>    17 TxHeader     c X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
>    17 TxHeader     c Date: Sun, 27 Apr 2008 18:06:28 GMT
>    17 TxHeader     c X-Varnish: 1336541393
>    17 TxHeader     c Age: 0
>    17 TxHeader     c Via: 1.1 varnish
>    17 TxHeader     c Connection: keep-alive
>    17 ReqEnd       c 1336541393 1209319588.402075768 1209319588.478549719
> 0.005740166 0.076447487 0.000026464

New description:

 When the content-length header is missing, the length defaults to zero and
 the object does not get cached or sent to the client.

 If I set the state to pipe in the vcl.conf, the content get's passed to
 the client correctly.

 So why is there no Content-Length header?  In my case I have a Java
 application server that does will dynamically generate a resized image
 from a master image based on the request, and using varnish to cache the
 resized images.  When possible, the application server uses 'convert' to
 create the image and pass it through to the client, so the content length
 is not known ahead of time.  If I buffer the images in my app-server and
 set a correct Content-Length header and everything works as expected.

 Viewing the image through a direct connection to the app server using
 firefox worked fine, so did viewing the image through a pound server that
 bypassed varnish.  I have a work-around, just not as memory efficient as I
 would like, and if I was dealing with larger images, I would have to cache
 them to disk, and would defeat any reason to use varnish at all.


 Here is the tail-end of the log:
 {{{
    17 ObjProtocol  c HTTP/1.1
    17 ObjStatus    c 200
    17 ObjResponse  c OK
    17 ObjHeader    c Server: Winstone Servlet Engine v0.9.10
    17 ObjHeader    c Expires: Wed, 30 Apr 2008 18:06:28 GMT
    17 ObjHeader    c Content-Type: image/jpeg
    17 ObjHeader    c Date: Sun, 27 Apr 2008 18:06:28 GMT
    17 ObjHeader    c X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
    17 TTL          c 1336541393 RFC 259199 1209319588 1209319588
 1209578788 0 0
    17 VCL_call     c fetch insert
    17 Length       c 0
    17 VCL_call     c deliver deliver
    17 TxProtocol   c HTTP/1.1
    17 TxStatus     c 200
    17 TxResponse   c OK
    17 TxHeader     c Server: Winstone Servlet Engine v0.9.10
    17 TxHeader     c Expires: Wed, 30 Apr 2008 18:06:28 GMT
    17 TxHeader     c Content-Type: image/jpeg
    17 TxHeader     c X-Powered-By: Servlet/2.5 (Winstone/0.9.10)
    17 TxHeader     c Date: Sun, 27 Apr 2008 18:06:28 GMT
    17 TxHeader     c X-Varnish: 1336541393
    17 TxHeader     c Age: 0
    17 TxHeader     c Via: 1.1 varnish
    17 TxHeader     c Connection: keep-alive
    17 ReqEnd       c 1336541393 1209319588.402075768 1209319588.478549719
 0.005740166 0.076447487 0.000026464
 }}}

-- 
Ticket URL: <http://varnish.projects.linpro.no/ticket/233#comment:1>
Varnish <http://varnish.projects.linpro.no/>
The Varnish HTTP Accelerator