On 09/17/2010 01:49 PM, Karel Klic wrote:
Dne 17.9.2010 12:19, Jan Kratochvil napsal(a):
> On Thu, 16 Sep 2010 20:08:42 +0200, Karel Klic wrote:
>> 1.1) It's a CGI script written in Python. Python is well suited
>> for the CGI scripting and HTTP protocol handling,
> Such script should be persistent accross requests. Most of the
> packages and backtrace info are repeating so a shared cache should
> be a major concern IMO. Such feature is generally provided AFAIK by
> FastCGI, mod_perl, there probably exists also some such interface
> for Python.
Python has WSGI and mod_python (never tried it).
WSGI looks fine for me. It's well suited for returning different HTTP
status codes and headers. We don't need to make the script absolutely
The uncompressed data size can be obtained by calling xz --list
file.xz. The --list option has been implemented only recently, so it
might be necessary to implement a method to get the uncompressed data
size by extracting the archive to the stdout, and counting the
extracted bytes, and call this method if --list doesn't work on the
If the files were compressed using tar.xz, we may ask tar about the
uncompressed size: tar tvfJ file.tar.xz.
1.5.3) The size limit for received compressed .xz files is
within the HTTP daemon which executes the abrt-retrace-server CGI
script, so the limit is not checked inside the script. This
assumption must be documented in the abrt-retrace-server manual page.
The recommended value for the maximum HTTP request size is 30 MB.
I'm actually not sure if HTTP daemon handles this, but it's quite simple
to handle it in application. In fact, I find this way better - HTTP
server doesn't have to be configured to handle only retrace server requests.
1.10) The maximum number of simultaneous connections is configured
within the HTTP daemon which executes the CGI script, so this limit
is not checked by the script. This must be documented in the server
manual page. The recommended value for the maximum number of
connections is 20 (to be tested). The archive extraction and chroot
preparation and gdb analysis is mostly limited by the hard drive
size and speed.
Same thing, I think we should limit this in the application.
Just to make sure, if any operation fails on the server side
(decompressing, creating direcories etc.), server returns "500 Internal
Server Error" code with/without? error information in response body.
We should add a condition, that the client has to identify itself within
the User-Agent header. This way, it will be possible to block some
unwanted requests (or maybe send some html data web browsers?) and have
some information about the reporter: name, version etc.
The rest looks fine for me.