I have check “host header to target” and it same problem. I can’t change the target address to https because server does not like it. Not even if I trying in my local network with IP address.
I have look in the debug log (F12 in firefox) with IP address in the local network and it looks fine. No error and it show the camera. I then trying same with the subdomain and proxy then I get some error.
Server prepared video ID be3f3b0b-5888-40bf-a99b-a3a0edbc0785 for camera 009bab80-d4fb-4892-b168-1a163687660c
Firefox can not establish a connection to the server on wss://vakt.xxxxx.nu/XProtectMobile/Video/be3f3b0b-5888-40bf-a99b-a3a0edbc0785
This is more then one error but I guess I when I have 4 camera it show 4 error, it only change the last id code in the error in the log.
Your destination 192.168.1.4 work only with http not with https, right? Then you have to use http.
What happens, if you look in the Firefox console (F12) when loading the page. Are there any errors?
You could also try fiddler as a man in the middle to check for errors.
Old topic but I think I have found why my is not working.
I have help a friend with his new server and he also running same system that I do (nethserver reverse proxy and Milestone)
But he working because I have not activate right now HTTPS with letencrypt
So if I run HTTP it works with winsock but when I run HTTPS it does not work??
In your case, https probably doesn’t work because you have a self-created (untrusted CA !) cert.
A lot of “apps”, especially python & java are VERY fussy about ssl certs. Lets Encrypt works without ANY issues, so why not use them?
LetsEncrypt is very easy to use, and you only need a domain (kinda obvious, LE doesn’t work on IPs) and http access to your NethServer…
Thanks for replay
I have try both http and https internal to milestone but does not work.
But right now is that ok as long he and I can access from web client even if it not secure it is ok.
With the value NoDecode , such URLs are accepted, but encoded slashes are not decoded but left in their encoded state
If the receiving program is expecting a certain URL suffix from the client, then this parameter will make sure that the complete received URL suffix will be passed by the proxy as it is sent by the client.
WebSphere Application Server for IBM i.
Client unable to access WebSphere through HTTP Server/plugin when there is encoded charcters (%2f etc) in URI.
This symptom occurs when client access WebSphere through HTTP Server/plugin.
This symptom does not occur when client access WebSphere directly (not through HTTP Server/plugin).
The current default Apache value for AllowEncodedSlashes is Off. IIUC if a %3F sequence is sent by the client a 404 response is returned unconditionally.
The NoDecode value is a “relaxed” behavior. I guess Apache at least make an attempt: if the requested file name matches literally, it is returned (e.g. this%3Ffile.gif - but ok, that’s a bit weird case).
Changing the parameter value everywhere on the fly should be safe, but as usual the safest path is defining a prop and change its default value for the next NS release: 7.10. I’d avoid a new UI checkbox because the new default behavior shouldn’t harm in 98% of cases
That would be the same strategy to be applied here:
Current value of AllowEncodedSlashes is good for 99% of configurations.
I’m against on changing the current default, even with a prop.
This seems to me the perfect candidate for a template-custom.
I agree with Davide that a UI option doesn’t make sense for this corner case.