> Hi Mansur,
> > Maybe it's possible to use SO_RCVLOWAT/SO_SNDLOWAT socket options?
> As far as I understand it, this should not be necessary (see below).
> > Or maybe server side should do some "reassembly" (with a little
> > timeouts to prevent DoS attacks) to get whole line of the request
> Yes, this is what the change from Mar 20th does.
> It is the new function rdLine(), which reads from the socket until at
> least a full line is received. It does so on the _receiving_ side of
> httpGate, i.e. on the way from the browser to httpGate.
> But your description seems to refer to the _sending_ side of httpGate.
> There is no special handling on the sending side, i.e. from httpGate to
> the PicoLisp process, because here plain TCP (without SSL encryption) is
> used and thus the 'line' function should be safe to receive the complete
> > 2) with httpGate
> > ! L
> > -> ("G" "E" "T" " " "/")
> > If I understand correctly, (line) immediatly returns first TCP packet
> > value. I'm not expert in TCP/IP programming, maybe reason is FreeBSD
> > itself?
> As I understand it, 'line' should not be concerned about TCP packets.
> These are on a lower level. PicoLisp reads from a socket, and should
> receive either correct data or EOF, but never partial data. It is a
> principle of TCP to handle this.
I can not agree with this. TCP guarantees only :
- data arrives in-order
- data has minimal error (i.e. correctness)
- duplicate data is discarded
- lost/discarded packets are resent
At the moment of calling (line) it's highly possible that there is no whole
line in receive TCP buffer,
and then application will get only arrived part of the request line and eof.
See also tcpdump listing in some of my prevous letters, which shows that pil
gets "GET /" piece, responds with "400 Bad request" and after that arrives the
large rest of the request.
So taking into account the principles of TCP stream that's perfectly legal
> So I must say I have no clue at the moment ... Do you have an idea how
> to further debug this?
Currently I think that pil server needs to do something to wait until more data
Maybe at the lisp level (in http function) or with socket options.