-
Justin Erenkrantz authored
let us later throw away the renegotiated content due to a name mismatch. We do not need to update the ->name field just before writing the headers as the computed ->name on open and create is sufficient. Updating ->name here is essentially a no-op - except in the case of Vary where the key has internally changed (to account for the Vary prefix), but the original name has not. However, writing the Vary'd-accounted key means that when we read the cache next that we will error out and disregard the just renegotiated response and fetch the content all over again - oops! (This is largely a case where I think we may have overthought ourselves; hence the explanation is here in the commit rather than in the file itself.) * modules/cache/mod_disk_cache.c (store_headers): The originally opened ->name is sufficient. * CHANGES: Combined with r538992, note that renegotiation for Vary's seem to work far better. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@538997 13f79535-47bb-0310-9956-ffa450edef68
373dc75a
To find the state of this project's repository at the time of any of these versions, check out the tags.