Henrik Nordström wrote:
How I have done it in the past is to use a configure cache presetting
the runtime test appropriately for the target.
But this requires that all AC_TRY_RUN checks are made cacheable.
The ./configure raw code shows that the autoconf people use [:] in their
own run-time
See
http://build.squid-cache.org/job/3.HEAD-sparc-opensolaris-SunStudioCc/204/changes
Amos Jeffries wrote:
Henrik Nordström wrote:
How I have done it in the past is to use a configure cache presetting
the runtime test appropriately for the target.
But this requires that all AC_TRY_RUN checks are made cacheable.
The ./configure raw code shows that the autoconf people use [:]
Great job!
Thanks guys ;)
On Sunday, August 29, 2010, Amos Jeffries squ...@treenet.co.nz wrote:
Thanks Markus. That worked.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.7
Beta testers wanted for 3.2.0.1
--
/kinkie
Thank you for this nice patch. It works very nice.
But now, I got following error:
ı/cf_gen cf.data ../../src/cf.data.depend
make[1]: ./cf_gen: Command not found
make[1]: *** [cf_parser.cci] Error 127
make[1]: Leaving directory
`/home/kromonos/buildroot/build/squid-3.1.6/build/src'
make: ***
sön 2010-08-29 klockan 18:59 +1200 skrev Amos Jeffries:
I *think* this will remove the need for such pre-seeding.
cross-compiles should always have all run tests preconfigured for the
target, or result in a default results in probe at runtime. The tests
are there for a reason, if not we could
sön 2010-08-29 klockan 12:02 +1200 skrev Amos Jeffries:
Right now we have siblings, parents, and multicast peers with their own
types. By origin servers require both parent and origin flags to be set.
Always been the intention to have an origin type peer, just haven't got
implemented yet. But
Am Sun, 29 Aug 2010 schrieb Henrik Nordström:
sön 2010-08-29 klockan 18:59 +1200 skrev Amos Jeffries:
I *think* this will remove the need for such pre-seeding.
cross-compiles should always have all run tests preconfigured for the
target, or result in a default results in probe at
On 08/29/2010 07:13 AM, Henrik Nordström wrote:
sön 2010-08-29 klockan 12:02 +1200 skrev Amos Jeffries:
Right now we have siblings, parents, and multicast peers with their own
types. By origin servers require both parent and origin flags to be set.
Always been the intention to have an origin
sön 2010-08-29 klockan 11:16 -0600 skrev Alex Rousskov:
It may be confusing to have origin type peer and originserver flag at
the same time. Please consider either renaming or documenting to resolve
the naming conflict.
Should be easy to solve by documenting the option reasonably.
Regards
On 08/29/2010 12:43 AM, Amos Jeffries wrote:
One of our users uncovered a nasty bug in 3.1 today. Squid hangs on some
simple requests.
FWIW, it is not clear to me what is so nasty about this bug: Squid waits
for more input. So what? A benign malformed request will eventually
timeout (if not,
sön 2010-08-29 klockan 15:17 +0200 skrev kromo...@user-helfen-usern.de:
A
No need to do, I think. It's like cross compiling python. maybe, it's
possible to first create cf_gen with host compiler and set a variable
for make command, which says, which cf_gen to use. So, host cf_gen could
be
lör 2010-08-28 klockan 14:26 +1200 skrev Amos Jeffries:
The author confirmed in bugzilla that he was happy with it being labeled
GPLv2 and changed the COPYING file over before I merged.
http://bugs.squid-cache.org/show_bug.cgi?id=2905
We seem to have missed some of the GPL references in
Compliance: reply with 400 (Bad Request) if request header is too big.
Reply with a standard 400 (Bad Request) instead of 601 (Unknown) status
in case of an ERR_TOO_BIG error. HTTP does not have a dedicated code for
the too-big header error. There is 414 (Request-URI Too Long), but Squid
does
On Sun, 29 Aug 2010 14:57:08 -0600, Alex Rousskov
rouss...@measurement-factory.com wrote:
Compliance: reply with 400 (Bad Request) if request header is too big.
Reply with a standard 400 (Bad Request) instead of 601 (Unknown) status
in case of an ERR_TOO_BIG error. HTTP does not have a
On Sun, 29 Aug 2010 12:07:02 -0600, Alex Rousskov
rouss...@measurement-factory.com wrote:
On 08/29/2010 12:43 AM, Amos Jeffries wrote:
One of our users uncovered a nasty bug in 3.1 today. Squid hangs on
some
simple requests.
FWIW, it is not clear to me what is so nasty about this bug: Squid
Compliance: Ignore unused chunk-extensions to correctly handle large ones.
Chunk parser did not advance until it got a complete chunk-extension.
HttpStateData::maybeReadVirginBody() does not grow the buffer if there
is no space available for the [chunked] body so the transaction with a
large
On 08/29/2010 05:09 PM, Amos Jeffries wrote:
* FooInit() is a C version of a Foo class constructor. I would recommend
converting HttpParserInit() to a constructor since you are polishing
this code anyway, but if you leave init() in place, please call clear()
_after_ performing any
On Sun, 29 Aug 2010 19:22:02 -0600, Alex Rousskov
rouss...@measurement-factory.com wrote:
On 08/29/2010 05:09 PM, Amos Jeffries wrote:
* FooInit() is a C version of a Foo class constructor. I would
recommend
converting HttpParserInit() to a constructor since you are polishing
this code
On 08/29/2010 09:08 PM, Amos Jeffries wrote:
By offset memory I mean the values from previous runs that HttpParser
stores for offset to various pieces of the request line.
init() reset the overall start/end offsets known for the line, but left
the finer details like start/end offsets in held
20 matches
Mail list logo
