Parsing MIME-encoded data in an HTTP request
Ron Garret
rNOSPAMon at flownet.com
Fri Jul 4 03:17:14 EDT 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