I am using Apache httpd and proxying requests to my Tomcat server where my application WARs are deployed.
Let's say I have application App and servlet URL pattern /servlet1 and domain name abc.com. So, when I forward request from my ROOT.war servlet to /App/servlet1, my URL changes to abc.com/App/servlet1, but I would prefer abc.com for a better user experience.
I know I could do this by re-nameing App to ROOT.war but that is not an option for me, as we already have a ROOT.war for another application.
Is it possible to rewrite abc.com/App/servlet1 to abc.com other then ROOT.war? If so, how do I do it?
The way to do this is to merge your ROOT and App applications together into a single application.
No servlet contains is going to be able to detect when some URLs should go to one application and others should go to another without some obvious mapping strategy. The servlet specification uses mandates the use of URL prefixes (context paths) to differentiate between deployed web applications: you cannot mix them together unless they are in fact the same application.
There are very very ugly ways to do this, but those techniques end up opening up a whole lot of headaches and continued hacks just to get around what sounds like a senseless requirement: making URLs pretty. Nobody cares how pretty a URL is. Make sure that example.com takes the user to the right place and don't worry about any of the rest of it.
Related
I'm developing a database backed web-app. I will be providing the same basic services to several branches of the same company.
Right now I have an Apache server with virtual servers and a resource server for reporting.
branch1.mycompany.com
branch2.mycompany.com
resources.mycompany.com
So basically when I call resources from the site I pass the site as a parameter.
branch1.mycompany.com -> resources.mycompany.com?branch=1¶meter=1
branch2.mycompany.com -> resources.mycompany.com?branch=2¶meter=1
Even with two branches there is a problem trying to keep up with updating both sites and now, I'm going to be implementing this scheme for seven sites.
So my question is this: Is there a way I can make a IIS or TomEE web-app with the following features?
I want to still allow each branch to access trough its URL
Even when there are 7 URLs; all of them will be pointing to the same web-app
Depending on the URL, is there a way the site parameter can be inferred or calculated so I can call the right resource or web service?
The user should never realize they are accessing a common web-app. (i.e. should not be redirected to web-app.mycompany.com?site=1.)
Tomcat (so tomee) has now a rewrite valve which is close to httpd mod_rewrite, this can surely solve that smoothly. I assume IIS has it as well but don't know it that much. Trick is to reverse proxy the requests.
I have a setup in Laravel whereby I have different sections of the site powered by one codebase. A section is defined by the first slug of the uri:
localhost.dev/section1/feature
localhost.dev/section2/another/feature
However, I also have a domain alias/proxy for these so that each section can have its own independent branding and SEO without splitting up the codebase.
section1.dev/feature (alias of localhost.dev/section1/feature)
section2.dev/another/feature (alias of localhost.dev/section2/another/feature)
However, Symfony's HTTPFoundation appears to be too smart to be fooled by this proxy, and whenever you use URL::full() or URL::current(), the domain remains localhost.dev despite your browser telling you that you're on section1.dev or section2.dev
Is there a way to configure .htaccess differently, or is there a way to make Laravel's URL::full() or URL::current() mirror what's in your address bar?
First: a domain alias is not a proxy.
Second: the app.url config option gets used by the application to generate URLs. Try making it an empty string.
We are building a fully RESTful back-end with the Play Framework. We are also building a separate web front-end with a different technology stack that will call the RESTful API.
How do we deploy both apps so they have the same domain name, with some URLs used for the backend API and some for the front-end views?
For example, visiting MyDomain.example means the front-end displays the home page, but sending a GET to MyDomain.example/product/24 means the back-end returns a JSON object with the product information. A further possibility is if a web browser views MyDomain.example/product/24, then the front-end displays an HTML page, and that webpage was built from a back-end call to the same URL.
Finally, do we need two dedicated servers for this? Or can the front-end and back-end be deployed on the same server (e.g. OpenShift, Heroku)
You are gonna to dig yourself... deep :)
Simplest and most clean approach with no any doubt is creating a single application serving data for both, BE and FE, where you differ response (JSON vs HTML) by the URL, pseudo routes:
GET /products/:id controllers.Frontend.productHtml(id)
GET /backend/products/:id controllers.Backend.productJson(id)
Benefits:
single deployment (let's say to Heroku)
name space managed from one app
No need to modify the models in many apps after change in one of them
else if
If you're really determined to create a two separate apps, use some HTTP server as a proxy - for an example nginx - so it will send all requests to domain.tld/* to application working at port 9000 (which will answer with HTML) but requests to domain.tld/backend/* redirect to application working at port 9001 responding with JSON.
else
If you are really gonna to response with JSON or HTML depending on the caller you can try to compare headers to check if request was sent from browser or from AJAX call in each controller , but believe me that will become a nightmare faster than you thing... insert the coin, choose the flavor
I thought of a different solution. I'm going to deploy back-end to a subdomain like
http://api.myapp.example/
and deploy front-end to the main domain:
http://myapp.example/
but I think you'd better use 2 different hosts, one for front-end and one for back-end (I searched the Google and this was the result of my investigations
Other possibility (therefore as separate answer) is using a possibility added in Play 2.1.x a Content negotiation I think it's closest for that what you wanted to get initially :)
Indeed its much easier to create a MEAN STACK APP and use one hosting like Heroku for instance.
Your frontend is what it is, front end for your backend. It will be easy to access backend / restfulAPI's and frontend like this:
http://localhost:3000/api/contacts (to access and consume your API endpoint)
http://localhost:3000/contacts (frontend)
NB: localhost:3000 or http://yourapp.example/api/contacts (api)
http://yourapp.example/contacts (frontend)
It's in the URL
The webapp I'm making is medium-sized, and it's going to be a single-page static JS+HTML app (made with Backbone, and served by nginx) which accesses an API, hosted on a proper webserver.
Should the API be under a different hostname, or same hostname but different path? What could be possible pros & cons of these options? Both options are feasible, thanks to nginx.
I would suggest using an intuitive separated environment. Splitting the access location like example.com and api.example.com allow the hostnames to describe the purpose of each environment. Separating these keeps things organised and clear while using the same hostname for each could cause confusion as to what kind of request is being done.
Using example.com/api is possible as well, but could lead to future issues where directories are used for other things as well. E.g., would example.com/newfeature have a directory like example.com/newfeature/api as well?
In the end, it's all a matter of personal preference though. Pick something that works in a clear way for your environment.
I think your question is somewhat irrelevant, as long as your code is flexible about the base url of the api. Make sure you can configure your code (both javascript and back-end) so that all api URLs are relative to some single configuration parameter and you will have flexibility to put your api service anywhere you want or need to put it.
I tend to think it might be a good idea to have everything on the same hostname, because the user might have disabled 3rd party cookies, and so the API server won't be able to recognize you after you close your browser. Before anyone tells me I should have the main website serve the cookies instead, let me tell you that I'd like the main website to be completely static HTML/JS files, and so they have no ability to serve httpOnly cookies, which is the kind of cookies I like.
We have Apache on top of JBoss serving either web or mobile app.
We are currently using Apache mod-rewrite to decide where to forward the user to web or mobile (and mod-jk to mount to JBoss), based on regular expressions matching of user-agent, but that is imprecise and error prone.
We want to use a servlet or jsp on JBoss as part of deciding whether to serve the web or mobile app (the servlet checks the user-agent in WURFL to see if this is a mobile device or a web browser).
How can I make a rewrite-condition dependent on the result of a servlet/jsp ?
(I already thought about redirecting the jsp back to two possible URLs and continue the rewrite-rule logic from there, but this gets complicated with passing URL parameters back and forth)
One conceptually simple way is to use a program-type rewritemap to call your EE-based service to check a U-A, assuming the program couldn't just perform the check itself (if you've only got some canned java interface into that DB)