Hello fpc-devel list.

I need to implement some customizations to the request and response classes of the fastcgi implementation -- maybe others as well -- but afaics I cannot override such classes without copy/paste the whole FCGI.ProcessRecord method.

A draft of the implementation I'd like to see in the fcl-web is described below. Is it possible to implement? Perhaps 2.6 branch?

Joao Morais

1. New virtual methods used to create requests and responses:

--- src/base/custweb.pp (revision 20261)
+++ src/base/custweb.pp (workcopy)
@@ -108,6 +108,8 @@
     Procedure SetBaseURL(AModule : TCustomHTTPModule; Const
AModuleName : String; ARequest : TRequest); virtual;
     function GetApplicationURL(ARequest : TRequest): String; virtual;
     procedure ShowRequestException(R: TResponse; E: Exception); virtual;
+    function CreateRequest: TRequest; virtual; abstract;
+    function CreateResponse(ARequest: TRequest): TResponse; virtual; abstract;
     Procedure InitRequest(ARequest : TRequest); virtual;
     Procedure InitResponse(AResponse : TResponse); virtual;
     Function GetEmail : String; virtual;

2. Patch every fcl-web implementation in order to use the virtual method instead of a hardcoded class:

--- src/base/custfcgi.pp        (revision 20261)
+++ src/base/custfcgi.pp        (workcopy)
@@ -119,6 +119,8 @@
     function Read_FCGIRecord : PFCGI_Header;
     function DataAvailable : Boolean;
   protected
+    function CreateRequest: TRequest; override;
+    function CreateResponse(ARequest: TRequest): TResponse; override;
     Function DoFastCGIRead(AHandle : THandle; Var ABuf; ACount :
Integer) : Integer; virtual;
     Function DoFastCGIWrite(AHandle : THandle; Const ABuf; ACount :
Integer) : Integer; virtual;
     function  ProcessRecord(AFCGI_Record: PFCGI_Header; out ARequest:
TRequest;  out AResponse: TResponse): boolean; virtual;
@@ -793,6 +795,16 @@
 end;
 {$endif}
+function TFCgiHandler.CreateRequest: TRequest;
+begin
+  Result := TFCGIRequest.Create;
+end;
+
+function TFCgiHandler.CreateResponse(ARequest: TRequest): TResponse;
+begin
+  Result := TFCGIResponse.Create(ARequest);
+end;
+
 function TFCgiHandler.DoFastCGIRead(AHandle: THandle; var ABuf;
ACount: Integer): Integer;
 begin
 {$ifdef windowspipe}
@@ -831,7 +843,7 @@
       end;
     assert(not assigned(FRequestsArray[ARequestID].Request));
     assert(not assigned(FRequestsArray[ARequestID].Response));
-    ATempRequest:=TFCGIRequest.Create;
+    ATempRequest:=CreateRequest as TFCGIRequest;
     InitRequest(ATempRequest);
     ATempRequest.RequestID:=ARequestID;
     ATempRequest.Handle:=FHandle;
@@ -848,7 +860,7 @@
   else if FRequestsArray[ARequestID].Request.ProcessFCGIRecord(AFCGI_Record)
then
     begin
     ARequest:=FRequestsArray[ARequestID].Request;
-    FRequestsArray[ARequestID].Response := TFCGIResponse.Create(ARequest);
+    FRequestsArray[ARequestID].Response := CreateResponse(ARequest)
as TFCGIResponse;
     InitResponse(FRequestsArray[ARequestID].Response);
     FRequestsArray[ARequestID].Response.ProtocolOptions:=Self.ProtocolOptions;
     ;

It is possible to implement this, and I even have started the process.

However, I don't see the use of adding the abstract calls ? Implementing this in src/base/custweb.pp gives the impression that you can use any TRequest/TResponse descendent, which definitely is not the case.

Each descendent needs to be sure that it gets the correct TRequest descendent.

I think it is sufficient to make sure that every webhandler has 2 virtual calls that create the correct descendents. You can then override these 2 virtual calls.

for instance in src/base/custfcgi.pp I would add

     function CreateRequest: TFCGIRequest; virtual;
     function CreateResponse(ARequest: TFCGIRequest): TFCGIResponse; virtual;

And similar functions in the other webhandler components.

I started on this procedure already.

For instance in custcgi, it is already implemented like that:

    Function CreateResponse(AOutput : TStream) : TCGIResponse; virtual;
    Function CreateRequest : TCGIRequest; virtual;

I just need to complete the work.

If you want, you can of course provide a patch that completes the work.

Michael.

Perfect.

The idea behind my draft was just a guideline to use the same method name and params. It's not a good one since the entries in the base class won't be used.

Nice, attached for fcgi against rev 20265, 2.6 branch, packages/fcl-web/ dir.

Joao Morais

Hello Michael, plans to implement the patch? Perhaps you prefer against trunk, including all webhandlers, registering a mantis, ...

Btw we have another patches that make fcl-web easier to extend and we'd like to see them implemented (asap =) ), how would we send them to you?

Joao Morais

It's indeed always best to open a bug report, then the patch cannot be forgotten.

Jonas

My apologies, I totally forgot about it :/

Btw we have another patches that make fcl-web easier to extend and we'd like to see them implemented (asap =) ), how would we send them to you?

Please, register them in mantis, and try to make patches against trunk.

I'll try to apply them ASAP.

Michael.

Hello Michael, registered as mantis #21980 a while ago. Is this kind of patch a candidate to be merged to 2.6? Before 2.6.2?

Joao Morais

Done, thank you.

Is this kind of patch a candidate to be merged to 2.6? Before 2.6.2?

I should think so, yes. It does not introduce any incompatibilities. Marco usually handles this.

Michael.