[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Last-Modified HTTP header in GET responses

From: Branko ─îibej <brane_at_apache.org>
Date: Thu, 31 Dec 2015 11:11:37 +0100

On 30.12.2015 15:50, Ivan Zhakov wrote:
> Currently mod_dav_svn sets ETag and Last-Modified HTTP headers for GET
> responses. These headers are optional and and are not used by
> Subversion client. But they used by browsers and intermediate proxies
> to cache responses.
> ETag header is cheap to construct: it's just last modification
> revision number of the node.
> Last-Modified header is relatively expensive to calculate: it's
> svn:date revision property of revision where path was modified.
> Revision properties are mutable and cannot be cached effectively.The
> other minor problem with Last-Modified header: svn:date revision
> property can be changed to any value, while RFC 7223 requires
> Last-Modified date to be earlier than the server's time of message
> origination (Date) [1]
> All browsers support ETag header (it's HTTP/1.1 header) and RFC 7232
> recommends to prefer using ETag instead of Last-Modified [2].
> Given all above I propose to stop adding Last-Modified header for HTTP
> GET responses.

Your analysis looks sound, but I wonder if doing this would have any
serious effect on checkout/update times; after all, the bulk of the work
there is in report generation, only HTTPv2 is affected by GET response

The only really valid reason for removing that code is your point that
we can't guarantee compliance of the Last-Modified header value compared
with the Date header value. There's another solution for that ... we
could check those values in mod_dav_svn and adjust Last-Modified if

FWIW, I'm not pushing for keeping the Last-Modified header: just
exploring other possibilities. Clearly, removing that code (as in your
patch) is the simplest solution.

-- Brane
Received on 2015-12-31 11:11:40 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.