Build failed in Hudson: 3.HEAD-amd64-CentOS-5.3 #765
See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/765/changes Changes: [Francesco Chemolli kin...@squid-cache.org] Fixed some build errors in purge tool. [Henrik Nordstrom hen...@henriknordstrom.net] Kill redundant hexd program from purge. There is too many other tools for producing a readable hexdump of a file. -- [...truncated 23965 lines...] then mv -f .deps/ext_ldap_group_acl.Tpo .deps/ext_ldap_group_acl.Po; else rm -f .deps/ext_ldap_group_acl.Tpo; exit 1; fi /bin/sh ../../../libtool --tag=CXX --mode=link g++ -I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -g -o ext_ldap_group_acl ext_ldap_group_acl.o -L../../../lib -lmiscutil ../../../compat/libcompat.la -lldap -llber -ldl -lm -lnsl -ldl -ldl libtool: link: g++ -I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -g -o ext_ldap_group_acl ext_ldap_group_acl.o -Lhttp://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/lib -lmiscutil ../../../compat/.libs/libcompat.a -lldap -llber -lm -lnsl -ldl make[4]: Leaving directory `http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/helpers/external_acl/LDAP_group' Making all in file_userip make[4]: Entering directory `http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/helpers/external_acl/file_userip' if g++ -DHAVE_CONFIG_H -I../../../.. -I../../../../include -I../../../../src -I../../../include-I/usr/include/libxml2-I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -MT ext_file_userip_acl.o -MD -MP -MF .deps/ext_file_userip_acl.Tpo -c -o ext_file_userip_acl.o ../../../../helpers/external_acl/file_userip/ext_file_userip_acl.cc; \ then mv -f .deps/ext_file_userip_acl.Tpo .deps/ext_file_userip_acl.Po; else rm -f .deps/ext_file_userip_acl.Tpo; exit 1; fi /bin/sh ../../../libtool --tag=CXX --mode=link g++ -I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -g -o ext_file_userip_acl ext_file_userip_acl.o -L../../../lib -lmiscutil ../../../compat/libcompat.la -ldl -lm -lnsl -ldl -ldl libtool: link: g++ -I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -g -o ext_file_userip_acl ext_file_userip_acl.o -Lhttp://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/lib -lmiscutil ../../../compat/.libs/libcompat.a -lm -lnsl -ldl make[4]: Leaving directory `http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/helpers/external_acl/file_userip' Making all in kerberos_ldap_group make[4]: Entering directory `http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/helpers/external_acl/kerberos_ldap_group' make[5]: Entering directory `http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/ws/btlayer-02-maximus/squid-3.HEAD-BZR/_build/helpers/external_acl/kerberos_ldap_group' if g++ -DHAVE_CONFIG_H -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../../helpers/external_acl/kerberos_ldap_group -I/usr/include/libxml2-I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -MT kerberos_ldap_group.o -MD -MP -MF .deps/kerberos_ldap_group.Tpo -c -o kerberos_ldap_group.o ../../../../helpers/external_acl/kerberos_ldap_group/kerberos_ldap_group.cc; \ then mv -f .deps/kerberos_ldap_group.Tpo .deps/kerberos_ldap_group.Po; else rm -f .deps/kerberos_ldap_group.Tpo; exit 1; fi if g++ -DHAVE_CONFIG_H -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../../helpers/external_acl/kerberos_ldap_group -I/usr/include/libxml2-I/usr/include/libxml2 -Wall -Wpointer-arith -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -MT support_group.o -MD -MP -MF .deps/support_group.Tpo -c -o support_group.o ../../../../helpers/external_acl/kerberos_ldap_group/support_group.cc; \ then mv -f .deps/support_group.Tpo .deps/support_group.Po; else rm -f .deps/support_group.Tpo; exit 1; fi if g++ -DHAVE_CONFIG_H -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../.. -I../../../../include -I../../../../src -I../../../include -I../../../../helpers/external_acl/kerberos_ldap_group
new/delete overloading, why?
Why are we overloading new/delete with xmalloc/xfree? include/SquidNew.h this is causing random linking issues every time some piece of code forgets to include SquidNew.h, especially when building helpers etc. And I fail to see what benefit we get from overloading the new/delete operators in this way. Regards Henrik
Re: [PREVIEW] 1xx response forwarding
tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Regards Henrik
Hudson build is back to normal: 3.HEAD-amd64-CentOS-5.3 #766
See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/766/changes
Build failed in Hudson: 3.HEAD-i386-opensolaris #410
See http://build.squid-cache.org/job/3.HEAD-i386-opensolaris/410/changes Changes: [Francesco Chemolli kin...@squid-cache.org] Fixed build issue in purge tool. [Francesco Chemolli kin...@squid-cache.org] Fixed some build errors in purge tool. [Henrik Nordstrom hen...@henriknordstrom.net] Kill redundant hexd program from purge. There is too many other tools for producing a readable hexdump of a file. [Henrik Nordstrom hen...@henriknordstrom.net] Also fix up hexd to Squid coding standards [Henrik Nordstrom hen...@henriknordstrom.net] Adjust purge sources to Squid coding standard (xmalloc, xfree etc) [Henrik Nordstrom hen...@henriknordstrom.net] Clean up DEFAULT_PID_FILE in similar manner [Henrik Nordstrom hen...@henriknordstrom.net] Kill recursive DEFAULT_HOSTS. Automake automatically adds expansions to Makefile.in, no need for us to wrongly try to reference them.. [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement [Francesco Chemolli kin...@squid-cache.org] configure.in fix: properly pass default hosts_file option around during build. [Amos Jeffries amosjeffr...@squid-cache.org] Bundle the purge and hexd tools with Squid sources. Fixes the remaining known errors with purge tool building within Squid source tree. This adds the auto-tools changes necessary to bundle the tool. [Amos Jeffries amosjeffr...@squid-cache.org] revert unwanted changes slipped into rev10756. [Amos Jeffries squ...@treenet.co.nz] Prep for 3.1.7 [Amos Jeffries amosjeffr...@squid-cache.org] Remove diff-reducer hack in rev10754 [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement -- [...truncated 3485 lines...] /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:187: error: `::wcsrtombs' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:197: error: `::wctob' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:198: error: `::wmemcmp' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:199: error: `::wmemcpy' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:200: error: `::wmemmove' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:201: error: `::wmemset' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:202: error: `::wprintf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:203: error: `::wscanf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:223: error: `::wcsstr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: initializing argument 1 of `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: At global scope: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:229: error: `::wmemchr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' In file included from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ios:46, from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ostream:45, from ../../../src/ip/Address.h:61, from ../../../src/squid.h:171, from ../../../src/base/AsyncCall.cc:5: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static int std::char_traitswchar_t::compare(const wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: `wmemcmp' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: (Each undeclared identifier is reported only once for each function it appears in.)
Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #512
See http://build.squid-cache.org/job/3.HEAD-i386-OpenBSD-4.5/512/ -- Started by upstream project 3.HEAD-amd64-CentOS-5.3 build number 766 Building remotely on vobsd Unable to obtain lock file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock held by hud...@vobsd.squid-cache.org on host vobsd.squid-cache.org [process #27278] locked 33 hours, 56 minutes ago Will continue to try until 15:39:32 bzr: ERROR: Could not acquire lock LockDir(file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock) ERROR: Failed to pull
Re: [PREVIEW] 1xx response forwarding
On 08/20/2010 06:30 AM, Henrik Nordström wrote: tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Good point. The next hop version check is better done on the server side though, right? We may not yet know the next hop when accepting the request. BTW, most things in HTTP are URI- and not hostname-based. I wonder what server or next hop means when checking for supported versions. Do we look just at the host name:port and hope that it reflects the version of everything running there? Thanks, Alex.
Re: [PREVIEW] 1xx response forwarding
Some aspects of http is hop-by-hop not end-to-end. Processing of Expect is one such thing. Transfer encoding and message delimiting another. We just look at what we know about the nexthop we select. Actual URI is pretty irrelevant unless used as selecting factor for selecting the nexthop. Yes proper Expect processing needs to be done in our client (server side in our terminology). regards Henrik - Ursprungsmeddelande - On 08/20/2010 06:30 AM, Henrik Nordström wrote: tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Good point. The next hop version check is better done on the server side though, right? We may not yet know the next hop when accepting the request. BTW, most things in HTTP are URI- and not hostname-based. I wonder what server or next hop means when checking for supported versions. Do we look just at the host name:port and hope that it reflects the version of everything running there? Thanks, Alex.
Re: [PREVIEW] 1xx response forwarding
On 08/20/2010 08:36 AM, Henrik Nordström wrote: Some aspects of http is hop-by-hop not end-to-end. Processing of Expect is one such thing. Transfer encoding and message delimiting another. Sure. We can consider the next hop == origin server case to avoid distractions. I am only wondering whether http://host/path1 and http://host/path2 responses are guaranteed to have the same protocol version. I do not think HTTP gives such guarantees, and yet its requirements imply that remembering versions using host names should work. Alex. We just look at what we know about the nexthop we select. Actual URI is pretty irrelevant unless used as selecting factor for selecting the nexthop. Yes proper Expect processing needs to be done in our client (server side in our terminology). regards Henrik - Ursprungsmeddelande - On 08/20/2010 06:30 AM, Henrik Nordström wrote: tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Good point. The next hop version check is better done on the server side though, right? We may not yet know the next hop when accepting the request. BTW, most things in HTTP are URI- and not hostname-based. I wonder what server or next hop means when checking for supported versions. Do we look just at the host name:port and hope that it reflects the version of everything running there? Thanks, Alex.
Re: [PREVIEW] 1xx response forwarding
See RFC on use and meaning of HTTP version numbers. fre 2010-08-20 klockan 08:58 -0600 skrev Alex Rousskov: On 08/20/2010 08:36 AM, Henrik Nordström wrote: Some aspects of http is hop-by-hop not end-to-end. Processing of Expect is one such thing. Transfer encoding and message delimiting another. Sure. We can consider the next hop == origin server case to avoid distractions. I am only wondering whether http://host/path1 and http://host/path2 responses are guaranteed to have the same protocol version. I do not think HTTP gives such guarantees, and yet its requirements imply that remembering versions using host names should work. Alex. We just look at what we know about the nexthop we select. Actual URI is pretty irrelevant unless used as selecting factor for selecting the nexthop. Yes proper Expect processing needs to be done in our client (server side in our terminology). regards Henrik - Ursprungsmeddelande - On 08/20/2010 06:30 AM, Henrik Nordström wrote: tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Good point. The next hop version check is better done on the server side though, right? We may not yet know the next hop when accepting the request. BTW, most things in HTTP are URI- and not hostname-based. I wonder what server or next hop means when checking for supported versions. Do we look just at the host name:port and hope that it reflects the version of everything running there? Thanks, Alex.
Re: [MERGE] Initial netfilter mark patch for comment
On Fri, 2010-08-13 at 18:19 -0600, Alex Rousskov wrote: On 08/11/2010 03:25 PM, Andrew Beverley wrote: I've moved these, as well as most of the other QOS functions, into Ip::Qos. I have also removed the QosConfig namespace, as it didn't seem to fit with all these additional functions. * A patch preamble with the proposed commit message would be nice. * I am not sure what Qos class is. It is not documented. If it is a QOS configuration class, I understand why we have a global instance of it, but the original QosConfig name seems better in that case. If it is not a configuration class, then I am not sure why we have a global instance of it. And the QosConfig file name does not seem to match the class name any more. Perhaps we need two classes, one for configuration and one for manipulation? Or a Qos namespace with a configuration class and global manipulation functions? The latter seems more likely. I was trying to copy the approach used by the Interceptor class, which has its configuration variables and methods in one class, with a global instance of it. I thought that it would keep things nice and tidy by having all qos aspects in one single class (with the configuration variables within private space). I'm happy to go with whatever approach you want though, and can separate the config aspects back out from the functions. Before I go ahead and do this, I want to check which option I should go for. As Alex says, the options are: 1) - Reinstate the QosConfig class with the configuration variables as public members - Create a new class (QosFunctions?) with the relevant functions in - Create one global instance of each class, or alternatively create a new instance of the functions class each time the functions need to be accessed (is the latter inefficient?) 2) - Reinstate the QosConfig class with the configuration variables as public members - Create the functions as global functions in the namespace 3) - Keep everything in one class :-) If going with option 2, the functions can no longer be const (which most of them currently are). Thanks, Andy
Build failed in Hudson: 3.HEAD-i386-opensolaris #411
See http://build.squid-cache.org/job/3.HEAD-i386-opensolaris/411/changes Changes: [Francesco Chemolli kin...@squid-cache.org] Compilation speedup: optimize test-suite/testheaders.sh [Francesco Chemolli kin...@squid-cache.org] Fixed build issue in purge tool. -- [...truncated 3472 lines...] /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:176: error: `::wcrtomb' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:187: error: `::wcsrtombs' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:197: error: `::wctob' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:198: error: `::wmemcmp' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:199: error: `::wmemcpy' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:200: error: `::wmemmove' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:201: error: `::wmemset' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:202: error: `::wprintf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:203: error: `::wscanf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:223: error: `::wcsstr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: initializing argument 1 of `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: At global scope: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:229: error: `::wmemchr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' In file included from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ios:46, from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ostream:45, from ../../../src/ip/Address.h:61, from ../../../src/squid.h:171, from ../../../src/base/AsyncCall.cc:5: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static int std::char_traitswchar_t::compare(const wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: `wmemcmp' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static const wchar_t* std::char_traitswchar_t::find(const wchar_t*, size_t, const wchar_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::move(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:336: error: `wmemmove' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::copy(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:340: error: `wmemcpy' undeclared (first use this function)
Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #513
See http://build.squid-cache.org/job/3.HEAD-i386-OpenBSD-4.5/513/ -- Started by upstream project 3.HEAD-amd64-CentOS-5.3 build number 767 Building remotely on vobsd Unable to obtain lock file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock held by hud...@vobsd.squid-cache.org on host vobsd.squid-cache.org [process #27278] locked 37 hours, 29 minutes ago Will continue to try until 19:12:16 bzr: ERROR: Could not acquire lock LockDir(file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock) ERROR: Failed to pull
Hudson build is back to normal: 3.HEAD-i386-Debian-sid #355
See http://build.squid-cache.org/job/3.HEAD-i386-Debian-sid/355/changes
Re: [PREVIEW] 1xx response forwarding
On 08/20/2010 09:26 AM, Henrik Nordström wrote: See RFC on use and meaning of HTTP version numbers. The only relevant RFC text I can find is an informal discussion that HTTP version is tied to a message sender, an undefined concept. However, even if we replace message sender with client or server, my assertion that HTTP does not guarantee that one host:port corresponds to one client or server appears to be valid. In other words, RFC requirement to maintain a database of server versions relies on an undocumented assumption that we can identify servers by some short, often reused component of a request (such as host:port). That assumption holds for most but not all current real-world environments. Alex. fre 2010-08-20 klockan 08:58 -0600 skrev Alex Rousskov: On 08/20/2010 08:36 AM, Henrik Nordström wrote: Some aspects of http is hop-by-hop not end-to-end. Processing of Expect is one such thing. Transfer encoding and message delimiting another. Sure. We can consider the next hop == origin server case to avoid distractions. I am only wondering whether http://host/path1 and http://host/path2 responses are guaranteed to have the same protocol version. I do not think HTTP gives such guarantees, and yet its requirements imply that remembering versions using host names should work. Alex. We just look at what we know about the nexthop we select. Actual URI is pretty irrelevant unless used as selecting factor for selecting the nexthop. Yes proper Expect processing needs to be done in our client (server side in our terminology). regards Henrik - Ursprungsmeddelande - On 08/20/2010 06:30 AM, Henrik Nordström wrote: tor 2010-08-19 klockan 10:41 -0600 skrev Alex Rousskov: The patch removes the ignore_expect_100 feature because we now forward 100 Continue messages. Is everybody OK with that removal? May need to keep/resurrect it when adding next hop version check as required by Expect.. Good point. The next hop version check is better done on the server side though, right? We may not yet know the next hop when accepting the request. BTW, most things in HTTP are URI- and not hostname-based. I wonder what server or next hop means when checking for supported versions. Do we look just at the host name:port and hope that it reflects the version of everything running there? Thanks, Alex.
Re: new/delete overloading, why?
2010/8/21 Henrik Nordström hen...@henriknordstrom.net: Why are we overloading new/delete with xmalloc/xfree? include/SquidNew.h this is causing random linking issues every time some piece of code forgets to include SquidNew.h, especially when building helpers etc. And I fail to see what benefit we get from overloading the new/delete operators in this way. it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. There may be nothing like that left to worry about now. -Rob
Re: new/delete overloading, why?
lör 2010-08-21 klockan 07:02 +1200 skrev Robert Collins: it was to stop crashes with code that had been cast and was freed with xfree(); if you don't alloc with a matching allocator, and the platform has a different default new - *boom*. Allocating with new and freeing with free() is a coding error in all books. There may be nothing like that left to worry about now. I sure hope not. Regards Henrik
Re: [PREVIEW] 1xx response forwarding
fre 2010-08-20 klockan 13:00 -0600 skrev Alex Rousskov: On 08/20/2010 09:26 AM, Henrik Nordström wrote: See RFC on use and meaning of HTTP version numbers. The only relevant RFC text I can find is an informal discussion that HTTP version is tied to a message sender, an undefined concept. However, even if we replace message sender with client or server, my assertion that HTTP does not guarantee that one host:port corresponds to one client or server appears to be valid. RFC 2145 section 2.3 Which version number to send in a message An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant An HTTP server MAY send a lower response version, if it is known or suspected that the client incorrectly implements the HTTP specification, but this should not be the default, and this SHOULD NOT be done if the request version is HTTP/1.1 or greater. Note: Proxy servers are both servers and clients depending on which side you look at. RFC 2616 3.2.2 http URL The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host Remember that use of NAT, TCP/IP load balancers etc is pretty much outside all normal TCP/IP specifications. IP derived specifications assumes end-to-end semantics at IP level unless otherwise explicitly stated, where relevant. Or put in other words, if you use NAT or TCP/IP load balancing or similar techniques making several different servers answer on the same ip:port then it's your responsibility to make sure your server as a whole acts in a coherent manner. As far as specifications is concerned it's still a single server, even if it internally splits the load across several physically distinct servers. Many implementations gets bitten by this at various levels, most notably for the HTTP specifications is ETag, Content-Location and Location mismatches. HTTP version is in this same category. Regards Henrik
[PATCH] Send chunked responses if body size is unknown.
Send chunked responses if body size is unknown. Apply HTTP chunked transfer encoding to the response body if all of the following conditions are met: * client claims HTTP version 1.1 or later support * response does not have a Content-Length header already * response does not use multipart/byteranges encoding * connection is persistent If we decide to send chunked reply, chunked_reply flag is set. Chunked encoding is done in ClientSocketContext::packChunk(). The last-chunk is sent only when clientReplyContext complete flag is set. This feature was requested to make Squid work with HTTP/1.1 clients that can handle chunked responses but cannot handle connection closures in the middle of a transaction sequence. The earlier version of the patch (for Squid v3.1) was tested in production. N.B. A bug in Squid may result in server-side code not treating premature server-side connection termination as an error. That bug results in Squid client-side sending a complete chunked response to the client instead of omitting the last-chunk to indicate a truncated response. Fixing that bug is outside this project scope (but we might have a patch for it somewhere, I need to check).
[PATCH] Send chunked responses if body size is unknown.
Send chunked responses if body size is unknown.
Apply HTTP chunked transfer encoding to the response body if all of the
following conditions are met:
* client claims HTTP version 1.1 or later support
* response does not have a Content-Length header already
* response does not use multipart/byteranges encoding
* connection is persistent
If we decide to send chunked reply, chunked_reply flag is set. Chunked
encoding is done in ClientSocketContext::packChunk(). The last-chunk is
sent only when clientReplyContext complete flag is set.
This feature was requested to make Squid work with HTTP/1.1 clients that
can handle chunked responses but cannot handle connection closures in
the middle of a transaction sequence. The earlier version of the patch
(for Squid v3.1) was tested in production.
N.B. A bug in Squid may result in server-side code not treating
premature server-side connection termination as an error. That bug
results in Squid client-side sending a complete chunked response to the
client instead of omitting the last-chunk to indicate a truncated
response. Fixing that bug is outside this project scope (but we might
have a patch for it somewhere, I need to check).
Send chunked responses if body size is unknown.
Apply HTTP chunked transfer encoding to the response body if all of
the following conditions are met:
* client claims HTTP version 1.1 or later support
* response does not have a Content-Length header already
* response does not use multipart/byteranges encoding
* connection is persistent
If we decide to send chunked reply, chunked_reply flag is set. Chunked
encoding is done in ClientSocketContext::packChunk(). The last-chunk
is sent only when clientReplyContext complete flag is set.
=== modified file 'compat/types.h'
--- compat/types.h 2010-07-09 13:23:03 +
+++ compat/types.h 2010-08-19 18:25:20 +
@@ -99,37 +99,47 @@
#ifndef PRId64
#ifdef _SQUID_MSWIN_ /* Windows native port using MSVCRT */
#define PRId64 I64d
#elif SIZEOF_INT64_T SIZEOF_LONG
#define PRId64 lld
#else
#define PRId64 ld
#endif
#endif
#ifndef PRIu64
#ifdef _SQUID_MSWIN_ /* Windows native port using MSVCRT */
#define PRIu64 I64u
#elif SIZEOF_INT64_T SIZEOF_LONG
#define PRIu64 llu
#else
#define PRIu64 lu
#endif
#endif
+#ifndef PRIX64
+#ifdef _SQUID_MSWIN_ /* Windows native port using MSVCRT */
+#define PRIX64 I64X
+#elif SIZEOF_INT64_T SIZEOF_LONG
+#define PRIX64 llX
+#else
+#define PRIX64 lX
+#endif
+#endif
+
#ifndef HAVE_MODE_T
typedef unsigned short mode_t;
#endif
#ifndef HAVE_FD_MASK
typedef unsigned long fd_mask;
#endif
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
#ifndef HAVE_MTYP_T
typedef long mtyp_t;
#endif
#endif /* SQUID_TYPES_H */
=== modified file 'src/client_side.cc'
--- src/client_side.cc 2010-08-18 23:43:22 +
+++ src/client_side.cc 2010-08-20 03:50:08 +
@@ -875,62 +875,81 @@ ClientSocketContext::noteSentBodyBytes(s
assert (http-range_iter.debt() = -1);
}
bool
ClientHttpRequest::multipartRangeRequest() const
{
return request-multipartRangeRequest();
}
bool
ClientSocketContext::multipartRangeRequest() const
{
return http-multipartRangeRequest();
}
void
ClientSocketContext::sendBody(HttpReply * rep, StoreIOBuffer bodyData)
{
assert(rep == NULL);
-if (!multipartRangeRequest()) {
+if (!multipartRangeRequest() !http-request-flags.chunked_reply) {
size_t length = lengthToSend(bodyData.range());
noteSentBodyBytes (length);
AsyncCall::Pointer call = commCbCall(33, 5, clientWriteBodyComplete,
CommIoCbPtrFun(clientWriteBodyComplete, this));
comm_write(fd(), bodyData.data, length, call );
return;
}
MemBuf mb;
mb.init();
-packRange(bodyData, mb);
+if (multipartRangeRequest())
+packRange(bodyData, mb);
+else
+packChunk(bodyData, mb);
if (mb.contentSize()) {
/* write */
AsyncCall::Pointer call = commCbCall(33, 5, clientWriteComplete,
CommIoCbPtrFun(clientWriteComplete, this));
comm_write_mbuf(fd(), mb, call);
} else
writeComplete(fd(), NULL, 0, COMM_OK);
}
+/**
+ * Packs bodyData into mb using chunked encoding. Packs the last-chunk
+ * if bodyData is empty.
+ */
+void
+ClientSocketContext::packChunk(const StoreIOBuffer bodyData, MemBuf mb)
+{
+const uint64_t length =
+static_castuint64_t(lengthToSend(bodyData.range()));
+noteSentBodyBytes(length);
+
+mb.Printf(%PRIX64\r\n, length);
+mb.append(bodyData.data, length);
+mb.Printf(\r\n);
+}
+
/** put terminating boundary for multiparts */
static void
clientPackTermBound(String boundary, MemBuf * mb)
{
mb-Printf(\r\n-- SQUIDSTRINGPH --\r\n, SQUIDSTRINGPRINT(boundary));
debugs(33, 6, clientPackTermBound: buf offset: mb-size);
}
/** appends a part HTTP header
Build failed in Hudson: 3.HEAD-i386-opensolaris #412
See http://build.squid-cache.org/job/3.HEAD-i386-opensolaris/412/changes Changes: [Automatic source maintenance squid...@squid-cache.org] SourceFormat Enforcement [Francesco Chemolli kin...@squid-cache.org] Compilation speedup: optimize test-suite/testheaders.sh -- [...truncated 3468 lines...] /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:176: error: `::wcrtomb' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:187: error: `::wcsrtombs' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:197: error: `::wctob' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:198: error: `::wmemcmp' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:199: error: `::wmemcpy' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:200: error: `::wmemmove' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:201: error: `::wmemset' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:202: error: `::wprintf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:203: error: `::wscanf' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:223: error: `::wcsstr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:227: error: initializing argument 1 of `wchar_t* std::wcsstr(wchar_t*, const wchar_t*)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: At global scope: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:229: error: `::wmemchr' has not been declared /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/cwchar:233: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' In file included from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ios:46, from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/ostream:45, from ../../../src/ip/Address.h:61, from ../../../src/squid.h:171, from ../../../src/base/AsyncCall.cc:5: /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static int std::char_traitswchar_t::compare(const wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: `wmemcmp' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:324: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static const wchar_t* std::char_traitswchar_t::find(const wchar_t*, size_t, const wchar_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: invalid conversion from `const wchar_t*' to `wchar_t*' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:332: error: initializing argument 1 of `wchar_t* std::wmemchr(wchar_t*, wchar_t, size_t)' /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::move(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:336: error: `wmemmove' undeclared (first use this function) /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h: In static member function `static wchar_t* std::char_traitswchar_t::copy(wchar_t*, const wchar_t*, size_t)': /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.h:340: error: `wmemcpy' undeclared (first use this function)
Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #514
See http://build.squid-cache.org/job/3.HEAD-i386-OpenBSD-4.5/514/ -- Started by upstream project 3.HEAD-amd64-CentOS-5.3 build number 768 Building remotely on vobsd Unable to obtain lock file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock held by hud...@vobsd.squid-cache.org on host vobsd.squid-cache.org [process #27278] locked 45 hours, 44 minutes ago Will continue to try until 03:27:20 bzr: ERROR: Could not acquire lock LockDir(file:///home/hudson/workspace/3.HEAD-i386-OpenBSD-4.5/.bzr/branch/lock) ERROR: Failed to pull
