CGIHTTPServer and POST with Netscape versus IE

[Changjune Kim]

My first thrust at the problem was using select. But it worked sometimes
and didn't work sometimes.

The securest way was to resort to checking the agent type and doing
blocking-read for garbages in case it's IE.


"Kevin Altis" <altis at semi-retired.com> wrote in message
news:bytS9.185$wz1.174516 at news.uswest.net...
> Well I was going to say this is fixed in the Python 2.3a1 release because
I
> thought Steve Holden had committed a fix, but I just checked the
> CGIHTTPServer.py file and it doesn't appear to have changed, so maybe
he'll
> chime in here.
>
> The PythonCard webserver sample contains a fix for the run_cgi() method
of
> CGIHTTPRequestHandler; it may be different than what Steve was going to
> patch with but it seems to work fine. Here are the two code fragments,
one
> for the Unix section and the second one for the Windows section. The
basic
> idea is to just throw away bytes paste the content-length but not block
> while doing so.
>             if pid != 0:
>                 # Parent
>                 pid, sts = os.waitpid(pid, 0)
>                 # throw away additional data [see bug #427345]
>                 while select.select([self.rfile], [], [], 0)[0]:
>                     waste = self.rfile.read(1)
>                 if sts:
>                     self.log_error("CGI script exit status %#x", sts)
>                 return
>             # Child
>
>
>             if self.command.lower() == "post" and nbytes > 0:
>                 data = self.rfile.read(nbytes)
>                 fi.write(data)
>                 # KEA now throw away data past Content-length
>                 while select.select([self.rfile._sock], [], [], 0)[0] !=
[]:
>                     waste = self.rfile._sock.recv(1)
>
> The one problem area I remember is that apparently someone added support
for
> Keep-Alive in BaseHTTPRequestHandler which might cause problems with the
> code above. If you need a robust server, you probably shouldn't be using
the
> CGIHTTPServer module, but it is perfectly fine for light personal use and
> testing. Since the HTTP/1.1 support in the request handler code is
shallow
> at best, adding Keep-Alive support was probably not a good idea.
>
> It would probably be beneficial to look at these changes in context, in
> which case you can get the 0.6.9 source
>
> http://sourceforge.net/project/showfiles.php?group_id=19015
>
> or just check out the webserver.py file in cvs
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototy
p
> e/samples/webserver/
>
> ka
> ---
> Kevin Altis
> altis at semi-retired.com
> http://radio.weblogs.com/0102677/
>
> "Peter Hansen" <peter at engcorp.com> wrote in message
> news:3E1A4A4D.50C5DB52 at engcorp.com...
> > (This may be my first question in this newsgroup.  Please
> > be gentle! :-)
> >
> > We've encountered a little problem in a test program
> > involving the standard module CGIHTTPServer.py and a POST
> > operation from Internet Explorer.
> >
> > In summary, Netscape always works, but when using
> > Internet Explorer 6.0 (SP1, probably all versions fail)
> > a POST operation will result in a message (not a 404 or
> > any other recognizable HTTP error) that reads:
> >
> >    "The page cannot be displayed"
> >
> > along with a page full of friendly advice about what I
> > might have done wrong, and a title bar reading "Cannot
> > find server".
> >
> > After extensive investigation, we discovered that IE is
> > appending a CR LF pair to the request body, but is not
> > reporting it in the Content-length field.  (The actual
> > data is 23 bytes long, or 25 with these two.)  By
> > modifying the CGIHTTPServer.py code to read two extra
> > bytes, we "fix" the problem, but then of course the
> > server hangs when accessed from Netscape which doesn't
> > supply the extra two bytes.
> >
> > My questions:
> >
> > Is this a known problem for IE and maybe other browsers?
> >
> > Is it legal for a browser to do this, in which case is
> > it something CGIHTTPServer.py should be handling?
> >
> > Can anyone point me to other code (haven't been able to
> > find the relevant lines in Zope yet) in web servers which
> > might already handle this in a general and safe manner?
> >
> > Thanks for any pointers.  I've tried a few Google searches
> > so far without any bites, but it seems pretty obvious that
> > this is something that is known and solved, if I knew
> > where to look, and it seems likely the fix should be added
> > to CGIHTTPServer.py.
> >
> > -Peter
>
>