Eric S. Johansson | 2 May 2006 00:40

limits in uploading files

is there any limit in uploading files through CGI's?  For a project of 
mine where people upload CD and DVD length files (yes, it's legit, to be 
disclosed when we go live), I'm finding that I can only upload 126 MB 
worth of data before it fails.  I'm really confused if it's a problem of 
mine or something inherent within Cherokee.  Additionally, it looks like 
a CGI program is terminating (timeout??) because I'm not seeing my "I'm 
finished transferring" log message.  Come to think of it, someone 
uploading a 90 MB file over his cable modem failed before a complete as 
well which would give a small amount of credence to the timeout theory.

I'm running Cherokee 0.5.3 on ubuntu 5.10
Eric S. Johansson | 2 May 2006 04:46

Re: limits in uploading files

Eric S. Johansson wrote:
> is there any limit in uploading files through CGI's?  For a project of 
...

> well which would give a small amount of credence to the timeout theory.

I changed CGI_timeout from 65 to 6500 and the amount of data uploaded 
before a failure almost doubled (200 MB) and I think, if I am 
interpreting logs correctly, the CGI ran for about 10 minutes.

I'll check again in the morning when I'm more awake.
Diego Fabregat | 4 May 2006 01:10
Picon

BUG: bad parse of full URL in request?

Hi all,

This is my first mail to cherokee mailing lists, so I hope I send it to the correct one.

I've been browsing source code from svn repository and a I've seen something strange (at least strange for me). In file header.c, function parse_request_first_line (lines 443 - 458) it checks if the resource requested is a full URL, and if it is, it looks for a '/' for getting the path of the resource in the server. But what if we do:


$ telnet www.alobbs.com 80
...  
GET http://www.alobbs.com HTTP/1.1
Host: www.alobbs.com           

??

We get:

HTTP/1.1 400 Bad Request       
...


And what if we do:

$ telnet www.alobbs.com 80
...
GET http://www.alobbs.com/ HTTP/1.1
Host: www.alobbs.com

??

In this case, we get:

HTTP/1.1 200 OK
...


I think the response of the first example is not correct, because it should consider the situation where the request don't have that '/' the code is looking for because the main page is being requested. Shouldn't cherokee return a 3XX code?

Of course, I can be wrong, I'm only a student with few knowledge about web servers. If so, I'm sorry.
I'm sorry about my poor english too.


Ouch!! I almost forget that:
Cherokee version:  "Server: Cherokee/0.5.3 (UNIX)"
And I think the same problem appears in svn version.

Greetings,
Diego

-----------------------------------------------
[Spanish Version]

Por si no se me entiende y sabiendo que Álvaro (y algún otro desarrollador/colaborador/usuario de la lista) es español/latinoamericano, intentaré explicarme en castellano:

He estado ojeando el código del repositorio svn (cherokee/trunk/cherokee) y me ha parecido extraño que en la función parse_request_first_line del fichero header.c (lineas 443 - 458), al comprobar si se trata de una URL completa se busca una '/' sin más (aparte del http://). Es decir, sin considerar el caso de que se trate de una petición de la página principal, como pongo en el ejemplo primero:

$ telnet www.alobbs.com 80
...  
GET http://www.alobbs.com HTTP/1.1
Host: www.alobbs.com           


HTTP/1.1 400 Bad Request       
...


Al ver que si pongo la barra devuelve un código de éxito:

$ telnet www.alobbs.com 80
...
GET http://www.alobbs.com/ HTTP/1.1
Host: www.alobbs.com


HTTP/1.1 200 OK
...


me ha "confirmado" mis sospechas de que puede tratarse de un error.

Pero como también he dicho, no soy ningún gurú del tema, ni mucho menos, por ese motivo mis disculpas si estoy equivocado o estoy diciendo alguna tontería.

Supongo que será importante saber la versión del servidor en el que lo he probado, pero eso Álvaro lo sabrá bien. Lo he probado con www.alobbs.com porque no tengo ningún cherokee a mano y sabía que ahí habría uno ;-)

Sin más,

Saludos,
Diego

PS: cualquier cosa que haya hecho o dicho mal, agradecería corrección :-)
PS2: he estado mirando por el archivo de mensajes viejos de la lista y no  he encontrado nada sobre el tema, espero que no se trate de algo repetido. Lo que sí he encontrado es que se debe escribir en inglés, espero que esta versión en español no sea una molestia.

_______________________________________________
Cherokee mailing list
Cherokee <at> 0x50.org
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
Alvaro Lopez Ortega | 4 May 2006 11:57
Picon

Re: BUG: bad parse of full URL in request?

Hi,

> This is my first mail to cherokee mailing lists, so I hope I send it
> to the correct one.

  Welcome Diego ;)

> I've been browsing source code from svn repository and a I've seen
> something strange (at least strange for me). In file header.c,
> function parse_request_first_line (lines 443 - 458) it checks if the
> resource requested is a full URL, and if it is, it looks for a '/'
> for getting the path of the resource in the server. But what if we
> do:
>
> $ telnet www.alobbs.com 80
> GET http://www.alobbs.com HTTP/1.1
> Host: www.alobbs.com
>
> HTTP/1.1 400 Bad Request
> ...

  This is a known unsupported corner case. Let me explain the reasons:

   - In first place, almost all the request that a Web Server receives
     don't include the URI in the request, something like this:

   	   GET / HTTP/1.1
	   Host: www.alobbs.com

	so, there is no need of parsing the URL, simple because the
	request and the Host header entry let the server know everything
	it needs. I guess 99% of the request a common server receives are
	not using full URLs as request.

   - It only happen when the request doesn't request any object.

  I would be happy to improve the support of this corner case, but it
  would need some quite big changes in the header.c code, and probably
  it would slow down a little bit the current code, so I think it
  doesn't worth supporting the case.

  Anyway, it someone finds out a way in which we can support it with
  messing up the code or slowing down the header parsing I'll more
  than happy to apply the patch.

> Of course, I can be wrong, I'm only a student with few knowledge
> about web servers. If so, I'm sorry.  I'm sorry about my poor
> english too.

  You were right Diego. There is an explanation for the issue though.

> Ouch!! I almost forget that: Cherokee version: "Server:
> Cherokee/0.5.3 (UNIX)" And I think the same problem appears in svn
> version.

  The SVN trunk version is currently upside down. I have been working
  in some HUGE changes for Cherokee 0.6, so we will need to start
  working with pre-releases within a month or two in order to
  stabilize all the new code :-)

--

-- 
Greetings, alo.
Alvaro Lopez Ortega | 6 May 2006 09:58
Picon
Gravatar

Uploading issues

Hi guys,

  I just wanted to comment a problem that seems to be affecting a few
  people running Cherokee with PHP-fastcgi. During the last weeks, I
  have received a few reports about Cherokee failing to manage uploads
  to CMS like Drupal or Jaws.

  At first moment it looked like a fcgi handler bug, but after some
  investigation, I have realized that there was nothing wrong in the
  server, the problem is in the PHP configuration actually.

  If you are suffering of this problem, the only thing you have to do
  is to increase the amount of memory that you allow the PHP server to
  use per request.

  In /etc/php/cgi/php.ini (this path depends on your set up, but
  should be similar), look for the "memory_limit" entry (by default is
  set to 8M), and increase it to, for example 16 or 32M.

  Finally, kill all the PHP daemons running in the machine and try to
  upload the file again.  It works now.. isn't it? :-)

--

-- 
Greetings, alo.
http://www.alobbs.com
Ogoshi | 6 May 2006 23:39
Picon

Cherokee with gallery2

Hi

I think to install the program gallery2 or gallery
(http://gallery.menalto.com/wiki/Help) in my web site that use Cherokee
0.4.30.

Any person install and use this program with cherokee and runs
ok?

Thanks a lot
--

-- 
http://vctrsnts.dyndns.org
"Hay 10 tipos de personas en este mundo."
"Las que saben binario y las que no."
Diego Fabregat | 9 May 2006 00:43
Picon

Re: BUG: bad parse of full URL in request?



2006/5/4, Alvaro Lopez Ortega <alvaro <at> sun.com>:

  This is a known unsupported corner case. Let me explain the reasons:

   - In first place, almost all the request that a Web Server receives
     don't include the URI in the request, something like this:

           GET / HTTP/1.1
           Host: www.alobbs.com

        so, there is no need of parsing the URL, simple because the
        request and the Host header entry let the server know everything
        it needs. I guess 99% of the request a common server receives are
        not using full URLs as request.

   - It only happen when the request doesn't request any object.


Of course, I know it is not frequent ( I guess it is less than 1%, 0.001% ? ).  The reason of my first mail is that I prefer things working well in 100% of cases :-P

  I would be happy to improve the support of this corner case, but it
  would need some quite big changes in the header.c code, and probably
  it would slow down a little bit the current code, so I think it
  doesn't worth supporting the case.

  Anyway, it someone finds out a way in which we can support it with
  messing up the code or slowing down the header parsing I'll more
  than happy to apply the patch.

I have no time for thinking about it (exams ;-) but I'll do it. In a quick look at the code I only guess two ways for doing it, and I don't like any of them.

  The SVN trunk version is currently upside down. I have been working
  in some HUGE changes for Cherokee 0.6, so we will need to start
  working with pre-releases within a month or two in order to
  stabilize all the new code :-)

Ok


Greetings,
Diego


_______________________________________________
Cherokee mailing list
Cherokee <at> 0x50.org
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
Paul Wellner Bou | 9 May 2006 09:07

Handler redir

Buenos dias,

Trying to port my apache rewrite configuration to cherokee I got 
confused with the handler directives, specially with the redir handler.
And I am not able to debug my tries as the logfiles do not contain 
anything about the internal server errors I get.
I think I did not get the concept of the cherokee handlers yet.

The handler directive can be everywhere, in Directory directives, 
Request, etc. Is it possible to use it just within a Server directive?

The examples in the documentation just show the use of the redir handler 
in a specific directory (Directory /photos). Is it possible to use it in 
the root directory? Do I have to use the Request directive then or is it 
possible to do it without?

I want to redirect, for example, myserver/action1 to 
myserver/index.php?do=action1 and the same with action2, action3, etc. 
Is it necessary to create a Request directive for each of them? Or is 
there a way to make it more generally?

Do I have to use "URL ..."? Why that? I want the server to fallback to 
the common handler if he does not find any suitable redirection patterns.

Thanks very much.
Regards
Paul.
Alvaro Lopez Ortega | 9 May 2006 13:31
Picon
Gravatar

Re: Cherokee with gallery2

Ogoshi wrote:

> I think to install the program gallery2 or gallery
> (http://gallery.menalto.com/wiki/Help) in my web site that use
> Cherokee 0.4.30.
>
> Any person install and use this program with cherokee and runs ok?

  Sure, many people do. Why wouldn't it work perfectly? :-)

    http://alobbs.com/modules.php?op=modload&file=index&name=gallery&include=albums.php

--

-- 
Greetings, alo.
http://www.alobbs.com
David Röhr | 9 May 2006 16:17

SSL issues.

Testing out Cherokee and is having some issues with SSL. Sometimes  
the content from the server doesn't load the entire page. The server  
seems to give this output.

socket.c:413: ERROR: Init OpenSSL: [Ã}
socket.c:413: ERROR: Init OpenSSL: error:1408F455:SSL  
routines:SSL3_GET_RECORD:decryption failed or bad record mac
socket.c:413: ERROR: Init OpenSSL: error:1408F455:SSL  
routines:SSL3_GET_RECORD:decryption failed or bad record mac
socket.c:413: ERROR: Init OpenSSL: error:1408F455:SSL  
routines:SSL3_GET_RECORD:decryption failed or bad record mac
socket.c:688: ERROR: SSL_write (8, ..) -> err=-1 'error:00000005:lib 
(0):func(0):DH lib'

Anyone who is having the same issues? Using OpenSSL (as the output  
might already give).

     /D.
--
A: It is confusing, since people don't read that way
Q: Why is top-posting bad?
A: It is adding comments to the top of a message
Q: What is top-posting?

Gmane