On Sep 29, 3:24 pm, Brian Smith [EMAIL PROTECTED] wrote:
Toshio Kuratomi wrote:
Graham Dumpleton wrote:
As to the HTTP request headers, the RFCs say they are effectively
latin-1. Thus, all HTTP_? variables in WSGI environ can only be
processed as latin-1 when converting toUnicode.
On Sep 29, 4:33 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
2008/9/30 Toshio Kuratomi [EMAIL PROTECTED]:
For response headers and content, the application can either generate
bytes and thus control the encoding, or it will fallback to trying to
convert it as latin-1
On Sep 29, 4:38 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
As to this whole discussion, as much as it is interesting there is
nothing I can do about it. It really needs to be brought up on the
Python WEB-SIG where I originally raised the issue of Python 3.0
support for WSGI. I can only
Graham Dumpleton wrote:
Just make sure mod_wsgi is working first by following instructions in:
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
The just substitute out hello world script with that snippet.
Yeah, I'm already running about a dozen vhosts under apache,
2008/9/30 Toshio Kuratomi [EMAIL PROTECTED]:
On Sep 29, 4:33 pm, Graham Dumpleton [EMAIL PROTECTED]
wrote:
2008/9/30 Toshio Kuratomi [EMAIL PROTECTED]:
For response headers and content, the application can either generate
bytes and thus control the encoding, or it will fallback to
Can we stop with the mod_wsgi should do this or mod_wsgi should do
that. The Apache/mod_wsgi module is just one implementation of the
WSGI specification. You need when talking about this to look at the
bigger picture and what other implementations exist, plus how they all
work and interact with
Today I was not able to start my application as I got segmentation
faults constantly.
I've attached gdb and that is the result:
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212216416 (LWP 29850)]
PyErr_Occurred () at Python/errors.c:80
80
Not particularly useful unfortunately.
Next thing would be to determine if crash happens as a result of
import WSGI script file itself, or due to call of WSGI application.
Thus at head of WSGI script file add:
import sys
print sys.stderr, START OF WSGI SCRIPT FILE
and at end of WSGI
2008/9/30 Pigletto [EMAIL PROTECTED]:
After switching to WSGIApplicationGroup %{GLOBAL} my application
started, but I have few more applications on this apache instance so I
can't use this kind of setup.
Can you explain to me how WebFaction process/memory limits work?
If you don't have
The BaseHTTPRequestHandler in http.server of Python 3.0 also only
makes headers available as Unicode (latin-1).
headers = []
while True:
line = self.rfile.readline()
headers.append(line)
if line in (b'\r\n', b'\n', b''):
break
2008/9/30 Toshio Kuratomi [EMAIL PROTECTED]:
On Sep 29, 3:24 pm, Brian Smith [EMAIL PROTECTED] wrote:
Toshio Kuratomi wrote:
Graham Dumpleton wrote:
As to the HTTP request headers, the RFCs say they are effectively
latin-1. Thus, all HTTP_? variables in WSGI environ can only be
Now, again, my application is working with the same setup as before
(without GLOBAL). I don't know why this started without segfault now.
Nothing has changed.
I have to mention that the issue that caused I was not able to start
my application today morning was
because my memory was over the limit
What do you get if you run:
ulimit -a
Maybe they have some sort of hard memory limits in place and you are
hitting that.
Graham
2008/9/30 Pigletto [EMAIL PROTECTED]:
Now, again, my application is working with the same setup as before
(without GLOBAL). I don't know why this started
Toshio Kuratomi wrote:
On Sep 29, 3:24 pm, Brian Smith [EMAIL PROTECTED] wrote:
Toshio Kuratomi wrote:
If mod_wsgi assumes latin-1 and converts that intounicode
before it hits the app, the app will see this::
Refererhttp://localhost/â%82¬.html
No, it will leave it as
2008/9/30 Brian Smith [EMAIL PROTECTED]:
mod_wsgi receives a sequence of bytes from apache.
It transforms those into unicode by pretending that those bytes are
latin-1 and sticks them into SCRIPT_NAME.
IMO, mod_wsgi should just drop SCRIPT_NAME and all other non-WSGI environ
keys except
On 30 Wrz, 14:41, Graham Dumpleton [EMAIL PROTECTED]
wrote:
What do you get if you run:
ulimit -a
Maybe they have some sort of hard memory limits in place and you are
hitting that.
Output of ulimit -a is:
---
core file size
Hi All,
I am trying to install modwsgi over my mac. It gave me some error so I
updated my Xcode to the latest version however it still doesn't
compile. It seems it has a problem with 64-bit:
here is the result of ./configure :
checking for apxs2... no
checking for apxs... /usr/sbin/apxs
I've managed to get segmentation fault (I was just clicking around my
application, I forced few reloads of mod_wsgi by changing wsgi script,
etc.), and I was able to reproduce this few times.
Again, I've connected to it with gdb but this time I've issued command
'share' before 'bt'. Thanks to
Currently I use psycopg2 from the svn - version dated at January 2008.
I've just looked at initd.org's svn and I see there is psycopg2-2.0.8
and in change log from march I found:
2008-03-07 James Henstridge [EMAIL PROTECTED]
* psycopg/pqpath.c (_pq_fetch_tuples): Don't call Python
On Tue, Sep 30, 2008 at 4:22 PM, Pigletto [EMAIL PROTECTED] wrote:
Maybe that is the problem? I'll give a try to newest psycopg2
2.0.8 definitely fixed some segfaults on my end.
Brett
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
2008/10/1 Brian Smith [EMAIL PROTECTED]:
mod_wsgi already mangles the URI components too much in SCRIPT_NAME and
PATH_INFO (in its defense, it does so because CGI/WSGI require it to for the
most part, except for // munging). That is why I fall back to parsing
REQUEST_URI myself.
In my
2008/10/1 Arash Arfaee [EMAIL PROTECTED]:
Hi All,
I am trying to install modwsgi over my mac. It gave me some error so I
updated my Xcode to the latest version however it still doesn't
compile. It seems it has a problem with 64-bit:
here is the result of ./configure :
checking for
22 matches
Mail list logo
