Hello,

I've the same problem in Apache and nginx: TRequest.PathInfo always returns an empty string.

In Apache, I'm using the the mod_proxy_fcgi module already distributed in Apache 24. In nginx, I'm using this configuration:

location /dev/duallsms {
fastcgi_pass localhost:8080;
... other configurations ...
fastcgi_param PATH_INFO $fastcgi_path_info; # from nginx docs }

First I've tested it on Windows, but I've noticed that it fail in Linux too. So I ask: is PATH_INFO available in FastCGI (working as proxy)? If not, what I use instead it?!

Thank you!

Oops, and my test is:

program DuallSMSFastCGITest;
{$mode objfpc}{$H+}
uses
  HttpDefs, CustFCGI;
type
  { TMyFCGIHandler }
  TMyFCGIHandler = class(TFCGIHandler)
  public
    procedure HandleRequest(ARequest: TRequest; AResponse: TResponse);
override;
  end;
  { TMyFCGIHandler }
  procedure TMyFCGIHandler.HandleRequest(ARequest: TRequest; AResponse:
TResponse);
  begin
    AResponse.Contents.Text := 'PathInfo: ' + ARequest.PathInfo;
  end;
begin
  with TMyFCGIHandler.Create(nil) do
  try
    Port := 8080;
    Initialize;
    Run;
  finally
    Free;
  end;
end.

FPC 2.6.4 (and FPC from trunk too).

PATH_INFO is not always available, you need to configure that in apache and/or nginx.

See http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html

The FPC fcl-web components by themselves do not try to reconstruct PATH_INFO. You can try determining it from SCRIPT_URI or SCRIPT_NAME.

Michael.

On Thu, Jan 29, 2015 at 6:58 PM, Michael Van Canneyt <

Thanks for the information.

Hm... what do you think about to read it from the REQUEST_URI param? If it is good, you need to do a small change in FCL (if relevant hehe). The patch in attached allows to use the implementation below:

program project1;
{$mode objfpc}{$H+}
uses
  HttpDefs, custfcgi;
type
  { TMyFCGIRequest }
  TMyFCGIRequest = class(TFCGIRequest)
  public
    property CGIParams;
  end;
  { TMyFCGIHandler }
  TMyFCGIHandler = class(TFCGIHandler)
  public
    function CreateRequest: TFCGIRequest; override;
    procedure HandleRequest(ARequest: TRequest; AResponse: TResponse);
override;
  end;
  { TMyFCGIHandler }
  function TMyFCGIHandler.CreateRequest: TFCGIRequest;
  begin
    Result := TMyFCGIRequest.Create;
  end;
  procedure TMyFCGIHandler.HandleRequest(ARequest: TRequest; AResponse:
TResponse);
  begin
    // open "
http://localhost/dev/duallsms/pesquisa/contato?campo=nome&filtro=fulano"
and get
    // the "REQUEST_URI:
/dev/duallsms/pesquisa/contato?campo=nome&filtro=fulano" output
    AResponse.Contents.Text := 'REQUEST_URI: ' +
      TMyFCGIRequest(ARequest).CGIParams.Values['REQUEST_URI'];
  end;
begin
  with TMyFCGIHandler.Create(nil) do
  try
    Port := 8080;
    Run;
  finally
    Free;
  end;
end.

I'm resending this last question because I'm not sure if my email was delivered.

No, that will not happen. This is guesswork.
Whether this will work, will very much depend on the setup.

If you need this, then you should implement the logic for handling REQUEST_URI yourself.

But I am prepared to provide a hook that allows you to determine PATH_INFO yourself if the server did not pass it on, since PATH_INFO is needed to determine the module that must handle the request.

Michael.

On Fri, Jan 30, 2015 at 11:07 AM, Michael Van Canneyt <

Thanks for the info again.

But I am prepared to provide a hook that allows you to determine PATH_INFO yourself if the server did not pass it on, since PATH_INFO is needed to determine the module that must handle the request.

Awesome! =)