Both of these are non-standard headers created by microsoft.
These are both weird ones. We seem to need them, but only because they
need to be stripped away in certain circumstances.
The Translate: header is the trickiest. After reading the docs it
appears we should be always stripping it awa
vollkom...@gmx.net wrote:
Here's what I did and the outcome, with squid-3.HEAD-20090511:
patch -p0 < b9683.patch
vi src/asn.cc
/* template cbdata_type CbDataList::CBDATA_CbDataList;
*/
Then 2) & 3).
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I../..
-I../../include
On Mon, May 18, 2009 at 1:05 PM, Amos Jeffries wrote:
> Both of these are non-standard headers created by microsoft.
>
> These are both weird ones. We seem to need them, but only because they need
> to be stripped away in certain circumstances.
>
> The Translate: header is the trickiest. After rea
Kinkie wrote:
On Mon, May 18, 2009 at 1:05 PM, Amos Jeffries wrote:
Both of these are non-standard headers created by microsoft.
These are both weird ones. We seem to need them, but only because they need
to be stripped away in certain circumstances.
The Translate: header is the trickiest. Af
Sorry to be blunt, but shouldn't these sites be securing themselves?
Having Squid strip this header hardly closes any significant attack
vectors off... and doing so creates yet another special case for
people to work around.
-1 on Translate (default strip; registering it, I suppose, althoug
Mark Nottingham wrote:
Sorry to be blunt, but shouldn't these sites be securing themselves?
Having Squid strip this header hardly closes any significant attack
vectors off... and doing so creates yet another special case for people
to work around.
-1 on Translate (default strip; registering i
Thanks. Since I didn't want to wait for 3.HEAD-20090519, I simply applied your
patch to the 3.HEAD-20090518 source. Here's the output:
patch -p0 < b9686.patch
...
g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../src -I../../include
-I/usr/include/libxml2 -Werror -Wall -W
> Thanks. Since I didn't want to wait for 3.HEAD-20090519, I simply applied
> your patch to the 3.HEAD-20090518 source. Here's the output:
>
We do have to wait unfortunately. The autotools bootstrapping is not part
of the patches. The snapshot is out now.
Amos
Please find below the output of "make -w -d" against the 3.HEAD-20090519 source.
...
rm -f .libs/squid.nm .libs/squid.nmS .libs/squid.nmT
creating .libs/squidS.c
(cd .libs && gcc -g -O2 -c -fno-builtin "squidS.c")
rm -f .libs/squidS.c .libs/squid.nm .libs/squid.nmS .libs/squid.nmT
g++ -Werror -Wal
tools.c:fatal() dumps core because it calls abort.
Considering that the core can be quite large (esp. on a 64bit system),
and that there's fatal_dump() as well if you really want one, can we
just make fatal() exit(1) instead of abort()ing?
Cheers,
--
Mark Nottingham m...@yahoo-inc.co
just make that behaviour configurable?
core_on_fatal {on|off}
Adrian
2009/5/19 Mark Nottingham :
> tools.c:fatal() dumps core because it calls abort.
>
> Considering that the core can be quite large (esp. on a 64bit system), and
> that there's fatal_dump() as well if you really want one, can w
11 matches
Mail list logo
