[Varnish] #1221: 304 not modified response with body makes next request fail

Varnish varnish-bugs at varnish-cache.org
Mon Oct 29 22:54:44 CET 2012

#1221: 304 not modified response with body makes next request fail
 Reporter:  tmagnien          |       Owner:
     Type:  defect            |      Status:  closed
 Priority:  normal            |   Milestone:
Component:  build             |     Version:  3.0.2
 Severity:  normal            |  Resolution:  worksforme
 Keywords:  304 chunked body  |
Changes (by phk):

 * status:  new => closed
 * resolution:   => worksforme


 RFC2616 makes it painfully clear that this is a bug in the backends

 4.4 Message Length

    The transfer-length of a message is the length of the message-body as
    it appears in the message; that is, after any transfer-codings have
    been applied. When a message-body is included with a message, the
    transfer-length of that body is determined by one of the following
    (in order of precedence):

    1.Any response message which "MUST NOT" include a message-body (such
      as the 1xx, 204, and 304 responses and any response to a HEAD
      request) is always terminated by the first empty line after the
      header fields, regardless of the entity-header fields present in
      the message.

 I'm not quite sure if you can work around this from VCL, you probably can
 from inline-C or a VMOD by marking the backend connection as "to be
 closed" behind the back of the normal logic.

 If you want to write a patch which makes varnish detect this bogus
 behaviour, please submit it to the -dev mailing list, but put a reference
 to this ticket in the description, even though I am closing the ticket

Ticket URL: <https://www.varnish-cache.org/trac/ticket/1221#comment:2>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator

More information about the varnish-bugs mailing list