(possible?) bugfix for squid-3.0

[garana]

Hi,

The patch attached fixes a possible bug:
in pconn.cc:314 there is a call to strncpy, but xstrncpy should be used, since strcmp 
is used for key comparison (pconn.cc:231).

pconnKey:
snprintf(buf, SQUIDHOSTNAMELEN * 2 + 10, );

pconnPop:
strncpy(key, pconnKey(host, port, domain), SQUIDHOSTNAMELEN + 10);

so, there is a chance that 'key' isn't actually zero terminated, which is a problem 
since strcmp is used in key comparison.

There are other strncpy calls that seem dangerous:
src/neighbors.cc:904
src/tools.cc:1221
I didn't came across yet with a bug in theese calls, though.

This could explain some of the memory corruption (in really long hostname lengths).

Hope this helps,

-- 
Gonzalo Arana
Ingenieria
UOLSinectis

Florida 537 Piso 6, Buenos Aires, Argentina 
+54-11-4321-9110 ext 2543
http://www.uolsinectis.com.ar/

diff -bur squid-3.0-PRE3-20040302-ori/src/pconn.cc squid-3.0-PRE3-20040302/src/pconn.cc
--- squid-3.0-PRE3-20040302-ori/src/pconn.ccSat Aug 16 07:04:34 2003
+++ squid-3.0-PRE3-20040302/src/pconn.ccThu Mar 11 17:32:23 2004
@@ -262,7 +262,7 @@
 }
 
 assert(table != NULL);
-strncpy(key, pconnKey(host, port, domain), SQUIDHOSTNAMELEN + 10);
+xstrncpy(key, pconnKey(host, port, domain), SQUIDHOSTNAMELEN + 10);
 
 p = (struct _pconn *) hash_lookup(table, key);
 
@@ -310,7 +310,7 @@
 int fd = -1;
 LOCAL_ARRAY(char, key, SQUIDHOSTNAMELEN + 10);
 assert(table != NULL);
-strncpy(key, pconnKey(host, port, domain), SQUIDHOSTNAMELEN + 10);
+xstrncpy(key, pconnKey(host, port, domain), SQUIDHOSTNAMELEN + 10);
 hptr = (hash_link *)hash_lookup(table, key);
 
 if (hptr != NULL) {

Re: next version of content-encoding / gzip design doc

[garana]

Hi there,

I'm back with this task (again).

Jon: you are far more advanced than I am on understanding squid.  I can start helping 
content compression writing GzipCoder, if you want to.

(Already discussed) About TE/Transfer-Encoding vs Accept-Encoding/Content-Encoding:  
Content-Encoding implementation (even if it bends standards) seems to be the 
reasonable choice, since TE/Transfer-Encoding is not available on most common browsers.

If implemented as Content-Encoding the following headers should be altered before 
encoding:

Content-Length: deleted (could be updated to actual gzipped content length, but it is 
too much trouble i guess).
ETag: modified (appending CEgz, for instance?)
Vary: append Accept-Encoding (if not already there)
Connection: if client is 1.1, could be set to keep-alive, but Transfer-Encoding 
chunked should be added/checked.

Hope this provides some light about possible encoding options.

Regards,

-- 
Gonzalo Arana
Ingenieria
UOLSinectis

Florida 537 Piso 6, Buenos Aires, Argentina 
+54-11-4321-9110 ext 2543
http://www.uolsinectis.com.ar/