[fpc-devel] fpweb is not showing the exception message

Wed Apr 13 09:34:11 CEST 2011

On 4/13/2011 00:07, michael.vancanneyt at wisa.be wrote:
<...snip...>
>>>> On Mon, 11 Apr 2011, ABorka wrote:
>> 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.
>
> 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.

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