2009/1/26 gert <[email protected]>:
>
>
>
> On Jan 25, 1:30 pm, Graham Dumpleton <[email protected]>
> wrote:
>> 2009/1/25 gert <[email protected]>:
>> > On Jan 25, 2:59 am, Graham Dumpleton <[email protected]>
>> > wrote:
>> >> 2009/1/25 gert <[email protected]>:
>>
>> >> > What does this mean ?
>>
>> >> > [Sun Jan 25 01:10:02 2009] [error] [client 217.136.57.14] Traceback
>> >> > (most recent call last):
>> >> > [Sun Jan 25 01:10:02 2009] [error] [client 217.136.57.14]   File "/
>> >> > home/www/appwsgi/www/lib/upload.py", line 12, in application
>> >> > [Sun Jan 25 01:10:02 2009] [error] [client 217.136.57.14]     s =
>> >> > environ['wsgi.input'].read().decode('latin1')
>> >> > [Sun Jan 25 01:10:02 2009] [error] [client 217.136.57.14] SystemError:
>> >> > Objects/bytesobject.c:3171: bad argument to internal function
>>
>> >> It means something bad happened. What is the exact line and
>> >> surrounding lines of Python code in WSGI application doing?
>>
>> >> Include the existing contents of the email in the reply so context not
>> >> lost. Do not reply with only the new stuff you want to add as it makes
>> >> it very hard to track the conversation.
>>
>> > def application(environ, response):
>> >    db = Db()
>> >    cookie = "SID="+environ['QUERY_STRING']
>> >    session = Session(db,cookie,'guest')
>> >    response('200 OK', [('Content-type', 'text/xml'), ('Set-Cookie',
>> > session.COOKIE)])
>> >    if not session.GID : return []
>> >    s = environ['wsgi.input'].read().decode('latin1')
>> >    p = search(r'Content-Type: application/octet-stream\r\n\r\n(.*?)\r
>> > \n--',s,DOTALL).group(1)
>> >    db.execute('UPDATE users SET picture=? WHERE uid=?',(p.encode
>> > ('latin1'),session.UID))
>> >    xml = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
>> >    xml+= "<root>"+str(db.ERROR)+"</root>"
>> >    response('200 OK', [('Content-type', 'text/xml')])
>> >    return [xml]
>>
>> > i get this error on files with a size of 182 KB
>>
>> Does it only happen for this specific file upload and does it happen 
>> repeatably?
>>
>> Regarding the line:
>>
>>   s = environ['wsgi.input'].read().decode('latin1')
>>
>> First off, this is not WSGI compliant. To be compliant with WSGI
>> specification you must supply a length to read() when it is called on
>> wsgi.input.
>>
>> I want you to first off replace that line with:
>>
>>   length = int(environ.get("CONTENT_LENGTH", "0"))
>>   print("LENGTH=%d", length, file=environ["wsgi.errors"])
>>
>>   data = environ['wsgi.input'].read(length)
>>   print("TYPE=%s", type(data), file=environ["wsgi.errors"])
>>   print("DATA=%s", repr(data), file=environ["wsgi.errors"])
>>
>>   s = data.decode("latin1")
>>   print("STRING=%s", repr(s), file=environ["wsgi.errors"])
>>
>> Then instead of that replace it with:
>>
>>   data = environ['wsgi.input'].read()
>>   print("TYPE=%s", type(data), file=environ["wsgi.errors"])
>>   print("DATA=%s", repr(data), file=environ["wsgi.errors"])
>>
>>   s = data.decode("latin1")
>>   print("STRING=%s", repr(s), file=environ["wsgi.errors"])
>>
>> Post the output from Apache error logs for both.
>>
>> This will help narrow down whether problem is in Python with decoding
>> bytes to latin1 string, or whether there is an issue in mod_wsgi with
>> calling read() with no argument, which as I said before is outside of
>> what WSGI specification allows anyway.
>
> specifying the length works.
> WSGI say's you have to specify length, but it also does not state that
> it should crash if you don't :-)

You did not post the output from the Apache error logs for the
debugging I asked you to put in. If we are going to sort this out I
need you to provide the exact information I ask for. This is because I
am going to have to get you to add debugging into the C code itself. I
can't be guessing what the exact output was based on you just saying
something does or does not work. You may think parts of the debug
aren't relevant, but everything may be relevant.

Before I tell you what debugging to add to the C code, I want to know
what the WSGI environment received by the WSGI application is. This is
so I know whether you are trying to do something odd like chunked
transfer encoding, or client is expecting a 100-continue repose.

Thus, use the first logging middleware wrapper in:

  
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response

and send what is recorded in the Apache error log for the WSGI environment.

This will potentially help me to duplicate the problem. Right now the
few tests I have done have worked okay.

Thanks.

Graham

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"modwsgi" 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/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to