Re: LunarCGI (was Re: CGI.lua - A native CGI Interface)

["Robert G. Jakabosky" <bobby@...>]

On Friday 25, Chris Babcock wrote:
> On Fri, Feb 25, 2011 at 6:41 PM, Miles Bader <miles@gnu.org> wrote:
> > Sebastien Lai <237482@googlemail.com> writes:
> >> Currently, that seems like a fairly impossible target, considering that
> >> Perl for example, makes heavy use of its regular expression engine to
> >> parse the data properly.
> > 
> > LPEG?
> 
> Overkill. The spec uses a grammar, but it's written so that it doesn't
> require a grammar to implement the parser. The string library is
> perfectly adequate for the task. I've written MIME parsers using
> regexps before. (I'm still using one.) It's like using a sledge hammer
> to drive finish nails.

I also think LPEG would be overkill to parse multipart messages.  I have 
written Lua code [1] for encoding form data (with support for file uploading) 
into multipart messages.  It is a part of my lua-handlers [2] project which I 
was planing on adding a simple async HTTP server to (which would require 
support for parsing multipart messages).


> The client is supposed to supply a boundary string that does not occur
> in the content, so if it happens that you find an instance of the
> boundary string that leads to parsing errors then you treat the whole
> message as invalid.
> 
> There's more to parsing multipart messages than just that boundaries,
> but if I understand correctly that is the concern of the OP.

Each part of the multipart message (the part between boundaries) is like a 
simple HTTP message with HTTP-style headers and a blank line before the 
content of the message part.


1. https://github.com/Neopallium/lua-
handlers/blob/master/handler/http/form.lua
2. https://github.com/Neopallium/lua-handlers

-- 
Robert G. Jakabosky