Re: issue with "uncacheable" cache revalidations

[Graham Leggett]

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]

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: No H2 Window updates!

[Jan Ehrhardt]

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

issue with "uncacheable" cache revalidations

[Eric Covener]

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!

[Jan Ehrhardt]

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!

[Jim Jagielski]

> 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! 

Re: No H2 Window updates!

[William A Rowe Jr]

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!

[Jim Jagielski]

Can you (or someone) provide a test case or explanation of
how to recreate the issue?

tia

Re: issue with "uncacheable" cache revalidations

[Jan Ehrhardt]

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