使用Django/PyISAPIe/IIS时，大型POST数据已损坏

Question

当使用Djang1.2.3、PyISAPIe v1.1.0-rc4和IIS7.5时，我遇到了大量POST数据(>16384字节)的问题。

例如，当提交大约。使用POST提供60 of的表单数据时，会发生以下情况：

• 第一个16 of的POST数据块是正确的
• 下一个16 of块是第一个块的重复。
• 下一个16 of是第一个块的另一个重复。
• 其余的(<16 is )再次正确。

有趣的是，当使用content-type="multipart/form-data"时，它工作得很好。

使用这一信息，我在WSGIRequest._get_raw_post_data中跟踪了bug可能在django\core\handlers\wsgi.py中的位置，这与默认(没有内容类型)大小写分别处理content-type="multipart/form-data"。

这两种情况都是从self.environ['wsgi.input']读取的，后者被设置为PyISAPIe对象。不同之处在于，默认的大小写似乎是以16 2GB的块读取，而多部分处理程序似乎是以略低于2GB的块读取。

我对C和Python接口还不太了解，无法让C进一步深入研究，但我猜这个bug在PyISAPIe中的ReadWrite.cpp函数中的某个地方。

我目前的解决办法是将content-type="multipart/form-data"添加到可能产生超过16 of数据的表单中。

是否有人也遇到过这种情况，或者是否有人知道如何确定该bug是否存在于PyISAPIe中？

谢谢!

Answer 1

这里是PyISAPIe作者。

这是在存储库中的修订本184中修复的，但在可下载的版本中没有修复，就像在邮寄名单上讨论的那样。

它解决了一个以前有记录错误，这个bug显然没有得到太多的关注，因为很多用户都在查看源代码，而不是下载包。或者，这是我最好的猜测；无论如何，我计划提供一个固定代码的可下载版本。

谢谢你让我注意到这一点，这样我就可以被提醒让这个项目的版本保持在正常运行状态。

Answer 2

我挖得更深了点，我想我发现了这个问题。

在PyISAPIe\Readwrite.cpp中：

PyISAPIe_Func(DWORD) ReadClient( Context &Ctx, DWORD Length, void *const Data )
{
  if ( !Length )
    Length = Ctx.ECB->cbTotalBytes;

  if ( !Data )
    // Return the size of the the data that would be read
    return min(Length, Ctx.ECB->cbTotalBytes);

  DWORD Ret, Total = 0;

  if ( Length > Ctx.ECB->cbAvailable )
  {
    [...snip...]
  }
  else
  {
    memcpy(Data, Ctx.ECB->lpbData, Length);
    Ctx.ECB->cbTotalBytes -= Length;
    Ctx.ECB->cbAvailable -= Length;
    return Length;
  }

如果重复调用长度为<= Ctx.ECB->cbAvailable的方法，则似乎总是将Ctx.ECB->lpbData缓冲区的开头复制到数据中，而不是从缓冲区中删除该数据或推进指针。只有当数据耗尽(cbAvailable == 0)时，新数据才会在代码的后面正确地读入数据中。

仍然不知道如何修复它，但至少我可以通过阅读足够大的数据块来解决这个问题，这样一组数据就可以全部读取。