Re: Wrong libtool choice on-install (in 2.0.x)
William A. Rowe, Jr. wrote: > LIBTOOL = /bin/sh /usr/local/apache20/build/libtool --silent > SH_LIBTOOL = /bin/sh /usr/local/apache20/build/libtool --silent > > I don't know where it came up with that nonsense... > > APR & APR-UTIL are installed in /usr/local/apr, httpd in /usr/local/apache20. > > It seems like config_vars.mk is imagining something, we use apr's libtool. Badda bing badda boom. Here's my suggested gross hack, which should handle the config_vars.mk libtool relocation, for strictly in-tree apr builds, and leave it alone for builds against a system apr. It also avoids changing SH_LIBTOOL which was always simply $(LIBTOOL). Anyone see a better alternative? Index: Makefile.in === --- Makefile.in (revision 486457) +++ Makefile.in (working copy) @@ -93,8 +93,10 @@ @test -d $(DESTDIR)$(installbuilddir) || $(MKINSTALLDIRS) $(DESTDIR)$(installbuilddir) @cp $(top_srcdir)/build/*.mk $(DESTDIR)$(installbuilddir); \ cp build/*.mk $(DESTDIR)$(installbuilddir); \ - sed 's#LIBTOOL = \(.*\)#LIBTOOL = $(SHELL) $(installbuilddir)/libtool $(LTFLAGS)#' \ + if [ -f srclib/apr/libtool ]; then \ + sed 's#i^LIBTOOL = \(.*\)#LIBTOOL = $(SHELL) $(installbuilddir)/libtool $(LTFLAGS)#' \ build/config_vars.mk > $(DESTDIR)$(installbuilddir)/config_vars.mk; \ + fi; cp $(top_srcdir)/build/instdso.sh $(DESTDIR)$(installbuilddir); \ cp $(top_builddir)/config.nice $(DESTDIR)$(installbuilddir);
Wrong libtool choice on-install (in 2.0.x)
LIBTOOL = /bin/sh /usr/local/apache20/build/libtool --silent SH_LIBTOOL = /bin/sh /usr/local/apache20/build/libtool --silent I don't know where it came up with that nonsense... APR & APR-UTIL are installed in /usr/local/apr, httpd in /usr/local/apache20. It seems like config_vars.mk is imagining something, we use apr's libtool.
Re: Wrong etag sent with mod_deflate
tis 2006-12-12 klockan 09:20 -0500 skrev Brian Akins: > Only conditional requests from clients, generally, have If-None-Match > headers. Correct. It's a conditional. These days you also see them from Squid btw. > So the only way for a cache, on an initial request from a client, to > determine > what object to serve is to use the Client supplied information - which > doesn't > include an Etag, so you have to, usually, rely on URI first, and then the > Vary > information. Indeed. This is always the case. If-None-Match MUST NOT be used for identification of which response to use. It's a conditional only. But the unique identity of the response entity is defined by request-URI + ETag and/or Content-Location. The cache is not supposed to evaluate Accept-* headers in determining the entity identity, only the origin server. The identity of the entity is important for - Cache correctness, making sure updates invalidate cached copies where needed. - Avoiding duplicated storage There may be any number of request header combinations in any Vary dimensions all mapping to the same entity. This logics is not at all unique for Accept-Encoding. The logics on how a cache is supposed to operate applies equal to all Vary indicated headers. The specs does not make any distinction between Accept-Encoding, Accept-Language, User-Agent etc in how caches are supposed to operate. It all boils down to the entity identified by URI + ETag and/or Content-Location as returned in 200 and 304 responses allowing the cache to map requests to entities. Please see RFC2616 13.6 Caching Negotiated Responses, it explains how the RFC intends that caches should operate wrt Vary, ETag and Content-Location in full detail. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Wrong etag sent with mod_deflate
Henrik Nordstrom wrote: mån 2006-12-11 klockan 14:25 -0500 skrev Brian Akins: So, multiple variants of the same object can have the same Etag, but still be different cached objects. Your implementation ignores RFC 2616 13.6 Caching Negotiated Responses, but is otherwise fine. It's functionally compliant but not as effective as it could be. That was a simplified explanation, we actually do not store a cache entry for every single variant. In our case the only thing we actually ever care about is whether or not you support gzip. So all the variants for "Vary: User-Agent, Accept-Encoding" actually boil down to 2 variants - gzip or no-gzip. One of the major reasons we quit using squid was it "support" for Vary's. (This was pre-3.0, so things may have changed). Of course, at the time httpd wasn't any better - but it was alot easier to hack ;) >Variants is >identified by ETag or Content-Location. Only if there is neither ETag or >Content-Location in the response entity then is the response entity >identified by the Vary request headers. Only conditional requests from clients, generally, have If-None-Match headers. So the only way for a cache, on an initial request from a client, to determine what object to serve is to use the Client supplied information - which doesn't include an Etag, so you have to, usually, rely on URI first, and then the Vary information. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
