> > But your description seems to refer to the _sending_ side of httpGate.
Still, if the _receiving_ side of httpGate doesn't get complete data,
the sending side will also fail. This was the issue with the fix from
> > 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,
Yes, but then 'line' will get some characters and wait. It will not
return until it sees EOL or EOF. If this were not the case, the whole
PicoLisp server would never work. There are always glitches and delays
in a connection.
> and then application will get only arrived part of the request line and eof.
No. EOF will only arrive when the connection is closed. And in our case,
the connection is not closed, just some TCP packets on the lower layers
> 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
No. This looks very much to me like the situation before March. The
receiving side of httpGate didn't handle partial lines correctly, and
then httpGate sent only a partial line to PicoLisp.
I cannot imagine how this could happen now.
Are you really, really very sure that it is not an old binary which is
running, though httpGate.c is new?
If so, perhaps you could send me part of the output of 'strace' of
httpGate, so see exactly what was read and what was sent, and if and
when the connection was closed by whom.