[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LunarCGI (was Re: CGI.lua - A native CGI Interface)
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Fri, 25 Feb 2011 22:00:34 -0800
On Friday 25, Chris Babcock wrote:
> On Fri, Feb 25, 2011 at 6:41 PM, Miles Bader <firstname.lastname@example.org> wrote:
> > Sebastien Lai <email@example.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  for encoding form data (with support for file uploading)
into multipart messages. It is a part of my lua-handlers  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.
Robert G. Jakabosky