Hello,

I need to tailor the content based on the remote ip address. I use the property RemoteAddr of a TRequest, but sometimes it is empty. I see that it is a header, what I didn't see (yet, I'll trace through the code later) is if it is sent from the remote host or is it filled based on the ip address of the connection.
If the former, is there a more reliable way to obtain the connected ip address?
If the latter is it a bug?

Bye

El 7/1/21 a les 16:15, Luca Olivetti via fpc-pascal ha escrit:

I now see that it set in TFPHTTPConnection.ReadRequestHeaders:

    Result.RemoteAddress := SocketAddrToString(FSocket.RemoteAddress)

In turn SocketAddrToString returns an empty string if the address is ipv6, but in my case it shouldn't be (the clients, firefox under windows 10 uses the ipv4 address of the server and most of the time I get the correct remote address, even from the same client). Another option is that TSocketStream.GetRemoteAddress cannot get the address (if fpGetPeerName fails).

Bye

El 7/1/21 a les 16:59, Luca Olivetti via fpc-pascal ha escrit:

Besides, it seems that the server only listens on ipv4. I'm puzzled, I really can't see where this empty RemoteAddress could come from.

Bye

Are you using https ?

Michael.

El 8/1/21 a les 11:06, Michael Van Canneyt via fpc-pascal ha escrit:

Are you using https ?

No, plain text http.
An even weirder fact is that I seem to get the wrong ip address (i.e. the address of a different client).

Bye

El 8/1/21 a les 11:14, Luca Olivetti via fpc-pascal ha escrit:

I think I found the possible cause:

I have an own thread that spawns a TEmbeddedHttpServer (actually a derived class to manage server-sent-events,
https://lists.lazarus-ide.org/pipermail/lazarus/2020-June/238072.html) with threaded:=true.

My thread has a method to manage the requests and it does this

     FRequest:=ARequest;
     Synchronize(@SyncNewConnection);
     if FCommandQueuenil then .....

I think that, since the method is called from a different thread for each request, if two requests come at the same time, the FRequest and/or the FCommandQueue (which is set in the synchronized method) could get mixed up.

I now did 2 things:

1) protected that part of the code with a critical section
2) use TThread.Synchronize(nil,..) (since it's not my thread but another one

    FCrit.Acquire;
    FRequest:=ARequest;
    TThread.Synchronize(nil,@SyncNewConnection);
    LocCommandQueue:=FCommandQueue;
    FCrit.Release;
    if LocCommandQueuenil then...

WDYT?

Am I right thinking that, even if several copies of the above method are running, each will get it's own local variables, so the LocCommandQueue variable (as well as the other locals) won't be clobbered by another copy? Or should I declare them as threadvar?

Bye

In windows 10 when you connect to localhost, it may connect with IPV6 and route to ipv4 with weird results.
Try to connect using IP 127.0.0.1 http://127.0.0.1 You may also add in C:\Windows\System32\drivers\etc\hosts a line like localhost4 127.0.0.1
and then http://localhost4
You may also disable IPV6 service if you don't use it. I have, because it is seldom used, it looks like every device/system still works only with IPV4

If there is only 1 FRequest instance/location in your thread, then this is definitely so...

Care should be taken that the critical lock does not cause a deadlock, I don't know what happens in SyncNewConnection.

If FCommandQueue is the only thing that is set during SyncNewConnection based on TRequest, then yes. For safety, I would Nil the FCommandQueue after assigning it to locCommandQueue.

Michael.

El 12/1/21 a les 10:24, Michael Van Canneyt via fpc-pascal ha escrit:

yes to "each will get its [*] own local" or yes to "should I declare them as threadvar"?

For safety, I would Nil the FCommandQueue after assigning it to locCommandQueue.

No need, it's only used as a return value from the synchronized method.

[*] sorry for the "it's" in the original sentence

Bye

Yes to "each will get its own local copy".
I don't think threadvars are needed here.

Michael.