I was playing today with fpweb a little, and found a simply reproducible minor problem.

When one creates a new CGI or FCGI application and creates a simple default action, but NOT setting the "handled := true;" within the event handler, then some kind of exception happens within fpweb when the action is called from the client browser, but it does not return a full response error message page.
All that comes back to the client is:

"<html><head><title>APPNAME: "

where the APPNAME is the title for the application. This happens at least for CGI and FCGI applications, not sure about Apache modules as I did not try that.
As soon, as we have "handled := true;" there, everything is OK. If we have "handled := false;" or simply not setting it, the above issue happens. It seems, that there is a problem with displaying error messages/exceptions from within fpweb internals.

/Latest FPC and Lazarus SVN, WinXP 32bit/

===============
Example:

procedure TFPWebModule1.DefActionRequest(Sender: TObject; ARequest:
TRequest; AResponse: TResponse; var Handled: Boolean);
begin
   Handled := true; //<-- if removed, the response is always the above
//and no matter what follows below
   AResponse.Content := '<html><body>Yo! (F)CGI works!</body></html>';
end;
===============

AB

I cannot reproduce this at least on Linux 64 bit and Windows 2000 32bit.

I am working with these things full-time at the moment, and I always get the full page.

Michael.

Yes, it works for me too in Linux 32bit.

But not in WinXP 32bit. In fact, it seems that no matter what, the response page is cut off at 30 characters. In custweb.pp of .../fcl-web/base/ ,

procedure ExceptionToHTML(S: TStrings; const E: Exception; const Title,
Email, Administrator: string);

assembles the response page, and for some reason S is only 30 characters maximum when it arrives to the client browser.
If I replace the inner part of this procedure with simply

   With S do
     begin
     Add('<html><head>longer than 30 characters here..........');
     end;

it is still cut at 30 characters. Odd :)

AB

OK, found the problem:

fpweb does not set the content length properly when there was an exception or error message, it uses the content length from the action event handler.
For example, if we have
===============
procedure TFPWebModule1.DefActionRequest(Sender: TObject; ARequest: TRequest; AResponse: TResponse; var Handled: Boolean); begin
// Handled := true; //commented out to trigger the exception error page

   AResponse.Content := '<html><body>Yo! (F)CGI works!</body></html>';

end;
===============
fpweb will send the content length in the response headers as the length of the string set in the event handler which is the length of '<html><body>Yo! (F)CGI works!</body></html>'#13#10 in this case, and not the length of the error response page it constructs and sends back.

Headers>
Status: 200 OK
Content-Length: 45
Content-Type: text/html

This is happening on Windows XP 32bit for me for both CGI and FCGI applications if the above example is used.
I would not be surprised if this problem would be there in Linux too, maybe it is just properly displayed in the browser there, no matter what the header says.

AB

Probably it more depends on the configuration of the Webserver. As far as I know, the 'content length' header is purely optional. In each case, I'll patch fpWeb so it sets the content length (if possible)

Michael.

On 4/13/2011 00:07, wrote:
<...snip...>

You might be right. After some more testing, the content length does not seem to be consistent for some reason.
So far, I was not able to figure out why the response is cut short in the client browser, and when. The received content-length header is definitely not the length for the response.content in most cases.

I will do some more testing as time permits, first maybe just remove all content-length headers from the responses or something similar.

I was also trying to see if deflate/gzip-ing the responses on the server side by Apache makes any difference, but so far no conclusive results found. The received result pages are just cut short.

AB

>>> On Mon, 11 Apr 2011, ABorka wrote:

<...snip...>

Michael, if I do an

   Application.ProtocolOptions := Application.ProtocolOptions +

[poStripContentLength];
before the

   Application.Run;

for the FCGI application, then it fixes the problem. Of course, this does not work for CGI apps.

AB

This option removes the Content-Length header.

It seems to me that if content-length is specified, it is used and therefor must be correct. I will check this.

Michael.