[Featureserver] [PATCH] handle multipart POSTs

Dan Lipsitt danlipsitt at gmail.com
Wed Jan 16 19:46:21 EST 2008

On Jan 16, 2008 7:19 PM, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> On Wed, Jan 16, 2008 at 06:30:52PM -0500, Dan Lipsitt wrote:
> > On Jan 16, 2008 5:30 PM, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> > > This only adjusts the wsgi handler. Is this a problem specifically for
> > > that handler for some reason?
> >
> > It may be present in the other handlers, but I'm not using them right
> > now. The logic that was broken was in the wsgi handler, but perhaps it
> > could be factored out and used for all of them.
> >
> > > Can you explain how I encounter misbehavior this fixes?
> >
> > It was treating multipart boundaries as part of the uploaded file.
> >
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.2
> >
> > Notably, the php Request module builds multipart POST.
> I guess the problem I'm having, conceptually, is that you're not
> uploading *files*, you're POSTing *strings*, and I'm confused why it
> would be doing multipart POST for that. Can I see some example code that
> I could cause it to reproduce with? (No need for it immediately, but I
> want to make sure I really understand first.)

Well, the short answer is that a multipart POST happens to be the
output of the tool I'm using. Conceptually (to me), I actually am
posting a file. It's a GML file on my disk, and the easiest way to get
it onto the wire seemed to be with the method I was using. I actually
tried to send it in a single-part POST, but the library I was using
choked with an out of memory error. That's not your fault, of course.
The files I'm playing with now are up to about 8MB, by the way.

> It's possible that this is an 'enhancement', rather than 'bug', in
> ticket tracking speak. If that's the case, I think I understand it and
> it makes sense. If it's a 'bug', then I don't understand it.

I guess it depends on your spec. The home page said I could use POST,
but it didn't say it was limited to certain content types.

This is actually a bit more than academic to me because the
application I'm trying to build right now involves having users upload
shapefiles. I currently have to convert them to GML, but it would be
pretty cool if I could import the files directly. I know that I can
set a shapefile up as a DataSource, but that requires editing the
config and restarting the server. So what I'm getting at is that if
someone created a OGR Service (as opposed to a DataSource), I might
want to upload multiple files into it at a time (since a shapefile is
actually several -- .shp, .dbf, .prj). A good way to do this might be
as a multipart POST.

> In either case, it's somewhat important to me to make all three (wsgi,
> mod_python, cgi) support the same level of functionality, so someone
> will need to hack the support into the other two handlers: I'll add this
> to my todo list to do if no one else gets to it first.

I probably won't beat you to it unless I end up needing to actually
use the others.

> > It's read-only. I implemented handle_post() for item creation.
> Hm, I'd take a patch, though I'd then have to change the WFS -> GML,
> since WFS 'creation' is WFS-T, which I'm assuming isn't what you
> implemented. That's not really a problem, just me talking out loud.

I actually didn't realize that WFS was dealing with GML when I first
started. No I didn't implement WFS-T. What I implemented is actually
kind of OGR-specific since I need the values it pulls out of the
shapefile's DBF.

I'm using these mappings:

          'gml': 'GML',
          'application/vnd.ogc.gml': 'GML'


More information about the Featureserver mailing list