On 2002-12-23 11:09:40, Wez Furlong wrote:
> Isn't the solution as "simple" as changing the #ifdef to include
> COMPILE_DL_ZLIB in the checks, or is this another situation where the
> zlib extension should be compiled into the distribution itself?
Probably the second one is the easier solution.
W
On 2002-08-12 11:34:40, Marcus Börger wrote:
> We will drop the double buffer again and my favorite would be changing
> zlibs default
> to 16K (resulting in 4K output chunks).
>
> But we must document this stuff
Yes, and provide useful defaults, I think there are some sites which
have switc
On 2002-08-11 02:32:50, Yasuo Ohgaki wrote:
> Log:
> Changed my mind.
> Let users decided whether users want larger chunk size or not.
> @ Changed zlib.output_compression behavior. If larger chunk is preferred,
> enable output_buffering also. (Marcus, Yasuo)
The NEWS entry got truncat
On 2002-08-01 02:28:26, Rasmus Lerdorf wrote:
> That fixed part of it, there is still another segfault in there somewhere.
Maybe it has to do with the silly strncasecmp error I made (and just
committed a fix to SAPI.c), but I don't know how this would cause a
segfault.
Stefan
--
Stefan Röhri
On 2002-06-26 19:55:33, Marcus Börger wrote:
> A hosting company would use mod_gzip if compression is necessary
> for them
Not necessarly. It does make sense to use transparent compression only
for dynamically created pages, so that static pages can be cached.
And if you are a user of a mid size
On 2002-06-26 20:19:34, Yasuo Ohgaki wrote:
> I'm -1 for features that silently fails.
> User can check ini_set return value if it is successful or not.
> So I'm 0 for ini_set("zlib.output_compresion","Off");
I don't understand your first two sentences, what do you mean with
"silently fails"? The
On 2002-06-25 09:36:20, Yasuo Ohgaki wrote:
> Yasuo Ohgaki wrote:
> >I would suggest turn off compression for image.
> I mean turn off compression manually.
> >As you already know, turning on and off by header(mime-type)
> >does not work always, thus it's confusing.
Yes, but we need some kind of
Hello!
There has been a bug report (#16109) about a bug in Netscape 4.79,
which doesn't display images if Content-Encoding: gzip is used. After
thinking about a browser detection config flag for zlib.output
compression, at LinuxTag we discussed, that a more general solution
would be better, that
Hello!
On 2002-06-05 15:39:55, Lenny Miceli wrote:
> issue. Even though I didn't compile php with the --with-zlib option when I
> run strings against the php library I still see zlib information. For
Maybe zlib is used by another library which PHP uses (e.g. some
graphic library, MySQL, ...).
On 2002-04-21 09:42:44, Stig S. Bakken wrote:
> I think interfaces are a great API, not just for creating specific
> interfaces between specific extensions, but to let any "reusable"
> extension define a C interface. With this API, we can solve interface
I like this idea, too. This would make a
On 2002-03-29 10:43:17, Jan Pavlík wrote:
> I will rewrite PHP to log only ONE error when the next errors are the same.
Maybe you can try logging errors to syslog, not to a file. Many syslog
daemons seem to have some logic to detect repeating messages and only
log something like "last message rep
On 2002-03-20 04:51:35, Rasmus Lerdorf wrote:
> That sounds good.
> On Wed, 20 Mar 2002, Wez Furlong wrote:
> > It was my intention to put the state into the stream structure
> > and nuke the global, so that the state is per stream, which makes
> > a bit more sense since running two fgetss() in "p
On 2002-03-19 16:40:51, Rasmus Lerdorf wrote:
> This is a remnant from my original implementation in PHP 2. It was
> committed: Mon May 20 15:20:25 1996 (5 years, 10 months ago)
Some code never goes away ;-) ...
> Having that level of revision history is actually pretty cool if you ask
> me. T
On 2002-03-19 21:35:09, Wez Furlong wrote:
> Well, that appears to be the intention, but I couldn't see
> a single line where the state variable is assigned to; it's
> passed by value, so I can't see how FG(fgetss_state) is ever
> set to a value other than 0?
Ups, this really looks like an oversi
On 2002-03-18 23:23:00, Wez Furlong wrote:
> Does anyone know what purpose FG(fgetss_state) serves?
As I remember it holds the internal state of php_strip_tags.
> It doesn't appear to do anything other than hold the value
> 0 for php_strip_tags.
> Is this an oversight or a leftover of some old c
On 2002-03-16 01:11:11, Wez Furlong wrote:
> Can you tell me which include files are needed to correct
> the build on your system?
> Then I can fix it :-)
Your fix to the .h file helped (even without the (long) change).
Maybe we can use a configure check for ptrdiff_t like in
ext/bcmath/libbcmat
Hello!
On 2002-03-15 21:12:36, Wez Furlong wrote:
> Please please please test the following things in particular
> as I can't compile them or verify them here:
I can't compile, because it complains about `ptrdiff_t' undeclared in
main/network.c. I think stddef.h or similar is needed in this file
On 2002-03-11 23:28:36, Rasmus Lerdorf wrote:
> It seems to work quite nicely for most. Having the mailing list software
> remove a user's ability to control where replies go is even nastier. Add
Yes, in general I'm against adding forced Reply-To headers by mailing
list software, too (having re
On 2002-03-12 10:50:43, Andrey Hristov wrote:
> What about implementing in build process check for the version of
> the zlib library. If <=1.1.3 to give error message that >=1.1.4 is
> needed. 1.1.4 is at :
I already thought about that, but there are people or even whole linux
distributions (e.g.
Hello!
I have two patches for zlib.c, but before commiting, I would like to
hear some comments.
First patch (should fix bug #14939):
I could reproduce #14939 even with a simple C program, so I think,
it's rather a very unusual behaviour of the zlib library which seems
to want to read a little b
Hello!
On 2002-03-07 18:04:09, [EMAIL PROTECTED] wrote:
> Well, I prefer the fonctionnality in documentation
> or something like : gzencode($data[,$level[,$mode]])
There was an error in the documenation of gzencode(), the second
(optional) parameter wasn't the compression level, it was a
compres
On 2002-02-17 19:31:40, André Næss wrote:
> I just read some general discussions on the topic in misc. security related
> boards and got the impression that the consensus was that MD5 should be
> phased out and replaced by SHA-1.
That may be true for some new applications (where you can use
mhash
On 2002-02-17 17:35:26, André Næss wrote:
> nice though, just to tell people about other hashing functions. Maybe there
> should also be a mention of the fact that MD5 is fairly easy to crack?
Can you give some references?
Yes, MD5 does have some weaknesses (so SHA1 would probably be better),
bu
23 matches
Mail list logo
