Mailing List Archive

#1797: Content-Type/Content-Length should miss on 304 requests
------------------------+--------------------
Reporter: shakalandy | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: varnishd | Version: 4.0.3
Severity: normal | Resolution:
Keywords: |
------------------------+--------------------

Comment (by shakalandy):

Ticket summary should be "ontent-Type/Content-Length should miss on 304
responses" - sorry!

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

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1797: Content-Type/Content-Length should miss on 304 requests
------------------------+--------------------
Reporter: shakalandy | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: varnishd | Version: 4.0.3
Severity: normal | Resolution:
Keywords: |
------------------------+--------------------

Comment (by fgsch):

Some details from RFC7232 4.1 p19:

{{{
The server generating a 304 response MUST generate any of the
following header fields that would have been sent in a 200 (OK)
response to the same request: Cache-Control, Content-Location, Date,
ETag, Expires, and Vary.

Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, a
sender SHOULD NOT generate representation metadata other than the
above listed fields unless said metadata exists for the purpose of
guiding cache updates (e.g., Last-Modified might be useful if the
response does not have an ETag field).
}}}

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

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1797: Content-Type/Content-Length should miss on 304 requests
------------------------+-----------------------
Reporter: shakalandy | Owner: fgsch
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: varnishd | Version: 4.0.3
Severity: normal | Resolution:
Keywords: |
------------------------+-----------------------
Changes (by fgsch):

* status: new => assigned
* owner: => fgsch


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

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs

#1797: Content-Type/Content-Length should miss on 304 requests
------------------------+----------------------
Reporter: shakalandy | Owner: fgsch
Type: defect | Status: closed
Priority: normal | Milestone:
Component: varnishd | Version: 4.0.3
Severity: normal | Resolution: invalid
Keywords: |
------------------------+----------------------
Changes (by fgsch):

* status: assigned => closed
* resolution: => invalid


Comment:

I've had some long thought about this.

The Content-Length part is already done in 4.1, minus the zero Content-
Length case.
The latter is fixed in master.

Specific headers aside, as the text from RFC7232 4.1 states, the goal here
is to minimize information transfer. I don't see how this could affect
upstream caches and/or force unnecessary revalidations. It's also worth
noting that while perhaps not ideal, it's not prohibited (SHOULD NOT as
opposed to MUST NOT).

As such I feel this falls into the feature request category. A better
place to raise this would be:

https://www.varnish-cache.org/trac/wiki/Future_Feature.

If you are adamant on this point, you can always unset the headers in VCL.

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

_______________________________________________
varnish-bugs mailing list
varnish-bugs@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-bugs