Re: Lua Socket

[Diego Nehab <diego@...>]

Hi,

> 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
> > helpful.
>
> 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
SMTP server.

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?

Regards,
Diego