Re: issue with "uncacheable" cache revalidations
On Tue, Dec 1, 2015 at 12:15 PM, Graham Leggett wrote: >> I've been looking at an issue where a revalidation >> of a stale cache entry fails because the 304 response >> on the revalidation doesn't contain its own CC or Expires >> but the URL has a query string. This kicks the revalidation >> response out of the cache save filter early and we never >> get to look at the stale handle and update the headers. > > As I recall there is a specific code path for responses that say "we've asked > for revalidation, revalidation was successful but not cacheable. Return > cached data but invalidate it, it is the best we can do". You're right, I missed that when comparing to my snapshot. It's prefixed by the "Hold the phone..." comment. -- Eric Covener cove...@gmail.com
Re: issue with "uncacheable" cache revalidations
On 1 Dec 2015, at 15:50, Eric Covener wrote: > I've been looking at an issue where a revalidation > of a stale cache entry fails because the 304 response > on the revalidation doesn't contain its own CC or Expires > but the URL has a query string. This kicks the revalidation > response out of the cache save filter early and we never > get to look at the stale handle and update the headers. As I recall there is a specific code path for responses that say "we've asked for revalidation, revalidation was successful but not cacheable. Return cached data but invalidate it, it is the best we can do". Regards, Graham --
Re: issue with "uncacheable" cache revalidations
Eric Covener in gmane.comp.apache.devel (Tue, 1 Dec 2015 10:50:56 -0500): >I've been looking at an issue where a revalidation >of a stale cache entry fails because the 304 response >on the revalidation doesn't contain its own CC or Expires >but the URL has a query string. This kicks the revalidation >response out of the cache save filter early and we never >get to look at the stale handle and update the headers. > >This is also one of the FIXME cases where the 304 still leaks >out to a non-conditional request. > >Part of me wants to merge the Expires/CC headers earlier, or >load up the local variables with what we'd end up merged for >Expires and CC. But since it's just two headers, part of me wants >to peek at them earlier but leave them as distinct things being >tracked in that early if/else/ for the various reasons. > >In the same neighborhood, we are missing a httpbis clarification >about not using Expires when we have parsed CC: s-maxage. On >this fork of the problem I looked at, some third-party component >had added a mystery Expires: $longago to the response to >accompany a cookie. Quick remark: in Drupal7 with mod_http2 1.0.8 I got the feeling that I was seeing a lot of 304's. And many URL's in the Drupal-themes have a query string. >I might not come back to it until the new year. Druk, druk, druk ;-) -- Jan
issue with "uncacheable" cache revalidations
I've been looking at an issue where a revalidation of a stale cache entry fails because the 304 response on the revalidation doesn't contain its own CC or Expires but the URL has a query string. This kicks the revalidation response out of the cache save filter early and we never get to look at the stale handle and update the headers. This is also one of the FIXME cases where the 304 still leaks out to a non-conditional request. Part of me wants to merge the Expires/CC headers earlier, or load up the local variables with what we'd end up merged for Expires and CC. But since it's just two headers, part of me wants to peek at them earlier but leave them as distinct things being tracked in that early if/else/ for the various reasons. In the same neighborhood, we are missing a httpbis clarification about not using Expires when we have parsed CC: s-maxage. On this fork of the problem I looked at, some third-party component had added a mystery Expires: $longago to the response to accompany a cookie. Anyone with strong feelings or insight about either of these cases? I might not come back to it until the new year.
Re: No H2 Window updates!
William A Rowe Jr in gmane.comp.apache.devel (Tue, 1 Dec 2015 08:32:24 -0600): >Hi Jan - it isn't possible to build httpd trunk sources using httpd 2.4.x build >files, and this goes for windows or unix. How were you trying to build? ... That was exactly what I was doing. I did not replace my working *.vcxproj files. But, sorry guys, really no time ATM. I will check in as soon as I have some spare time. -- Jan
Re: No H2 Window updates!
On Tue, Dec 1, 2015 at 7:15 AM, Jan Ehrhardt wrote: > Jim Jagielski in gmane.comp.apache.devel (Tue, 1 Dec 2015 07:38:47 -0500): > > > >> On Nov 30, 2015, at 5:53 PM, Jan Ehrhardt wrote: > >> > >> Creating library .\Release/mod_http2.lib and object > .\Release/mod_http2.exp > >> 1>h2_from_h1.obj : error LNK2019: unresolved external symbol > _ap_casecmpstr > >> referenced in function _create_response > >> 1>.\Release\mod_http2.so : fatal error LNK1120: 1 unresolved externals > > > >Sounds like you needed to do a make clean and rebuild... ap_casecmpstr() > >is httpd not APR :) > > If only it was that simple on Windows. Replacing all sources of 2.4.x with > those from trunk leads to oher errors. Hi Jan - it isn't possible to build httpd trunk sources using httpd 2.4.x build files, and this goes for windows or unix. How were you trying to build? ... > For instance: > > 1>-- Build started: Project: mod_ssl, Configuration: Release Win32 > -- > 1> mod_ssl.c > 1>mod_ssl.c(43): error C2491: 'ssl_run_pre_handshake': definition of > dllimport > function not allowed > 1> ssl_engine_config.c > 1> ssl_engine_init.c > 1>ssl_engine_init.c(39): error C2491: 'ssl_run_init_server': definition of > dllimport function not allowed > etc > Right now, SSL_DECLARE_EXPORT is defined in both mod_ssl.dsp, from the ancient build schema, and in CMakeFiles.txt, for our new and still evolving cmake-based build schema. It seems like you may have been trying to build mod_ssl in trunk using the mod_ssl.mak file from 2.4.x? Someone can generate you the .mak files for trunk, we just don't check them in during trunk development because they are a more rapidly moving target that doesn't settle down till we are about ready to release trunk as some 2.6 or 3.0 version. That's what the cmake effort is all about. See the README.cmake in the root httpd trunk directory for guidance on how to use that. If that is what you did, then we have a bigger issue to resolve, but I compared the use of SSL_DECLARE_EXPORT to the long-existing DAV_DECLARE_EXPORT and it seems to be consistent. Cheers, Bill
Re: No H2 Window updates!
Can you (or someone) provide a test case or explanation of how to recreate the issue? tia
Re: No H2 Window updates!
Jim Jagielski in gmane.comp.apache.devel (Tue, 1 Dec 2015 07:38:47 -0500): > >> On Nov 30, 2015, at 5:53 PM, Jan Ehrhardt wrote: >> >> Creating library .\Release/mod_http2.lib and object .\Release/mod_http2.exp >> 1>h2_from_h1.obj : error LNK2019: unresolved external symbol _ap_casecmpstr >> referenced in function _create_response >> 1>.\Release\mod_http2.so : fatal error LNK1120: 1 unresolved externals > >Sounds like you needed to do a make clean and rebuild... ap_casecmpstr() >is httpd not APR :) If only it was that simple on Windows. Replacing all sources of 2.4.x with those from trunk leads to oher errors. For instance: 1>-- Build started: Project: mod_ssl, Configuration: Release Win32 -- 1> mod_ssl.c 1>mod_ssl.c(43): error C2491: 'ssl_run_pre_handshake': definition of dllimport function not allowed 1> ssl_engine_config.c 1> ssl_engine_init.c 1>ssl_engine_init.c(39): error C2491: 'ssl_run_init_server': definition of dllimport function not allowed etc I do not have the time now to solve things like this. -- Jan
Re: No H2 Window updates!
> On Nov 30, 2015, at 5:53 PM, Jan Ehrhardt wrote: > > Jim Jagielski in gmane.comp.apache.devel (Mon, 30 Nov 2015 07:24:07 -0500): >> I'm assuming that the brokenness also shows up on trunk, >> right? >> >> Bert, Jan, can you check if trunk shows the same behavior? >> I would prefer not hacking away on 2.4 directly and independently. > > I checked out revision 1717334 from trunk and tried to update mod_http2 > without updating the other sources. Surprise: > > Creating library .\Release/mod_http2.lib and object .\Release/mod_http2.exp > 1>h2_from_h1.obj : error LNK2019: unresolved external symbol _ap_casecmpstr > referenced in function _create_response > 1>.\Release\mod_http2.so : fatal error LNK1120: 1 unresolved externals > > Somebody followed your advice and actually wrote some code! I cannot easily > test mod_http2 from trunk, because it involves updating APR as well. Sounds like you needed to do a make clean and rebuild... ap_casecmpstr() is httpd not APR :) Thanks for the test!