[Web-SIG] httplib and 100-continue support
graham.dumpleton at gmail.com
Wed May 26 07:26:13 CEST 2010
On 26 May 2010 15:19, Deron Meranda <deron.meranda at gmail.com> wrote:
> On Wed, May 26, 2010 at 12:32 AM, Graham Dumpleton
> <graham.dumpleton at gmail.com> wrote:
>> Bigger problem may be to find a server which actually supports
>> 100-continue in the way one would expect it to work.
> Fortunately in my specific case that's not an issue as I wrote
> the server from scratch (in C) and so I have full control over exactly
> how it works and how closely to the RFC I can make it. ... This is
> not a general-purpose web server (or I'd be using Apache/mod_wsgi
> here), but its a REST interface to a complex application. It's also giving
> me a good excuse to get even more familiar with the intricacies of the
> HTTP/1.1 spec. -- So unlike most of my projects where I have Python
> on the server side ; in this case my Python is just on the client side.
> But for the wider consideration, it's good to know that server-side
> support for 100-continue with Python currently has its limits as well.
>> If you want to upload to a Python web application your options are
>> possibly quite limited.
>> In the Apache space, the following definitely work:
>> * mod_wsgi embedded mode
>> And the following will not work as desired:
>> * mod_wsgi daemon mode
> Is this a limit in the WSGI spec, with Apache, or just something
> with the current version of mod_wsgi?
> I know you've proposed many changes to WSGI to fix a lot
> of things, and a lot of the discussions seem to be on the
> encoding or decoding of headers. But was this ability to
> do things like the 100-continue also among the issues that
> have been raised?
The limitation is purely an implementation detail of the Apache module
for each of those I listed, including the daemon mode part of
mod_wsgi, and nothing to do with WSGI specification.
In short, to handle end to end 100-continue, one would need to
preserve the concept of a handshake between the Apache server child
process doing the proxying and the back end server. That is, back end
server sends equivalent of 100 status only when WSGI application first
performs a wsgi.input.read() and proxying process only starts sending
data when it sees that.
This can be done but was easier to ignore it for now just like every
other proxying solution ignores the problem. It works for embedded
mode of mod_wsgi because Apache in that case handles it for you
without you doing anything.
More information about the Web-SIG