Re: [Apt-proxy-users] NetServer::Generic

[Jason B. <ja...@ed...>]

On Tuesday 12 March 2002 04:02 am, you wrote:
<snip>
> I'm no expert, but looking at the manpage for sysread I can't see how you
> can say 'pull in this amount of input until a newline or you read a maximum
> length' with sysread.  Is it possible to specify nonblocking behaviour, so
> that it would return immediately even if the client hadn't sent LENGTH
> bytes?

I modified the example to use sysread() instead.  Of course the echo server 
is a line based server, so using sysread() breaks the input up, ignoring line 
and word boundries as it goes.

But it seems happy to pull in an amount <= whatever you specify.  So I tested 
by pulling in 9 bytes and it happily accepted less than that and looped when 
there was more data than that.

The forked client will happily sit around and wait for data forever, though, 
so using sysread won't be that useful for playing with data coming from a 
client requesting a file.  I guess it won't be useful for preventing attacks 
from malicious servers, either, since you can't rely on the Content-Length 
returned from the server...

I guess if the bug was that easy to solve, the author would've simply noted 
that you need to use sysread() instead of <STDIN>.

My concern is actually that using a while() construct on <STDIN> and having 
it read until a newline, which is the default behavior, will result in pieces 
of varying sizes being slurped into memory from a debian mirror sending 
binary data, since who knows when a 'newline' will 'show up' in a pile of 
bits.  That's why I was thinking of sysread().  At least, then we could 
sysread() in chunks of a sane size up to Content-Length, which we'd know to 
be correct.  (Assume we aren't talking to a malicious server, of course.)

Excuse my clueless posts.  I've been sick this week.

> Chris
>