DomainHostRedirect not working

firstfriday · 2020-01-31 04:15:04

Hi, I have a Mormot Server written with server.DomainHostRedirect(..) which works on one computer but not on another one.

Same programm on both computers and startet as Admin to register the server.
no error occurs.

Even THttpApiServer.Execute is not executed which leads me to the idea that the https server is not passing the request.
but why? Any ideas where to look?

ab · 2020-01-31 10:19:02

What are the OS versions on the computers?
What are the logs showing? (don't post the logs here - use an external site like PasteBin if needed)

I guess you should find some OS error at some point when debugging the application.

firstfriday · 2020-02-01 05:57:42

Thank you for your reply.

Both latest Windows 10.

Unfortunatly no errors and the logs of both computer are identical.

TSynLog 1.18.5499 2020-02-01T04:40:52
image.server.model.TSQLHttpServerroot(056a38f0) http.sys registration of http://+:8083/root
SetThreadName 1130=TSQLHttpServerroot 8083/root THttpApiServer
image.server.model.TSQLHttpServerroot(056a38f0) {"THttpApiServer(05d8d7f0)":{"RegisteredUrl":"http://+:8083/root/","MaxBandwidth":-1,"MaxConnections":-1,"APIVersion":"HTTP API 2.0","ServerName":"mORMot (Windows)","ProcessName":"root "}} initialized for root
image.server.model.TSQLHttpServerroot(056a38f0) Redirect http://localhost:8083 to http://localhost:8083/root
image.server.model.TSQLHttpServerroot(056a38f0) http.sys registration of http://+:8083//

DomainHostRedirect('images.localhost','root/images');

http://localhost:8083/root/images/test.jpg // works on both computers
http://images.localhost:8083/test.jpg // does not work on one computer, Page not found

I don't think it is related to mormot or my code more because if I set A1) breakpoint

unit SynCrtSock;
...
Err := Http.ReceiveHttpRequest(fReqQueue,ReqID,0,Req^,length(ReqBuf),bytesRead);
if Terminated then // A1) breakpoint here

and call http://images.localhost:8083/test.jpg
the breakpoint is not reached.
I checked also the windows eventlog but there is nothing interesting to find.
How exactly is the way from a browser-call images.localhost to this breakpoint?

BTW:
In Debug-Mode this has no effect:
TSynLog.Family.DestinationPath:='log\';
In Release-mode it does.

Last edited by firstfriday (2020-02-01 06:58:27)

ab · 2020-02-01 07:19:45

Perhaps a http.sys registration problem.
Some URIs may be overlapping on a computer.

Compare the ouput of

netsh http show urlacl

https://docs.microsoft.com/en-us/window … how-urlacl

Try to change the port, to see if it solves the problem.

macfly · 2020-02-01 13:42:14

See the "hosts" file in this computer.

It's in the folder

C:\Windows\System32\drivers\etc

Check if there is any entry that could be preventing the redirection

Also, try to add this line:

127.0.0.1      images.localhost

Last edited by macfly (2020-02-04 13:54:44)

firstfriday · 2020-02-02 05:34:41

These were interesting answers. I (believe) to be closer to the problem.

Very interesting is that
- Chrome Browser CAN access http://images.localhost:8083/test.jpg
- Fire Fox, Edge, ie CAN NOT and
- THTTPClient responds Error sending data: (12007) The server name or address could not be resolved

In my mind this must be a DNS problem while google chrome somehow resolved that on it's own.

With
- "logman.exe start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl –ets"
you can trace any http requests but no traffic.
- hosts file is empty
- I checked also TCPIP settings for alternative DNS->No

More ideas?

mpv · 2020-02-02 06:35:40

1) try to use curl in verbose mode, curl diagnostic is very human friendly
curl -v http://images.localhost:8083/test.jpg

2) try to use wireshark to see low lewel TCP traffic instead of logman
3) try plain socket server instead of http api based, this is the simplest point to start from

Last edited by mpv (2020-02-02 06:39:09)

ab · 2020-02-02 10:01:52

Yes images.localhost is not a real domain name.

Use the server host name instead of localhost.

firstfriday · 2020-02-03 06:24:30

1) curl -v http://images.localhost:8083/test.jpg
* Could not resolve host: images.localhost
* Closing connection 0
curl: (6) Could not resolve host: images.localhost
2) maybe thats an option but after 2h of reading the manual I gave up.
3) tried already.
4) http://images.hostname:8083/test.jpg does also not work on this computer other yes

I suppose some problems never get solved or are not worth finding :-(

ab · 2020-02-03 09:04:43

This is a problem when using 'localhost' as part of DNS resolution.
'localhost' is not a real DNS name, it is a simple way to access the loopback interface, as an alias to 127.0.0.1.

So 'localhost' couldn't be used as part of host resolution.
Chrome should be making some special guesses to let it work, trying alternate addresses, like plain localhost:8083 instead of images.localhost:8083 putting images.localhost in the HOST field. But it is a trick.

I have added an explicit warning when TSQLHttpServer.DomainHostRedirect('something.localhost') is defined, and a documentation note.
See https://synopse.info/fossil/info/b641f50aea

macfly · 2020-02-03 12:56:45

Tried to put images.localhost on hosts file, as I did in the previous post?

I remember that when using servers as Apache, the only way for the server respond to a subdomain on localhost was by placing this entry on the hosts.

Why does it work on one machine and another doesn't? Do not know...

Perhaps the question is: Why is it running on the other machine without this entry on the hosts.

=======

Edit: I did a test and on Chrome accesses without then entry in hosts file.

On Edge and Firefox only access with the entry.

NOTE: the door should not be added as I passed above.

Would be like this:

127.0.0.1       images.localhost

Last edited by macfly (2020-02-03 14:16:54)

ab · 2020-02-03 20:10:11

'localhost' is just another way of writing 127.0.0.1.
So there is no such thing as a subdomain on localhost, by definition.
Just like there is no such thing as a subdomain on a ip address - subdomain.1.2.3.4 doesn't mean anything in terms of DNS resolution: DNS is about resolving a name into an IP.

You can only fake it either by hacking the hosts list, or by browsing to plain localhost, but putting the subdomain.localhost in the HTTP Host: header (as Chrome seems to do).

firstfriday · 2020-02-03 23:51:02

1) HTTP Host: header is indeed modified by Chrome but also Firefox does modify it.

2) Editing the hosts file
127.0.0.1 images.localhost
does work.

3) Only one thing of understanding is bugging me:
I agree totally with the DNS resolution process. But this should work then:
http://images.<hostname>:8083/test.jpg
hostname=computername. But it also fails.

Last edited by firstfriday (2020-02-03 23:55:50)

mpv · 2020-02-04 05:54:05

http://images.<hostname>:8083/test.jpg should worrk if you have DNS service what resolve "images.nameofyourhost" into ip address of your host, or if you specify images.nameofyourhost in hosts ( then will work locally).
To check DNS works as you expect execute "ping images.<hostname>' or use nslookup utility. While ping not works, host name unreacable to ANY program. Does ping work in your case?

Also http://images.<hostname>:8083 should be registered in htts.sys routing tabke and no firewall rules deny access to 8083 port.

ab · 2020-02-04 09:09:16

You have some confused assumptions about name resolution on a network.
It won't work with images.hostname if the DNS server is not having any entry for it!
From the DNS point of view, images.hostname is just as unknown than imageshostname if it is not registered in the DNS entries. It doesn't "cut" images.hostname into images + hostname then resolve hostname.
So if you expect images.hostname to work on a local network, either add it to the local host files, or configure a local DNS server. Otherwise it should not work.

I guess you should rather use hostname/images if all information comes from the same server.
IMHO images.hostname is only useful if it points to another IP than plain hostname. For instance, in our DNS entries, we have www.synopse.info and synopse.info pointing on this server, but blob.synopse.info points to another third-party server, which hosts the blog, and mail.synopse.info for the POP3/SMTP server.
If you find it "cooler" to have images.hostname in the URI bar, it is your choice, but don't expect to make implement it easy on a local network!

Also consider CORS policy: images.hostname is not the same origin than hostname, so for proper Web page security, you should rather stick with hostname/images. For instance, you could not run a JavaScript HTTP Request on image.hostname sub-domain from a web page hosted in hostname domain.
For what I understand in how the www works, sub-domains are external/foreign/separated domains, even from HTML point of view.

macfly · 2020-02-04 13:53:25

For local testing, I don't see a problem modifying the hosts file to accept these requests.

Then on the real server, which will probably have a DNS server this will work accordingly.

But I agree with @ab about the usefulness of subdomains. I've used this just to make the address "cool" and I just had problems.

I have a service with great access to images, js, etc. (widgets that can be incorporated into websites). So all the static files are on a separate server, with a subdomain.

I imagine that is your case.

PS: Consider the option of not using mORMot to serve these files. You can resolve this with a reverse proxy.

mORMot Open Source

#1 2020-01-31 04:15:04

DomainHostRedirect not working

#2 2020-01-31 10:19:02

Re: DomainHostRedirect not working

#3 2020-02-01 05:57:42

Re: DomainHostRedirect not working

#4 2020-02-01 07:19:45

Re: DomainHostRedirect not working

#5 2020-02-01 13:42:14

Re: DomainHostRedirect not working

#6 2020-02-02 05:34:41

Re: DomainHostRedirect not working

#7 2020-02-02 06:35:40

Re: DomainHostRedirect not working

#8 2020-02-02 10:01:52

Re: DomainHostRedirect not working

#9 2020-02-03 06:24:30

Re: DomainHostRedirect not working

#10 2020-02-03 09:04:43

Re: DomainHostRedirect not working

#11 2020-02-03 12:56:45

Re: DomainHostRedirect not working

#12 2020-02-03 20:10:11

Re: DomainHostRedirect not working

#13 2020-02-03 23:51:02

Re: DomainHostRedirect not working

#14 2020-02-04 05:54:05

Re: DomainHostRedirect not working

#15 2020-02-04 09:09:16

Re: DomainHostRedirect not working

#16 2020-02-04 13:53:25

Re: DomainHostRedirect not working

Board footer