I have Geoserver set up on a Windows 2008 server using Jetty as the web container on port 8080. If the browse to http://[servername]:8080/geoserver/www/test/test.html I get a html page returned as expected.
Then I have set up IIS 7.5 using ARR and URL rewrite at the application pool level, to set up a reserve proxy. So that http://[servername]/geoserver.. is rewritten to http://[servername]:8080/geoserver... I am using match '.*' for the url and 'geoserver/' for the condition.
This gives a error when browsed to of 'connection reset' IIS http error log (C:\Windows\System32\LogFiles\HTTPERR) shows 'Connection_Dropped DefaultAppPool'
If I change the url rewrite to an action of redirect, the html page is displayed as expect, but obviously the url shows as redirected to port 8080.
Solved this by changing the URL rewrite to use .* for the URL match condition.
Related
I have a website running at https://example.com:555
The 80 and 443 port for the same public ip have been forwarded to another server.
I only want to re-direct the url from http://example.com:555/1618/?id=877 to https://example.com:555/1618/?id=877
Right now I am getting the 400 error "Your browser sent a request that this server could not understand..."
I am using apache 2.4 on ubuntu 20.04
Any leads would be highly appreciated.
Thanks.
adding "ErrorDocument 400 https://example.com:555" in .htaccess
works but the id parameter is not passed
adding ErrorDocument in the localized-error-pages.conf in apache
works but the id parameter is not passed
configure Strict-Transport-Security
didnt work
trying different $1 , REQUEST_URI etc in .htaccess
did not work
I have a simple MVC web application where javascript code sends ajax requests to the controller and the controller sends back responses.
I built the app 2 years ago and everything used to work fine. Now I tried to run the app again locally and met with the following problem:
whenever an Ajax request is sent from the frontend to the controller (running on localhost), the localhost refuses to connect and I get an ERR_CONNECTION_REFUSED message in (chrome's) javascript-console. (In Safari's javascript-console I get the following error message: "Failed to load resource: Could not connect to the server.")
I'm running the app using NetBeans 11.2. My NetBeans IDE uses GlassFish as server:
I removed the Glassfish server from NetBeans IDE, deleted its folder in my home directory and then added the Glassfish server again in my NetBeans IDE (which also entailed downloading the the newest version of the Glassfish server).
Still, the server refuses to accept any requests from the frontend.
I also tried using Payara Server (version 5.193). That didn't make a difference either.
The frontend itself looks fine at first glance by the way. That is, going to http://localhost:8080/myapp loads the frontend of the app. However, any dynamic features of the app don't work because the server refuses to accept any Ajax requests coming from the frontend (and initiated through mouse clicks).
How can I fix this?
I think I found the reason for the problem:
In my javascript-file I have the following line of code:
var url = "http://localhost:8080/myapp/Controller";
The variable "url" is passed to all the AJAX requests sent to localhost.
But here is the crazy thing: the AJAX requests are not sent to "http://localhost:8080/myapp/Controller" but to "http://localhost:8081/myapp/Controller" !!!!!
What the hell is going on here?!
Did you use port 8081 before and then changed the variable "url" to the new port 8080? In this case, maybe the variable is still set to the old value in the cache. Restart your computer and see whether this fixes the problem.
If the value of the attribute http-listener is localhost, it will refuse the connection external connection.
You can verify using its value using the command
asadmin> get server-config.network-config.network-listeners.network-listener.http-listener-1.*
Information similar to the following should returned:
server.http-service.http-listener.http-listener-1.acceptor-threads = 1
server.http-service.http-listener.http-listener-1.address = 0.0.0.0
server.http-service.http-listener.http-listener-1.blocking-enabled = false
server.http-service.http-listener.http-listener-1.default-virtual-server = server
server.http-service.http-listener.http-listener-1.enabled = true
server.http-service.http-listener.http-listener-1.external-port =
server.http-service.http-listener.http-listener-1.family = inet
server.http-service.http-listener.http-listener-1.id = http-listener-1
server.http-service.http-listener.http-listener-1.port = 8080
server.http-service.http-listener.http-listener-1.redirect-port =
server.http-service.http-listener.http-listener-1.security-enabled = false
server.http-service.http-listener.http-listener-1.server-name =
server.http-service.http-listener.http-listener-1.xpowered-by = true
Modify an attribute by using the set subcommand.
This example sets the address attribute of http-listener-1 to 0.0.0.0:
asadmin> set server.http-service.http-listener.http-listener-1.address = 0.0.0.0
Reference:
https://docs.oracle.com/cd/E19798-01/821-1751/ablaq/index.html
I host my CodeIgniter website under IIS 7 with application name NewApp. So the URL can be reach on URL "my-domain.com/NewApp". The landing page can be access through "my-domain.com/newapp" link. But when I tried to access the other page like "my-domain.com/NewApp/Module" using "my-domain.com/newapp/Module" URL format, it gave me 404 error.
I have tried to un-tick the "ignore case" under "URL Rewrite" section but it makes "my-domain.com/newapp/Module" accessible and "my-domain.com/NewApp/Module" error 404.
Here is the setting that I applied on the IIS "URL Rewrite" section
Update Aug 12, 2015
The working application name is depend on what URL that we accessed after IIS Application Pool recycle period. So if I access "newapp" after the recycle period, we cannot access "NewApp". The same behaviour also applied when I access "NewApp" at the first time.
I found out that if I call codeigniter function $this->uri->uri_string() on "newapp" (assume I run "NewApp" after recycle period) the string that returned by the function is "NewApp/Controller/Function". And if I call the same function on "NewApp" it will returned "Controller/Function"
The temporary solution is to modify the router core class to make the function return the same output string.
Is there anyone know what to do in IIS so I don't use this temporary solution?
I have used ARR and URL rewrite to reverse proxy request from the internet to my local host MVC web app.
The weird thing is some parts of the web app works while others show 404 err:
1) When I type in : mywebsite/Nodewebsite/ - that works
2) When I type in : mywebsite/Nodewebsite/blog - that works
3) When I type in : mywebsite/Nodewebsite/admin - I get my admin page fine but when I try to log on I get a 404 err.
4) When I click on a link on lets say : mywebsite/Nodewebsite/blog that points to another page in my web app, I get a 404 err.
I checked the URL, the path is not right in the 404 err, it points to a location in my web root folder.
It seems whenever I try to access the web app from the internet by typing in a specific URL, it will work but if something redirect to a site it gives a 404 err.
I am attempting to configure an owncloud server that rewrites all incoming requests and ships them back out at the exact same domain and request uri but change the scheme from http to https.
This is failed miserably. I tried:
redirect 301 https://$hostname/$request_uri
and
rewrite ^ https://$hostname/$request_uri
Anyway, after removing that just to make sure the basic nginx configuration would work it as it had prior to adding the ssl redirects/rewrites it will NOT stop changing the scheme to https.
Is there a cached list somewhere in nginx's configuration that keeps hold of redirect/rewrite protocols? I cleared my browser cache completely and it will not stop.
AH HA!
in config/config.php there was a line
'forcessl' => true,
Stupid line got switched on when it received a request at the 443 port.
Turned off and standard http owncloud works and neither apache/nginx are redirecting to ssl.
Phew.