I have Embedded Jetty running which has reverse proxy servlet mapped for a particular URL. For ex: http://url1/abc is reverse proxied to http://url2. This works great, whenever someone calls http://url1/abc, data is served from http://url2.
I want to achieve the same using quarkus. Is this possible to do it in Quarkus? I think one of the option is to write own code in ContainerRequestFilter but I am looking more for OOTB support just like jetty. Can somehow undertow be leveraged here?
Please help.
UPDATE 1
I tried to do it through undertow-handlers.conf (placing it in META-INF folder). It worked well for redirect and rewrite but throwing error for reverse-proxy:
path-prefix('/a') -> redirect('/b)
path-prefix('/a1') -> rewrite('/b1')
path-prefix('/a2') -> reverse-proxy('http://localhost:7100/b')
If I have first two only, quarkus is started successfully and requests are served correctly. If I started using third one, quarkus start gets failed with below error.
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string no handler named reverse-proxy known handlers are [disallowed-methods, allowed-methods, jdbc-access-log, secure-cookie, access-log, mark-secure, response-rate-limit, canonical-path, response-code, disable-cache, ssl-headers, trace, blocking, url-decoding, access-control, redirect, set, ip-access-control, request-limit, resource, restart, clear, byte-range, done, rewrite, forwarded, stuck-thread-detector, jvm-route, learning-push, dump-request, proxy-peer-address, resolve-local-name, header, store-response, path-separator, resolve-peer-name]:
Although, I see undertow has reverse-proxy handler, not sure why it is not working for me.
http://undertow.io/undertow-docs/undertow-docs-2.0.0/index.html#predicates-attributes-and-handlers
I think the main issue is of dependency here. I see io\undertow\server\handlers package in my app libs but not io\undertow\server\handlers\proxy where I think the reverse proxy code is present.
How can I pull this dependency in my app?
Related
After having finished and tested an Angular2 application on my local machine, I decided to move it to an AWS cloud server with Apache.
I cloned the sw from git but, as soon as I launched the app, I got an error on the browser console stating:
EXCEPTION: Template parse errors:
Only void and foreign elements can be self closed "head" ("[ERROR ->]<head/>
After some research I found that all of my external html templates are magically enriched with a starting <head/> tag which I do not see trace of in my code.
To fix this I had to turn off mod-pagespeed .Since I am not familiar with Apache configuration I do not know which side effects this may have and whether there is any better solution. Any help would be very much appreciated.
I believe mod-pagespeed has an option where it automatically adds a head tag to an html document if it cannot find it in the document (before the body). To turn off this feature add this to your pagespeed apache configuration (ie. in the .htaccess):
To prevent javascript alterations also forbid a couple more filters
ModPagespeedForbidFilters add_head,rewrite_javascript,rewrite_javascript_inline,combine_javascript,inline_javascript
This way you can still enjoy the rest of the mod-pagespeed features :)
Consider the following setup for a deployed Grails application.
the Grails application is deployed on a Tomcat server (tomcat7)
in front of Tomcat an Apache webserver is deployed
Apache does SSL offloading, and acts as a proxy for Tomcat
So far a quite standard setup, which I have used succesfully many times. My issue is now with the links generated by the Grails application, especially those for the redirects (the standard controller redirects, which occur all the time e.g. after succesfully posting a form).
One configuration is different from all the other applications so far: in this Grails application no serverURL is configured. The application is a multi-tenant application, where each tenant is given it's own subdomain. (So if the application in general is running under https://www.example.com, a tenant can use https://tenant.example.com.) Subdomains are set automagically, that is without any configuration at DNS or Apache level. Grails can do so perfectly, by leaving out the serverURL property in Config.groovy: it then resolves all url's by inspecting the client host.
However: when generating redirect-url's, Grails is not aware the website is running under https. All redirect url's start with http... I guess this is no surprise, because nowhere in the application it is configured we are using https: there is no serverURL config, and technically the application is running on the standard http port of Tomcat, because of the SSL offloading and proxying by Apache.
So, bottom line: what can I do to make Grails generate proper redirects?
I have tried to extend the DefaultLinkGenerator and override the makeServerURL() method. Like this:
class MyLinkGenerator extends DefaultLinkGenerator {
MyLinkGenerator(String serverBaseURL, String contextPath) {
super(serverBaseURL, contextPath)
}
MyLinkGenerator(String serverBaseURL) {
super(serverBaseURL)
}
def grailsApplication
/**
* #return serverURL adapted to deployed scheme
*/
String makeServerURL() {
// get configured protocol
def scheme = grailsApplication.config.grails.twt.baseProtocol ?: 'https://'
println "Application running under protocol $scheme"
// get url from super
String surl = super.makeServerURL()
println "> super.makeServerURL(): $surl"
if (surl) {
// if super url not matching scheme, change scheme
if (scheme=='https://' && surl?.startsWith('http://')) {
surl = scheme + surl?.substring(7)
println "> re-written: $surl"
}
}
return surl
}
}
(Maybe not the most beautiful code, but I hope it explains what I'd like to do. And I left out the bit about configuring this class in resources.groovy.)
When running this code strange things happen:
In the log you see the code being executed, and a changed url (http > https) being produced, but...
The redirect sent to the browser is the unchanged url (http)
And even worse: all the resources in the generated views are crippled: they now all start with // (so what should be a relative "/css/myapp.css" is now "//css/myapp.css")
Any help or insight would be appreciated!
Grails version is 2.1.1 by the way (running a bit behind on upgrades...).
It seems you're always talking https to the outside world, so your cleanest option is to solve the problem where it originates, at your Apache webserver. Add to httpd.conf Header edit Location ^http://(.*)$ https://$1, and you're done.
If you have limitations that force you to solve this in your application you could do the rewrite of the Location header field in a Grails after interceptor. Details of that solution are in this post.
Some years have past since this question was written, but problems remain the same or at least similar ;-)
Just in case anyone hits the same/similar issue (that Grails redirect-URLs are http instead of https) ... We had this issue with a Grails 3.3.9 application running on OpenShift. The application was running in HTTP mode (on Port 8080) and the OpenShift Loadbalancer was doing the SSL-Termination.
We solved it by putting
server:
use-forward-headers: true
into our application.yml. After that Grails works perfect and all the redirects created were correct with https://.
Hint: We have do not use grails.serverURL in our configuration
I setup ActiveMQ 5.8.0 on a Windows 2003 virtual server for development purposes. I understand that there is suppose to be a REST interface for reading from and writing to queues and such. But, I can't seem to track down how to do it exactly. Port 8161 can be used to access the admin console, but every URL I try from Firefox Poster returns a 404. I tried URLs like these:
http://localhost:8161/queues <-- 404
http://localhost:61616/queues <-- some default message
http://localhost:61616/queue/inbox <-- same default message
http://localhost:8161/queue/inbox <-- 404
The documentation mentions mapping a URI to the servlet, but I'm not sure how or if I need to do this. The /demo feature is disabled by default, which is fine by me. How do I enable REST for my queues? Thanks!
As /demo is disabled, it been moved to /api
http://localhost:8161/api/message/
this is the path for all REST operations
I have configured cluster with two instances on glassfish 3.1.1 and iPlanet Web Server as a load-balancer (on the same machine). For test application provided with glassfish everything works ok (and this application has session replication enabled).
But when I try to make my own application working following situation takes place: it responds when I send requests on ports of a particular instances (that is 28080 and 28081), but when I try to send request through load balancer (port 81) I get error 404. My application has not session replication enabled yet, but it can just make a connection and create two other sessions for each instance. I would like to get similar effect with load balancer.
So I would like to determine:
Is session replication strongly required to load balancer works fine?
Does anyone know any other reasons of this error?
Message from iPlanet log:
[23/Aug/2012:05:44:16] failure ( 4120) myHost: for host 127.0.0.1 trying to GET /myApp/login.jsp, service-j2ee reports: PWC6117: File "c:/webserver7/https-myHost/docs/myApp/login.jsp" not found
Additional conclusions:
(81 - http-listener port on iPlanet)
When I send GET http://localhost:81/testApp then loadbalancer passes it to glassfish and returns correct site. But when I try the same with my test application, GET http://localhost:81/myApp then iPlanet looks for this site in its own resources (docs directory as in log above)
fragment of myHost-obj.conf:
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
NameTrans fn="name-trans-passthrough" name="lbplugin" config-file="C:/WebServer7/https-myHost/config/loadbalancer.xml"
NameTrans fn="assign-name" name="perf" from="/.perf"
NameTrans fn="ntrans-j2ee" name="j2ee"
NameTrans fn="pfx2dir" from="/mc-icons" dir="C:/WebServer7/lib/icons" name="es-internal"
PathCheck fn="uri-clean"
PathCheck fn="check-acl" acl="default"
PathCheck fn="find-pathinfo"
PathCheck fn="find-index-j2ee"
PathCheck fn="find-index" index-names="index.html,home.html,index.jsp"
ObjectType fn="type-j2ee"
ObjectType fn="type-by-extension"
ObjectType fn="force-type" type="text/plain"
Service method="(GET|HEAD)" type="magnus-internal/directory" fn="index-common"
Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"
Service method="TRACE" fn="service-trace"
Error fn="error-j2ee"
AddLog fn="flex-log"
</Object>
First, if you are running the Load Balancer plugin, then you may have a support contract (a GlassFish license is required before you put the plugin into production). If so, calling support is a good option.
To answer your first question, session replication is not required for the Load Balancer to work.
As a shameless plug, I have a 5-part youtube series on setting this up. You can skip the videos on downloading and installing and go straight to setup/configuration/testing. Based on what you describe, I suspect the issue isn't the plugin itself, but the loadbalancer.xml configuration. Look at loadbalancer.xml and see if myApp is configured.
Hope this helps.
My app ([URL]) is not responding. I have gone through the recommended steps on your site.
I have deployed this war to my local tc-server and everything is working there (/people-server/rest/persons/). I would expect to get some xml back from [URL]/people-server/rest/persons/.
Please advise
Darren Leung
Your app is actually responding to http://[URL]/_stax/status, which implies the container is able to receive and handle requests properly.
Since your app is returning 404 for /people-server/rest/persons path requests, this implies that there are no Servlets currently loaded by the container to handle those requests. There are two main reasons that your app may not have servlets configured at runtime:
You have not configured your app with Servlets properly to handle these requests (this is typically done via servlet and servlet-path entries in WEB-INF/web.xml)
There was an error that occurred during the startup sequence of your app that prevented the container from loading your configured Servlets.
To determine if there is an error, the first thing you should check is the logs for your app. Since you didn't post any errors, I'll assume that you checked the logs already and did not find any errors.
This leaves you with the scenario that you don't have any Servlets configured to handle the requests. After seeing your URL, I noticed that it is prefixed by /people-server, which looks suspiciously like a context-path prefix you may be using in your locally configured TC server. Since apps deployed on CloudBees run at the root context-path, I tried using the following URL and see that it is indeed responding:
[URL]/rest/persons/
This implies that you do have a Servlet configured for handling /rest/persons/ paths, which means you are encountering a slight difference in URLs expected in your local environment vs your deployed environment.
If you want this Servlet to be available at /people-server, you will need to update your web.xml to use this prefix for the path used by your REST Servlet. Alternatively, you can deploy the app as an EAR file with an application.xml that uses a context-path of /people-server for your webapp archive.
As a general rule - 400 type errors (eg 404 in this case) indicate a problem with the app almost always - and are typically related to path errors and mapping.
500 type errors mean there is an unhanded error in the application, this is as per:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Some causes of them could be if the application is slow to start, there can be a short period of time where there are some errors, 504 if the application (all instances of it) are very very slow (too slow).
If there is a persistent 502 happening this can indicate a platform problem in some cases (ie requests are not reaching your application).
You can often see errors in your apps log (bees app:tail will stream this - or use the console).
If your app uses JAX-RS to serve rest content on a jboss ("JavaEE 6 Web profile") container, you need to enable container support for this feature. Just add this servlet declaration to your web.xml
<servlet>
<servlet-name>jax-rs</servlet-name>
<servlet-class>javax.ws.rs.core.Application</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jax-rs</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Your IDE may warn javax.ws.rs.core.Application is not a servlet, and that's indeed a strange detail from JAX-RS API, but that's the correct class to be used.