I have an application installed on a WebSphere 8.5 application server which respond to the url: host_or_ip:9081/Stuff.
The requirement is that when i call the url host_or_ip:9080/Stuff. the request goes to: host_or_ip:9081/Stuff without going back to the client in the process (no redirect)
The host and the context root are the same, the port changes from 9080 to 9081.
I've thinked about a web server like IHS, but i don't know how to configure it properly. Moreover i've searched for a similar issue online and i found many different ways to do similar things like url rewriting, virtual hosts and http servers.
Which one should i choose and how it works?
Thank you in advance
Related
I have one doubts, Please clarify this
We have currently host the one sub application to under main application. like below
URL like
www.Examples.com/internal
internal is a sub application hosted under Examples main application.
But, i want to host the sub application as main application like below
But, the URL should be same like
www.Examples.com/internal
Note: Internal application maintain in single server or different server but, the URL should be same.
Is there any posibilities to maintain website like this?
Thanks,
Mathan Kumar H J
A more common way is having your root zone, example.com, and making other projects DNS records on that zone, for example, if you host the internal app at Ipv4 1.2.3.4 then you would make the DNS record internal IN A 1.2.3.4 in your zone and then internal.example.com will resolve to your app
Edit: noticed you do not want to change the url - if the other site is running on its own server, then you would have to get the user to that server eventually, so if you did it the example.com/internal way you would have to 301 redirect to that ip which would end up changing the url anyway
I am using VS 2013. IIS 8.0 Express and Azure .NET SDK v2.2
With a simple WebAPI template project I am able to repro this. When I locally debug the project in the azure compute emulator, it starts up the web page in https://127.0.0.1. However, in the request, the URI comes up with port 444.
Is there any known fix / workaround for this bug?
I could find similar issues for others at following pages but their workarounds don't work for me. Nothing in Request object or Request.RequestContext.HttpContext.Request object has the right URL. For e.g. if I try to open https://127.0.0.1:444/, I get "page not found" error.
Wrong port number in mvc 4 windows Azure Request.Url
Request.Url has wrong port information
Thanks!
After reading through this, I think this might be by design. The request is associated with DIP rather than VIP since it is just been forwarded from the Load balancer.
However, this would still mean that I need to keep 443 unused for my service to function normally. My service redirect users to live login page and it has to provide the VIP domainname port as redirect url in order to get the request.
During local debugging, requests to url:port provided in Request.Url doesn't work. Overall this azure local debugging setup still looks like a mess.
Let me know if there is any other workaround/fix.
Hi I have a website that I will be developing in the future.
Upon looking at the current website I noticed something weird that I have never seen before and also Google'd and found nothing.
If you go to: http://www.smartrainer.com.au you get the normal site
But, if you go to: https://www.smartrainer.com.au you get redirected to another website and are also given an SSL warning beforehand (in Chrome)
The site is hosted on a UNIX / PHP server and the .htaccess file currently has nothing that would suggest that it's redirecting to this other website.
Any help or insight would be appreciated with this, because I've never heard of this or seen this before.. The client also has no idea why it would be directing to that company that we've never heard of
Thanks!
It sounds like you're using a shared hosting server.
In plain HTTP, the server can know which host the client is requesting using the Host header in the request (this is based on the URL). Apache Httpd supports this with what it calls Name-based virtual hosts.
The HTTPS configuration is separate from the HTTP configuration in Apache Httpd (and presumably a number of other servers). Having virtual hosts (typically on a shared host) for the HTTP configuration doesn't mean that the same configuration is replicated for HTTPS.
HTTPS presents another problem: choosing which certificate to send before being able to see the Host header. Indeed, the server needs to send the client a certificate with the correct name during the SSL/TLS handshake, which happens before any HTTP traffic is sent (so before the Host header can be read). To overcome this problem, some hosts will set up a certificate valid for multiple host names (typically multiple Subject Alternative Names, or sometimes wilcards), others will use Server Name Indication (which isn't supported by all clients).
To get your server to host your site for HTTPS, you'd need:
To make sure the certificate it serves is valid for your host name (otherwise, there will be a warning message).
That the virtual hosts (or equivalent) it serves are configured for your host too.
In your case it seems that (a) your server is serving a single certificate that is not valid for your host and (b) your host isn't configured for HTTPS anyway, since you're falling back to what's probably the default host.
You may solve this issue by redirecting HTTPS URL to HTTP URL from your .htaccess. This error might because of shared hosting. If you cannot solve this issue from your .htaccess than you may also contact your hosting provider on this issue.
I'm trying to work out a feature for a Web application, but I'm a bit confused at this point. I was wondering if anyone can shed some light on the following scenario.
Say, my Web app is located at domain1.com and a users website is located at domain2.com. What I would like to allow is for the user to be able to map their domain to one of the files/pages on my server. So if someone accesses domain2.com/files then it will internally and transparently route to domain1.com/files.aspx?domain=2 (notice the domain parameter).
I know this can be done with a simple file redirection (301 or 302) on the users server, but I would like to achieve this on the DNS level. How can I go about it?
Thanks in advance!
You can map domain2.com (or a subdomain) to the same IP domain1.com runs on using the A record. That's about everything you can achieve on DNS level, as it doesn't care about directory structures.
Simply put, you can't. If you wanted to point foo.domain1.com to the record for foo.domain2.com, then you can probably use a CNAME record but DNS has no clue about HTTP URLs.
The "HTTP Redirector" plug-in for Simple DNS Plus does just that if you configure it to redirect to "http://domain1.com/files.aspx?domain=#HOST#"
Technically it actually does a HTTP redirect (native DNS is not possible), but it is done at the DNS servers instead of the web-server.
See http://www.simpledns.com/kb.aspx?kbid=1258
One of my rails apps (using passenger and apache) is changing server hosts. I've got the app running on both servers (the new one in testing) and the DNS TTL to 5 minutes. I've been told (and experienced something like this myself) by a colleague that sometimes DNS resolvers slightly ignore the TTL and may have the old IP cached for some time after I update DNS to the new server.
So, after I've thrown the switch on DNS, what I'd like to do is hack the old server to issue a forced redirect to the IP address of the new server for all visitors. Obviously I can do a number of redirects (301, 302) in either Apache or the app itself. I'd like to avoid the app method since I don't want to do a checkin and deploy of code just for this one instance so I was thinking a basic http url redirect would work. Buuttt, there are SEO implications should google visit the old site etc. etc.
How best to achieve the re-direct whilst maintaining search engine niceness?
I guess the question is - where would you redirect to? If you are redirecting to the domain name, the browser (or bot) would just get the same old IP address and end up in a redirect loop.
If you redirect to an IP address.. well, that's not going to look very user friendly in someone's browser.
Personally, I wouldn't do anything. There may be some short period where bots get errors trying to access your site, but it should all work itself out in a couple days without any "SEO damage"
One solution might be to use Mod_Proxy instead of a rewrite to proxy traffic to the new host. This way you shouldn't see any "SEO damage".
I used rinetd to redirect the IP traffic from the old server to the new one on IP level. No web server or virtual hosts config needed. Runs very smoothly and absolutely transparent to any client.