[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Socket
- From: Diego Nehab <diego@...>
- Date: Sat, 21 Jul 2007 19:05:49 -0400 (EDT)
And the other reason, even with non-blocking I/O, is that
it can still be considered handy to limit the maximum
amount of data you'll have to handle in one go. (You might
get a lot of already-buffered-elsewhere data back before
blocking, after all.)
I believe that if set the timeout to zero, there is no risk
you will get a lot of data. The maximum amount of data is
LuaSocket's buffer size, which is really not that much.
I try to cover most of the use cases, but I usually
avoid introducing to too much complexity into the
library. I know, each request seems simple, but once they
pile up, things become untreatable. Are there many
protocols that behave like this? Examples would be
SMTP and HTTP spring to mind. My point is that as things
stand, you can't use the mightily convenient "*l" when
writing, say, an SMTP server which implements (or at least
allows as an option) _strict_ compliance with RFC2821. I
believe the same is true for HTTP (many servers allow
lines to end just LF, but strictly speaking, CRLF is
required). Numerous other line-oriented protocols specify
CRLF, if I recall correctly, and actually disallow CR on
its own (a condition you cannot test for with "*l" because
it blindly eats CRs) anywhere, or LF on its own.
I think the problem you are talking about is with the
termination of the DATA command in SMTP, where '<LF>.<LF>'
must not be considered the same as '<CRLF>.<CRLF>'. I agree
something must be done about this if you are implementing an
On HTTP, things are more complicated. The standard
explicitly says tolerant servers should behave just like
LuaSocket, accepting <LF> as line terminator and ignoring
the leading <CR> within control structures. Within entity
bodies, it's not even a matter of tollerance, servers must
accept any variation of line termination.
I am not sure your suggestion fixes these problems. Strict
compliance to standards is very important. I am all for
that, and in fact I've spent a lot of time working around
broken implementations. However, I don't think there is
an easy solution to the problem.
I just think that completeness requires that you be able
to reconstruct the input data after receiving it, and it
seems a pity that you can't do that if you want to use
"*l" -- you have to implement your own buffering in Lua on
top of the buffering already implemented below.
This is a nicer request. Maybe I should return the detected
line break as an extra argument?