Is there any easy way to retrieve URI given TFPWebModule and TFPWebAction instances?

for instance:
...
RegisterHTTPModule('m',TAModule);
...
from inside an action's request handler:
procedure Tm.XXXRequest(Sender: TObject; ARequest: TRequest;
  AResponse: TResponse; var Handled: Boolean);
begin
  AResponse.Content := GetURI(Self,Actions.CurrentAction); // will be
'/m/xxx'
end;

ARequest.URI ?

There are other properties that can be useful:
ARequest.URL
ARequest.Location
ARequest.PathInfo
ARequest.PathTranslated
ARequest.ScriptName
ARequest.Query

Forgot to mention that there is a global Request property which is the same.
So Request.URI ...

AB

ARequest.URI ? Forgot to mention that there is a global Request property which is the same. So Request.URI ...

It's empty in CGI/FastCGI/Embedded Webserver. Did I just find another bug?

This is the result of dumping [A]Request properties:

[CGI, URL = http://localhost/test.fpw/m/helloget]
ScriptName /test.fpw
PathInfo /m/helloget
URI
ReturnedPathInfo m
LocalPathPrefix ../../
CommandLine
Command
QueryString
HeaderLine

[FastCGI, URL = http://fpfcgi.local/m/helloget]
ScriptName fpfcgi.local
PathInfo /m/helloget
URI
ReturnedPathInfo m
LocalPathPrefix ../../
CommandLine
Command
QueryString
HeaderLine

[Embedded Webserver, URL = http://localhost:2015/m/helloget]

PathInfo m/helloget
URI
ReturnedPathInfo m
LocalPathPrefix ../
CommandLine
Command
QueryString
HeaderLine HTTP/1.1

I am not sure about the Embedded Webserver as I have never used it, but I remember vaguely about some kind of problem we have fixed regarding pathinfo with Apache 2.4 and the mod_proxi_fcgi a few years ago.

There was a bug report, let me see if I can find it: ... http://bugs.freepascal.org/view.php?id=23387

In it you can see that with Apache 2.4 you have had to do some tricks in the conf file to even get the pathinfo passed from the web server (in the bug report "Steps To Reproduce" section):

#No PATH_INFO with mod_proxy_fcgi unless this is set SetEnvIf Request_URI . proxy-fcgi-pathinfo=1

See also the "Additional Information" section for detailed Apache doc on the issue.
So, it is possible, that for the URI we can have the same kind of issue. I am not using the URI parameter myself in my projects - might be because it was never set - it seems the others were sufficient or the URI can be rebuilt from the remaining ones.

Michael can probably shed some more light on this issue.

AB

There has been an extensive reworking of the HTTPDefs structures recently.

There are 2 properties URI and URL which were stored in different fields. I had not noticed this, since I do not use the URI field (the URL field showed up properly in my tests) I have corrected this, they share the same field now. Rev 30760.

Michael.

PS. You can use the dumprequest routine in webutils to create a relatively complete dump in HTML of the HTTP environment.

I have corrected this, they share the same field now. Rev 30760.

Thanks, Michael. It looks like you should start considering unit test for fcl-web.

PS. You can use the dumprequest routine in webutils to create a relatively complete dump in HTML of the HTTP environment.

Noted.

Btw, PathInfo and PathTranslated in embedded webserver contains no leading /, while the other app modes has. OTOH, HeaderLine is empty on other modes but embedded webserver.

leledumbo wrote

> I have corrected this, they share the same field now. Rev 30760. Thanks, Michael. It looks like you should start considering unit test for fcl-web.

It is on my todo list, yes.

I have recently created a TTestRequestApp custapp descendent which can be used to test requests based on some command-line options, and a testcase for testing web modules. I just need to commit them.

Headerline: That is normal, since headerline is not propagated from the webserver.

Pathinfo:

Strange. Probably a side effect of the fix for:

http://bugs.freepascal.org/view.php?id=26462

I will check this.

Michael.

It is on my todo list, yes.

I'll be waiting.

One more thing (which is actually why I ask my original question), how can I get registered module name given the module instance or module class? i.e. if I:

RegisterHTTPModule('m',TModule);

then

Something(TModule); or Something(Module);

shall return 'm'. ModuleFactory doesn't seem to provide such a functionality. I want to create a listing of what actions are available for the current module and I want to avoid repeating registered module name.

A good idea. I'll implement it.
But you'll have to be prepared that a module can be registered for different URLs, so the return is a TStringArray (or Strings).

Michael.

But you'll have to be prepared that a module can be registered for

different URLs,

so the return is a TStringArray (or Strings).

No problem, nested for is not that slow ;)