-
Notifications
You must be signed in to change notification settings - Fork 780
Use Jetty's ProxyServlet implementation #2753
Conversation
941a904
to
9fcbd53
Compare
Made configurable via OSGi Signed-off-by: John Cocula <john@cocula.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm in general.
One concern I have: Up to know, ESH is compatible to javax.servlet 2.4 (see C.2, afaik, OSGi 4.2 uses servlet spec 2.4) - the Jetty ProxyServlet breaks this (I found a dependency to at least 2.6, which corresponds to Servlet 3.0 spec).
if (sitemapName == null) { | ||
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Parameter 'sitemap' must be provided!"); | ||
logger.error("Parameter 'sitemap' must be provided!"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not really like such things to be logged as errors in the runtime log. After all, these might be unsolicited requests from remote clients and errors should rather turn up in the client (if on the server, it should rather be some http access/error log).
Is there no way to send an HTTP error back here as it was done before?
Specific errors should be sent back to the client now (more accurate than previous set) instead of being logged. I will look at javax.servlet 2.4 compatibility issue. Do you have any suggestions? |
I suppose my testing works on OH2 because it is using OSGi Release 5 or 6? Any chance ESH can move to a later OSGi spec, since it's also moving to Java 8 soon?
|
Unfortunately not as there are ESH solutions out there that are using OSGi 4.2 (which is still quite widespread in commercial deployments).
Maybe we could do a similar solution as in the SSE support: This checks for servlet3 support and then registers different implementations. So we could keep the old proxy servlet as a fallback, while registering the Jetty proxy servlet on all servlet3 capable environments. Wdyt? |
OK, I will add that. |
…ailable; otherwise register older blocking servlet, but maintain identical external usage. Signed-off-by: John Cocula <john@cocula.com>
Added old servlet back when servlet API for async is not available. Tested old and new servlets in OH2 IDE, including Basic Authentication header. Not tested in an actual OSGi R4.2 container. |
Signed-off-by: John Cocula <john@cocula.com>
@watou Would you mind dropping an already build version of the bundle here in the comment
|
@marcelrv I would if I could (or knew how)! It eludes me how to build with Maven when something more is needed in the target platform. @maggu2810 (I think) added the
If anyone knows to how to build PRs like this with |
I'll take care of all necessary steps. Consider it done by tomorrow EOB latest! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, just one very minor comment
@@ -18,6 +18,7 @@ Import-Package: javax.imageio, | |||
org.eclipse.jetty.client.api, | |||
org.eclipse.jetty.client.util, | |||
org.eclipse.jetty.http, | |||
org.eclipse.jetty.proxy, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you add optional=true
here, we would be fully backward compatible - i.e. the jetty-proxy bundle does not even have to be present, in which case we would automatically fall back to the old implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kaikreuzer Just to be clear, are you suggesting that I add optional=true
now, and that no other code changes are required for this to work in the way you described? Once org.eclipse.jetty.proxy is in the TP (which I think you are going to do), is optional=true
needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to have it in the TP in any case, otherwise the code won't compile, so I will also have to add it to the OH2 IDE TP.
The "optional=true" is relevant at runtime: with it, the smarthome.ui bundle can be resolved and used even if jetty-proxy bundle is NOT available (and I guess on a system which only has servlet 2.4, it simply CANNOT be available anyhow).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added optional resolution of org.eclipse.jetty.proxy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perfect, thanks.
|
@maggu2810 Thank you very much for the information about alternatives. I will find that very useful in the future. |
…that cannot support it. Signed-off-by: John Cocula <john@cocula.com>
The Jetty proxy servlet is a more thorough implementation of a proxy, and likely fixes #2692 (not closing connections) and header mistakes (#2734 (comment)).
It is configurable via OSGi ConfigAdminManager using pid
org.eclipse.smarthome.proxy
. Any of the properties documented here can be passed to the servlet."Assumed" Basic authentication behaves the same as previous, but required Digest authentication is not addressed (see this report for current issues with authentication). To be clear, the authentication behavior should be identical to the previous version.
A follow-on PR will address which URLs are allowed to be proxied by maintaining a whitelist:
url=
host:port is on a whitelist configured for the servlet, it will be proxied. If not, the servlet will respond with a 302 redirect to the given URL.Signed-off-by: John Cocula john@cocula.com