Parsing MIME-encoded data in an HTTP request

Ron Garret rNOSPAMon at flownet.com
Fri Jul 4 09:17:14 CEST 2008


In article 
<4834df8f-2cf8-434c-8c95-ff53024766c8 at p25g2000hsf.googlegroups.com>,
 s0suk3 at gmail.com wrote:

> On Jul 3, 3:59 pm, Ron Garret <rNOSPA... at flownet.com> wrote:
> > I'm writing a little HTTP server and need to parse request content that
> > is mime-encoded.  All the MIME routines in the Python standard library
> > seem to have been subsumed into the email package, which makes this
> > operation a little awkward.
> 
> To deal with messages of that kind, I've seen modules such as
> 'rfc822', and 'mimetools' (which apparently builds itself from
> 'rfc822', so it might be more complete). There's also 'mimetypes', in
> case you need to deal with file extensions and their corresponding
> MIME media type.

>From the mimetools docs:

"Deprecated since release 2.3. The email package should be used in 
preference to the  module. This module is present only to maintain 
backward compatibility."

> 
> > It seems I have to do the following:
> >
> > 1.  Extract the content-length header from the HTTP request and use that
> > to read the payload.
> >
> > 2.  Stick some artificial-looking headers onto the beginning of this
> > payload to make it look like an email message (including the
> > content-type and content-transfer-encoding headers)
> >
> > 3.  Parse the resulting string into a email message
> >
> 
> Email? Why does an HTTP server need to build an email message?

It shouldn't.  That's my whole point.  But see the docs excerpt above.

> I remember doing things like that some time ago when building an HTTP
> server myself (http://code.google.com/p/sws-d/). Incidentally, I
> resisted the urge to use much of the Python's library facilities (most
> things are done manually; am I a knucklehead or what!? :). You might
> wanna take a look to get some ideas.

I'd much prefer not to reinvent this particular wheel.

rg



More information about the Python-list mailing list