Re: [PATCH] mod_cache 304 on HEAD (bug 41230)
mån 2007-04-16 klockan 22:58 +0200 skrev Ruediger Pluem: > My first question in this situation is: What is the correct thing to do here? > Generate the response from the cache (of course with the updated headers from > the 304 > backend response) and delete the cache entry afterwards? My understanding (regarding no-store and cache updates from 304 responses): The response you send if the client request was a unconditional SHOULD be the merged response of the old response and entity headers from the 304. But you do not need to delete the already cached response without no-store if you do not want to (change of CC is not an invalidation criteria), but you MUST NOT store the updated headers from a no-store session (no-store on either response or request). Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [PATCH] mod_cache 304 on HEAD (bug 41230)
On 04/13/2007 05:31 PM, Niklas Edmundsson wrote: > On Wed, 11 Apr 2007, Niklas Edmundsson wrote: > >> Looking a bit further, I think that something like this would actually >> be enough: > > > > I have now tested this patch, and it seems to solve the problem. This is > on httpd-2.2.4 + patch for PR41475 + our mod_disk_cache patches. > > Without the patch a HEAD on a cached expired object that isn't modified > will unconditionally return 304 and furthermore cause the cached object > to be deleted. We believe that this is the explanation to why it has > been so hard to track down this bug - it only bites one user and that > user usually has no clue on what happens, and even if we try to > reproduce it immediately afterwards it won't trigger. > > With the patch stuff works like expected: > - A HEAD on a cached expired object that isn't modified will update > the cache header and return the proper return code, it follows the > same code path as other requests on expired unmodified objects. > - A HEAD on a cached expired object that IS modified will remove the > object from cache and then decline the opportunity to cache the > object. Are you really sure that it gets deleted? cache->provider->remove_entity does not really remove the object from the cache. Only cache->provider->remove_url does this. I consider the CACHE_SAVE filter already as hard to read (not your fault by any means), but from my point of view your patch does increase this (specificly I think about the rv = !OK line. I know that a similar trick is done some lines above, but I don't like that one either). Looking at the problem I noticed a related problem already mentioned in a FIXME comment: It can happen that the headers of a 304 response from the backend cause the response to be uncacheable (e.g. Cache-Control: no-store). Currently this leads to a wrong response (304) if the original request was unconditional (just like in your HEAD case and your HEAD case will also fail here, even after your patch). My first question in this situation is: What is the correct thing to do here? Generate the response from the cache (of course with the updated headers from the 304 backend response) and delete the cache entry afterwards? Regards Rüdiger
Re: Call for Papers Opens for ApacheCon US 2007
On Apr 16, 2007, at 11:27, Eli Marmor wrote: On *April 16*, Rich Bowen wrote: Call for Papers Opens for ApacheCon US 2007 The Call for Papers is now open for ApacheCon US, to be held November 12-16 at the Peachtree Westin, Atlanta. The conference will consist of two day of tutorials (November 12-13) and three days of regular conference sessions (November 14-16). ... The paper submission deadline is Monday, 28 April 2007, Midnight GMT. ^ Considering the short time till the deadline, is it possible to give an extension? (let's say - May 16, a month from now). Isn't it a little early to ask for an extension? However, no, its not possible to give an extension. We have a hard, unmovable deadline of ApacheCon EU, and it's not possible to extend past that. The deadline is Monday, April 30. Yes, I typoed it. Sorry. -- Speech is conveniently located midway between thought and action, where it often substitutes for both. John Andrew Holmes
Re: Call for Papers Opens for ApacheCon US 2007
On *April 16*, Rich Bowen wrote: > > Call for Papers Opens for ApacheCon US 2007 > > The Call for Papers is now open for ApacheCon US, to be held November > 12-16 at the Peachtree Westin, Atlanta. The conference will consist > of two day of tutorials (November 12-13) and three days of regular > conference sessions (November 14-16). > > ... > > The paper submission deadline is Monday, 28 April 2007, Midnight GMT. ^ Considering the short time till the deadline, is it possible to give an extension? (let's say - May 16, a month from now). -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: bug #42120: Apache improperly handling Path Component parameters?
Nick Kew wrote: On Fri, 13 Apr 2007 16:30:06 -0500 Andy Wang <[EMAIL PROTECTED]> wrote: There are a number of potential workarounds (LocationMatch, or Multiple Location blocks to deal with the ;* pattern) but it does seem like this is a bug unless someone can clarify RFC 2396 section 3.3 for me and explain why it isn't. Your reading of the RFC is correct but irrelevant. The semantics of are (like ) based on path components. Doesn't that more or less support my interpretation? If the semantics of are based on path components, and the RFC 2396 section 3.3 defines the grammar for Path Component, and according to that grammar param's are not significant when parsing them, shouldn't apache also not include parameter's when attempting to match a URI's path component to a block? Andy
Call for Papers Opens for ApacheCon US 2007
Call for Papers Opens for ApacheCon US 2007 The Call for Papers is now open for ApacheCon US, to be held November 12-16 at the Peachtree Westin, Atlanta. The conference will consist of two day of tutorials (November 12-13) and three days of regular conference sessions (November 14-16). Please log in to the website at http://apachecon.com/html/login.html to submit your proposal. Further details about fees and are avaialable on the CFP form. Topics appropriate for submission to this conference are manifold, and may include but are not restricted to: * ASF projects * ASF-Incubated projects * Scripting languages and dynamic content such as Java, Perl, Python, Ruby, XSL, and PHP * New technologies and broader initiatives such as Web Services and Web 2.0 * Security and e-commerce, performance tuning, load balancing, and high availability * Business and community issues surrounding the ASF and Open Source The paper submission deadline is Monday, 28 April 2007, Midnight GMT. Thanks, and we hope to hear from you, and to see you in Atlanta. -- The ApacheCon Planners [EMAIL PROTECTED]
