Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2022-09

TJSONRPCModule: access the request from an handler.

4 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Luca Olivetti

Hello,

I added a "Web JSON-RPC Module" to my project, I dropped on it a TJSONPCHandler.

I find no way to access the request (I want to check the RemoteAddress):

1) the module has a "Request" field but it is always nil (either in DataModuleCreate, which isn't called with every request so it's unusable anyway, in BeforeExecute and in Execute, I didn't check AfterExecute but it would be too late).

2) the JSONRPCHandler has no way to access the request (or I couldn't find it).

I guess that, instead of calling the RegisterHTTPModule of the module, I should register the route in my webserver class (with httprouter.RegisterRoute), but what should I do in the handler to delegate the handling to the JSONRPCModule?

Bye

Luca

Reply by email

Michael Van Canneyt
to Luca Olivetti
Luca Olivetti wrote 11 lines
Hello, I added a "Web JSON-RPC Module" to my project, I dropped on it a TJSONPCHandler. I find no way to access the request (I want to check the RemoteAddress): 1) the module has a "Request" field but it is always nil (either in DataModuleCreate, which isn't called with every request so it's unusable anyway, in BeforeExecute and in Execute, I didn't check AfterExecute but it would be too late).

This is fixed in trunk: Request is always available.

Show quoted text 8 lines
2) the JSONRPCHandler has no way to access the request (or I couldn't find it). I guess that, instead of calling the RegisterHTTPModule of the module, I should register the route in my webserver class (with httprouter.RegisterRoute), but what should I do in the handler to delegate the handling to the JSONRPCModule?

The solution is much more simple.

Override HandleRequest() in the module.
Save the request in a variable and call inherited.

I have code that needs to work with 3.2.2 and I do this:

---
procedure TUserRPCModule.HandleRequest(ARequest: TRequest; AResponse: TResponse);
Var
   C : String;
begin
   FRequest:=aRequest;
   FResponse:=aResponse;
   try
     C:=FRequest.Content;
     C:=C+C;
     inherited HandleRequest(ARequest, AResponse);
   finally
     FRequest:=Nil;
     FResponse:=Nil;
   end;
end;
---

Michael.

Reply by email

Luca Olivetti
to Michael Van Canneyt

El 9/9/22 a les 15:50, Michael Van Canneyt ha escrit:

The solution is much more simple. Override HandleRequest() in the module. Save the request in a variable and call inherited.

Much simpler indeed! Thank you.
In my case I just save the remote address, but in your example below I suppose you redefined FRequest (and FResponse) to hide the private one in the ancestor, but what I don't understand is the C:=C+C and the need to set FRequest and FResponse to nil.

Show quoted text 22 lines
I have code that needs to work with 3.2.2 and I do this: --- procedure TUserRPCModule.HandleRequest(ARequest: TRequest; AResponse: TResponse); Var   C : String; begin   FRequest:=aRequest;   FResponse:=aResponse;   try     C:=FRequest.Content;     C:=C+C;     inherited HandleRequest(ARequest, AResponse);   finally     FRequest:=Nil;     FResponse:=Nil;   end; end;

Bye

Luca

Reply by email

Michael Van Canneyt
to Luca Olivetti
Luca Olivetti wrote 12 lines
El 9/9/22 a les 15:50, Michael Van Canneyt ha escrit: > The solution is much more simple. > > Override HandleRequest() in the module. > Save the request in a variable and call inherited. Much simpler indeed! Thank you. In my case I just save the remote address, but in your example below I suppose you redefined FRequest (and FResponse) to hide the private one in the ancestor, but what I don't understand is the C:=C+C and the need to set FRequest and FResponse to nil.

You can remove the C variable stuff, it was for debugging purposes. I simply didn't remove it during the copy & paste.

I set the variables to Nil after calling inherited (where the request is actualluy handled) so they are not inadvertently used in the OnDestroy of the datamodule.

Michael.

Reply by email