On Thu, 4 Mar 2004, Adrian Chadd wrote:
On Thu, Mar 04, 2004, Adrian Chadd wrote:
You need to remove far more fd_set references if this is the problem.
There is also seveal delay pool related fd_set usage in comm_poll, and a
few other places I think.
Ok. I must've missed them.
-- Forwarded message --
Date: Fri, 5 Mar 2004 00:18:04 +0100 (CET)
From: Henrik Nordstrom [EMAIL PROTECTED]
To: Jon Kay [EMAIL PROTECTED]
Cc: Henrik Nordstrom [EMAIL PROTECTED]
Subject: Re: Content-Encoding and storage forma
On Thu, 4 Mar 2004, Jon Kay wrote:
So, are you
Henrik Nordstrom wrote:
On Wed, 3 Mar 2004, Jon Kay wrote:
Because current browser implementations treat Content-Encoding much as
though it was Transfer-Encoding, we will implement Content-Encoding and
Accept-Encoding as though they were actually the Transfer-Encoding and
TE described
I think our decision not to keep just encoded versions around
immunizes us from that one; I don't see how a redecoding could arise,
as encoded versions follow different paths to encoding-accepting
clients than decoded versions to unaccepting, purist clients.
I do not quite follow what
On Thu, Mar 04, 2004, Henrik Nordstrom wrote:
Ok. I must've missed them. Let me go through the codebase and remove
all references to fd_set when you're not actually using select().
Ok, the only use I can see is in the slowfds use. The other use of
fd_set is in the select() codepath.
Coontent-Encoding and Transfer-Encoding is fundamentally different in
their operation far beyond the hop-by-hop vs end-to-end difference. You
can not interchange one for the other.
It is not safe to assume a clients accepts gzip TE only because they
accept gzip content-encoding. For one
