Skip to content
  • Justin Erenkrantz's avatar
    mod_disk_cache: When renegotiating an already cached Vary'd response, do not · 373dc75a
    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.