On Dec 29, 1:12 pm, "Anand Chitipothu" <[EMAIL PROTECTED]> wrote:
> On Dec 29, 2007 3:00 AM, Gary Bernhardt <[EMAIL PROTECTED]> wrote:
> > On Dec 26, 2007 6:08 AM, JLIST <[EMAIL PROTECTED]> wrote:
>
> > > Hello all,
>
> > > I've been trying a little AJAX with SACK:
> > >http://www.twilightuniverse.com/projects/sack/
>
> > > I'm getting a lot of 405 errors with CherryPy server.
> > > The requests fail most of the time, succeed occasionally.
>
> > > This shows on web.py 0.22 console on Windows:
> > > 127.0.0.1:1883 - - [26/Dec/2007 02:00:09] "HTTP/1.1 POST /req" - 200 OK
> > > 127.0.0.1:1883 - - [26/Dec/2007 02:00:11] "HTTP/1.1 
> > > rndval=1198663209684POST /req" - 405 Method Not Allowed
> > > 127.0.0.1:1883 - - [26/Dec/2007 02:00:11] "HTTP/1.1 
> > > rndval=1198663211026POST /req" - 405 Method Not Allowed
>
> > This log makes it look like the HTTP method being sent is
> > "rndval=<random integer>POST".  Obviously, that isn't a valid HTTP
> > method.  I can't imagine what kind of bug could result in this, but
> > maybe it's some kind of printed debug info that's making its way into
> > the HTTP request somehow?
>
> Aah, I know what is happening.
> When you send a POST request and not read the input, it gets available
> to the next request.
>
> For example consider the following 2 requests.
>
>     POST /path1 HTTP/1.1
>     k1: v1
>     k2: v2
>
>     rndval=1234
>
>     GET /path2 HTTP/1.1
>     k1: v1
>     k2:v2
>
> Since the data in POST request is not read, the second request's
> method becomes rndval=1234GET.
> Even I noticed this once. This happens only with cherrypy webserver
> and not with lighttpd or apache.
>
> If you make sure you read all the given input data, it will be OK. You
> may add the  following unloadhook.
>
>     web.unloadhooks['input'] = web.input

The CherryPy WSGI server also does not protect against a WSGI
application accidentally reading more request content than was
actually sent for the request. This can be a problem if keep alive is
enabled and the content length header was wrong, the WSGI application
tries to read more than what the content length specified or the WSGI
application calls read() on wsgi.input with no arguments. End result
is that the WSGI application will block indefinitely waiting for more
input.

Proper web servers like Apache protect against such things and will
never let you read more data than was actually sent, properly
signalling EOF if you do even when keep alive is enabled. Apache will
also ensure that any remaining content from a request is discarded
before trying to process a subsequent request when keep alive is on.

For a production grade system, always probably better to use something
like Apache.

Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web.py" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/webpy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to