Re: worrying potential DoS issue

Hello Igor,

See below for comments. Russell and I are colleagues in case you are 
wondering.

RK> Content-Length: 2000000000
RK> I think this would soon lead to denial of service for legitimate users
RK> of the cgi script as memory would be exhausted (and swapping would 
RK> probably slow the system down). I'm not sure if I've thought this 
RK> through properly, so please correct me if I haven't.

Igor>    You're wrong, considering that cgicc is responsible for
Igor>     HTTP packets handling. Naturally it is the job of HTTP server. It
Igor>     is HTTP server that sets up content length variable and it won't
Igor>     be set unless HTTP server receives a valid packet. In other words if
Igor>    the packet has an incomplete header and there is no bug in the
Igor>     server itself, the packet will be rejected and your CGI application
Igor>    won't even know about the packet's existence.

In fact, the HTTP server cannot have any knowledge of the REAL content length for HTTP POST messages before 
setting the environment variables (which includes CONTENT_LENGTH) for CGI to parse because the message body
is not buffered by HTTP servers (well Apache anyway :)).
Therefore, the content length sent by the client has to be used as the environment variable
used by CGI, this has been verified experimentally with Apache 2. 
With a few requests, you can bog a system down very quickly.

Please correct me if I'm wrong because this issue is VERY important.

RK> I've also run into another problem with session validation using 
RK> cookies. Unfortunately, during a file upload, this session validation 
RK> cannot be performed as the CgiEnvironment object can't be instantiated 
RK> before the upload is complete. This is a problem because I'm wanting to 
RK> check the cookie before continuing to accept the file upload.

Igor>  I'm not sure about this behavior but cookies are the part of HTTP
Igor>    header. Therefore the header should be received first, processed
Igor>    by HTTP server, and only then cgicc can handle it. I
Igor>    doubt it is possible to avoid this pattern on cgicc level.

True, cookies are part of the headers and they are set as environment variables for the 
CGI program to use, see the specification - http://hoohoo.ncsa.uiuc.edu/cgi/
So you could get all of the environment variables before loading the message body for HTTP POST and 
parsing it for data. There are two sources of data for CGI to use, the environment variables and
standard input (std::cin) so we should be able to seperate these two sources.

We are still hoping to submit a patch.

I'm sory about the rant, but it could cause a lot of pain if we ignore this issue.

Regards,

Steve King