Re: Proposed Lua backport for 2.4
On 3/13/2013 1:12 PM, Daniel Gruno wrote: On 03/13/2013 08:39 PM, Gregg Smith wrote: On 3/13/2013 4:44 AM, Daniel Gruno wrote: On 03/13/2013 02:50 AM, Gregg Smith wrote: Hi Daniel, I'm seeing segfaults on that dreadful Windows OS when using LuaMapHandler LuaRoot together. The backtrace was actually quite helpful :) It would appear that the bug (perhaps) pre-dates my work on mod_lua (or it could be something I've missed completely, who knows). I can see that vm_construct is creating, or attempting to create, a lua VM which returns a null pointer meaning that part failed, but it doesn't check whether the VM is null, making munge_path segfault. At the same time, the lifecycle_pool being passed is also NULL, which makes even less sense to me, since you can see in the backtrace that it wasn't null when it got passed to ap_lua_get_lua_state. Can you tell me which exact lua directives you used for this? which LuaScope, LuaCodeCache and so on? IfModule lua_module AddHandler lua-script .lua LuaMapHandler /testlua /usr/etc/lua/example.lua LuaRoot /usr/etc/lua Directory /usr/etc/lua Options All AllowOverride None Require all granted /Directory /IfModule So since not specifically configured, the defaults of once and stat respectively. Regards, Gregg I am unable to get my own server to segfault, and I can't seem to find anything in the code that would cause the pool to suddenly become null. Your backtrace seems to indicate that your request calls: ap_lua_get_lua_state(apr_pool_t * lifecycle_pool=0x0258c0e8, ap_lua_vm_spec * spec=0x0258b658, request_rec * r=0x0258a120) which then calls: vm_construct(lua_State * * vm=0x036efdc0, void * params=0x0258b658, apr_pool_t * lifecycle_pool=0x) except lifecycle_pool never gets changed anywhere in the code, it's just passed straight through to vm_construct...so whatever made it turn into 0x0 is beyond my eyes to spot. If anyone else can spot something I'm missing, please do speak up, otherwise I'll probably chalk this one down to a Windows oddity. It was suggested to me a few days ago off list to give the old module a try pre r1200614. I did just that yesterday and it works and no segfaults. Just FYI. Regards, Gregg
Re: mod_cache with Cache-Control no-cache= or private=
On Mar 13, 2013, at 10:20 AM, Graham Leggett wrote: On 11 Mar 2013, at 12:50 PM, Yann Ylavic ylavic@gmail.com wrote: The way I read the spec, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. What this means is that if the specified field names are found to be present in the cached response, then the origin server needs to be given the opportunity to update these fields through a conditional request. In the current cache code, we return 0 meaning this is stale, revalidate, and a conditional request is sent to the origin. We hope the origin sends 304 Not Modified, with updated headers corresponding to the fields. Ok, I see your point, and this is surely the right reading of the rfc, but there is necessarily a difference between no-cache and no-cache=header(s), particularly with the handling of that (stale) header(s). For what I understand now, if the origin does not send (one of) the header(s) in its 304 response, the stale header(s) MUST NOT be served. I don't read it that way from the spec, I think it all comes down to the phrase without successful revalidation with the origin server. I read it as without successful revalidation [of the whole request] with the origin server. In other words, the origin server sent the original header, if the origin server doesn't update the header in the 304 response then it means I've had my opportunity to revalidate the entity, current cached value is fine, send it. Roy ultimately would be able to answer this? It means delete the header fields prior to storing them in the cache for later reuse. If the origin had wanted must-revalidate, it would simply use that directive instead. The successful revalidation bit is saying that the cache should forward all of the fields for the response to the original request and for any response that is revalidated (i.e., forward the new fields received in 304), but not for the requests that are entirely handled by the cache. Roy
Patches languishing in Bugzilla
There are a number of OK-looking patches in Bugzilla that have been sitting there with no action for a while. I just went through the recent Bug report looking for bugs of interest to me that have patches. All of the following bugs have a patch, and most of them address a pretty straightforward failure to implement the spec. None of the bugs' comments indicate objections to their patches (although in some cases that's because nobody has commented on them at all, beyond the initial problem description and patch submission): |35981|New|Maj|2005-08-02|mod_dav overrides dav_fs response on PUT failure | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |50773|New|Nor|2011-02-14|Dav lock database corruption | |51297|New|Nor|2011-05-31|Improve error handling during UNLOCK| |52559|New|Nor|2012-01-30|[PATCH] Some PROPPATCH causing segfault in mod_dav| |53525|New|Nor|2012-07-09|PROPPATCH delete (svn propdel) errors not returned| |53741|New|Min|2012-08-19|Code clean up (Concat string at compile time when | |53910|New|Nor|2012-09-21|If: check spuriously succeeds with %-encoded URL a| |54145|New|Min|2012-11-14|Poor error handling in dav_method_put() | |54611|New|Nor|2013-02-26|Location header for dav_created not URI encoded | (general case of |54367|New|Maj|2013-01-02|Location header in response to PUT is not %-escape|?) |54610|New|Nor|2013-02-26|COPY doesn't respect If/If-Modified/etc | I'd like to propose that 35981, 39287, 51297, 52559, 53741, 54145 be committed. The patches in 50773, 53525, 53910, 54610, and 54611 perhaps should be evaluated by someone with more familiarity with the server internals before they are committed, but I'd be especially grateful if someone would look at 53910, 54610, and/or 54611; these are bugs that make the stock Apache unusable for us.
