jetty proxy
BlastChat
problems the other way. I am looking at following:
http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet
Can anybody advice how to configure this jetty servlet so that it
redirects to apache everything but /cometd calls?
Simone Bordet
I was able to configure this setup in this way (no deep testing, but
seems to work fine, still almost no time ;).
I used the primer to create a CometD 2 application.
Then I added this servlet to web.xml:
<servlet>
<servlet-name>proxy</servlet-name>
<servlet-class>org.eclipse.jetty.servlets.ProxyServlet$Transparent</servlet-class>
<init-param>
<param-name>ProxyTo</param-name>
<param-value>http://localhost:80</param-value>
</init-param>
<init-param>
<param-name>Prefix</param-name>
<param-value>/</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
That's it.
The whole webapp is deployed to context path /.
Given the rules for mapping requests to servlets, any request to
/cometd/* will be mapped to the CometD servlet (because its mapping -
/cometd/* - is more specific than the other mapping - /*), and any
other request will be mapped to the proxy servlet, which redirects to
whatever is listening on port 80.
Let us know if it works for you.
Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
BlastChat
my issue. I was expecting it would work something like that, but let
me ask few specifics:
1. I am using cometd 1.0.0, jetty 6.1.22, will the code look the same
for that version?
2. into which web.xml do I place this code? into my chat servlet
web.xml?
3. my webapp directory is more or less empty (I mean I do not have my
php files there), only cometd.war is there, is that alright, or what
does it exactly mean that "whole webapp is deployed to context path /"
You see, I am no expert in this matters.
P.
BlastChat
I plan to deploy Jetty on 80 and 443 (apache on 8080 and 8443)
How will this servlet handle https requests?
P.
BlastChat
<servlet-class>org.mortbay.proxy.AsyncProxyServlet$Transparent</
servlet-class>
BlastChat
0. Setup:
Jetty 6.1.22 started on ports 80 and 443, Httpd started on 8080 and
8443
My regular webpage calls are http://www.website.com
Calls to cometd chat are http://www.website.com/cometd/cometd
1. I kept web.xml more or less in same format as it arrived with demo
application under jetty 6.1.22 and now I added for proxy:
<servlet>
<servlet-name>cometd</servlet-name>
<servlet-
class>org.mortbay.cometd.continuation.ContinuationCometdServlet</
servlet-class>
...
</servlet>
<servlet-mapping>
<servlet-name>cometd</servlet-name>
<url-pattern>/cometd/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>cometdDemo</servlet-name>
<servlet-class>org.cometd.demo.CometdDemoServlet</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet>
<servlet-name>proxy</servlet-name>
<servlet-class>org.mortbay.proxy.AsyncProxyServlet
$Transparent</servlet-class>
<init-param>
<param-name>ProxyTo</param-name>
<param-value>http://127.0.0.1:8080</param-value>
<init-param>
<param-name>Prefix</param-name>
<param-value>/</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
2010-08-11 22:41:12.091:INFO::CometdDemoServlet started
2010-08-11 22:41:12.092:INFO::Opened /home/apps/jetty-6.1.22/logs/
2010_08_11.request.log
2010-08-11 22:41:12.126:INFO::Started
SelectChann...@0.0.0.0:80
2010-08-11 22:41:12.763:INFO::Started
SslSelectCha...@0.0.0.0:443
2010-08-11 22:41:13.046:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:13.214:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:13.380:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:13.552:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:13.720:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:13.891:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:14.058:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:14.230:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:14.394:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:41:14.572:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:42:03.932:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:42:04.066:WARN::javax.net.ssl.SSLHandshakeException: no
cipher suites in common
2010-08-11 22:42:06.858:INFO:/cometd:Transparent AsyncProxyServlet @ /
to http://127.0.0.1:8080
I am not sure why is it complaining about no cipher suites in common
(SslSelectChannelConnector when started on 8443 is not complaining
about it)
3. Opening basic http://website.com, page loaded says:
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
* /cometd ---> org.mortbay.jetty.webapp.WebAppContext@26d66426{/
cometd,/home/apps/jetty-6.1.22/contexts/cometd.d}
4. And Jetty log adds:
2010-08-11 22:42:06.870:WARN::/cometd/
java.lang.NumberFormatException: 8080cometd
at org.mortbay.util.TypeUtil.parseInt(TypeUtil.java:380)
at org.mortbay.jetty.HttpURI.getPort(HttpURI.java:448)
at
org.mortbay.jetty.client.HttpExchange.setURL(HttpExchange.java:248)
at
org.mortbay.proxy.AsyncProxyServlet.service(AsyncProxyServlet.java:
212)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
390)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:
230)
5. I reverted back with no problems, but am willing to give it another
try, of course only if you find time and give me another advice.
P.
PS: I am not sure why, but lately jetty startup procedure is taking
between 3-5 minutes (normally it started right away), if you have any
advice here, that would be nice.
Simone Bordet
On Wed, Aug 11, 2010 at 22:04, BlastChat <blas...@gmail.com> wrote:
> First of all thank you for getting back to me, I was afraid you forgot
> my issue. I was expecting it would work something like that, but let
> me ask few specifics:
>
> 1. I am using cometd 1.0.0, jetty 6.1.22, will the code look the same
> for that version?
I used CometD 2 and Jetty 7, but should be the same for CometD 1 and
Jetty 6, modulo some package renaming (which you got right in a later
email, "org.mortbay.proxy.AsyncProxyServlet$Transparent").
> 2. into which web.xml do I place this code? into my chat servlet
> web.xml?
Yes.
> 3. my webapp directory is more or less empty (I mean I do not have my
> php files there), only cometd.war is there, is that alright, or what
> does it exactly mean that "whole webapp is deployed to context path /"
It means that the web application is deployed to the root context (or,
equivalently that the contextPath is the emtpy string). You have
deployed your webapp under context path "/cometd", and the servlet
path is again "/cometd" (so your CometD servlet responds to
http://mysite/cometd/cometd). You need to change the deployment of
that webapp to have context path "" and servlet path "/cometd" (so
your CometD servlet responds to http://mysite/cometd).
Show me how you deployed your war, and I'll tell you how to do it.
In this way a request to http://mysite.com/index.php ends up to Jetty,
which figures out this request is for the web application deployed on
the root context; then Jetty figures out this request is for the proxy
servlet (because it does not match "/cometd/*"), the proxy servlet
calls Apache, and returns the response to the client.
Regarding https, there is no need for you to forward https requests to
Apache. Let Jetty handle both http and https, and have the
communication between Jetty and Apache in plain http.
So you configure 2 connectors in Jetty (http and https) and one in
Apache (http).
The proxy servlet does not support forwarding https traffic.
Regarding the slow start time, you can take a thread dump by hitting
ctrl + \ in the console (Unix/Linux); it is probably due to the fact
that the SSL machinery needs a secure random seed, and this is
generated by listening to hardware events until a sufficient amount of
random noise is gathered. If this is the case, there is not much we
can do about, but please confirm it.
Simon
--
BlastChat
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
<!-- Ensure Jetty Plus features are enabled for this
webapp -->
<Set name="configurationClasses">
<Array type="java.lang.String">
<Item>org.mortbay.jetty.webapp.WebInfConfiguration</Item>
<Item>org.mortbay.jetty.plus.webapp.EnvConfiguration</Item>
<Item>org.mortbay.jetty.annotations.Configuration</Item>
<Item>org.mortbay.jetty.webapp.JettyWebXmlConfiguration</Item>
<Item>org.mortbay.jetty.webapp.TagLibConfiguration</Item>
</Array>
</Set>
<Set name="contextPath">/cometd</Set>
<Set name="war"><SystemProperty name="jetty.home" default="."/>/
contexts/cometd.d</Set>
So, I am assuming that changing
<Set name="contextPath">/cometd</Set>
to
<Set name="contextPath">/</Set>
will take care of /cometd/cometd change to /cometd calls.
2. about ssl
When Jetty is started with ports 8080 and 8443 all works fine:
2010-08-11 22:50:35.242:INFO::Started
SelectChann...@0.0.0.0:8080
2010-08-11 22:50:35.607:INFO::Started
SslSelectCha...@0.0.0.0:8443
But when I changed it to 80 and 443 I got those cipher suites problem:
010-08-11 22:41:12.126:INFO::Started
cipher suites in common
changed to 443, any idea?
3. keystore
I generated my keystore like this (deleted the old one):
keytool -keystore keystore -import -alias jetty -file
mycert.crt -trustcacerts
where mycert.crt is a certificate sent by certificate authority, it
asked for the password, so I put new password there. Which leads to my
follow up question about keystore:
This is copy from Jetty SSL Config Howto page:
<Call name="addConnector">
<Arg>
<New class="org.mortbay.jetty.security.SslSocketConnector">
<Set name="Port">8443</Set>
<Set name="maxIdleTime">30000</Set>
<Set name="keystore"><SystemProperty name="jetty.home"
default="." />/etc/keystore</Set>
<Set name="password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</
Set>
<Set name="keyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="truststore"><SystemProperty name="jetty.home"
default="." />/etc/keystore</Set>
<Set name="trustPassword">OBF:
1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
</Arg>
</Call>
Which password is which?
password
keyPassword
trustPassword
I think if I solve this 443 problem, this solution might actually
work. Your help is highly appreciated.
Simone Bordet
On Thu, Aug 12, 2010 at 20:25, BlastChat <blas...@gmail.com> wrote:
> So, I am assuming that changing
> <Set name="contextPath">/cometd</Set>
> to
> <Set name="contextPath">/</Set>
> will take care of /cometd/cometd change to /cometd calls.
Correct.
> 2. about ssl
> When Jetty is started with ports 8080 and 8443 all works fine:
>
> 2010-08-11 22:50:35.242:INFO::Started
> SelectChann...@0.0.0.0:8080
> 2010-08-11 22:50:35.607:INFO::Started
> SslSelectCha...@0.0.0.0:8443
>
> But when I changed it to 80 and 443 I got those cipher suites problem:
>
> 010-08-11 22:41:12.126:INFO::Started
> SelectChannelConnec...@0.0.0.0:80
> 2010-08-11 22:41:12.763:INFO::Started
> SslSelectChannelConnec...@0.0.0.0:443
> 2010-08-11 22:41:13.046:WARN::javax.net.ssl.SSLHandshakeException: no
> cipher suites in common
>
> I am not quite sure why would this come up just because 8443 was
> changed to 443, any idea?
Nope, very strange.
Are you starting Jetty with root privileges ? And you don't have file
permission problems reading the keystore files ?
I think it's the "password", which is the keystore password.
However, I would not use a specific alias (you used "jetty" above),
just use the default. I would like to avoid that the server looks for
the cert on the default alias when you've put it somewhere else, and
for this reason you get the error.
BlastChat
> > When Jetty is started with ports 8080 and 8443 all works fine:
>
> > 2010-08-11 22:50:35.242:INFO::Started
> > But when I changed it to 80 and 443 I got those cipher suites problem:
>
> > 010-08-11 22:41:12.126:INFO::Started
> > SelectChannelConnec...@0.0.0.0:80
> > 2010-08-11 22:41:12.763:INFO::Started
> > SslSelectChannelConnec...@0.0.0.0:443
> > 2010-08-11 22:41:13.046:WARN::javax.net.ssl.SSLHandshakeException: no
> > cipher suites in common
>
> > I am not quite sure why would this come up just because 8443 was
> > changed to 443, any idea?
>
> Nope, very strange.
> Are you starting Jetty with root privileges ? And you don't have file
> permission problems reading the keystore files ?
>
it user " jetty"
I will check keystore permissions, 'read' for user 'jetty' should be
enough?
<Set name="password">mypassword</Set>
Where mypassword is not the password of certificate itself, but
password I had to insert when executing command
mycert.crt -trustcacerts
> just use the default. I would like to avoid that the server looks for
> the cert on the default alias when you've put it somewhere else, and
> for this reason you get the error.
>
default="." />/etc/keystore</Set>
<Set name="keystore"><SystemProperty default="." />/etc/keystore</
Set>
Am I understanding it correctly?
But still strange is that this was not observed when jetty was on port
8443, hm...did I forgot to change 8443 port in some additional file to
443 by any chance?
BlastChat
further:
1. I moved context from /cometd to / with a success
2. Started jetty on 80 and 443 (443 has still
around by redirect 443 to 8443 at iptables level)
3. direct request to http://www.myweb.com loading php page, page loads
but looks like no images are loaded, no .css probably not even .js
files are being delivered back to browser (client). This is a major
showstopper.
Following error was not generated when http://www.myweb.com was used
(so it is not related to no images, no css, only a wild guess), but
URL called a different page
2010-08-14 00:54:54.629:WARN::/index2.php?option=...
java.lang.NumberFormatException: 8080index2.php?option=...
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:
114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
542)
at org.mortbay.jetty.HttpConnection
$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:
404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
Simone Bordet
On Sat, Aug 14, 2010 at 10:16, BlastChat <blas...@gmail.com> wrote:
> so I made another attempt to "switch". this time it went a little bit
> further:
>
> 1. I moved context from /cometd to / with a success
> 2. Started jetty on 80 and 443 (443 has still
> ":javax.net.ssl.SSLHandshakeException: no cipher suites in common"
> warning, which is not showing up when 8443 port is used, I could go
> around by redirect 443 to 8443 at iptables level)
> 3. direct request to http://www.myweb.com loading php page, page loads
> but looks like no images are loaded, no .css probably not even .js
> files are being delivered back to browser (client). This is a major
> showstopper.
>
> Following error was not generated when http://www.myweb.com was used
> (so it is not related to no images, no css, only a wild guess), but
> URL called a different page
> 2010-08-14 00:54:54.629:WARN::/index2.php?option=...
> java.lang.NumberFormatException: 8080index2.php?option=...
"8080" is attached to the path "index2.php"
What have you specified as ProxyTo and Prefix ? You must be missing a slash.
BlastChat
I never did hit 8443 in my original configuration, so I was not seeing
this warning at all. There must be problem with something somewhere,
not sure what
WARN::javax.net.ssl.SSLHandshakeException: no cipher suites in common
You mentioned something about default in this code:
etc/keystore</Set>
<Set name="keystore"><SystemProperty name="" default="." />/etc/
keystore</Set>
On Aug 14, 6:53 am, Simone Bordet <simone.bor...@gmail.com> wrote:
> Hi,
>
>
>
>
>
> On Sat, Aug 14, 2010 at 10:16, BlastChat <blastc...@gmail.com> wrote:
> > so I made another attempt to "switch". this time it went a little bit
> > further:
>
> > 1. I moved context from /cometd to / with a success
> > 2. Started jetty on 80 and 443 (443 has still
> > ":javax.net.ssl.SSLHandshakeException: no cipher suites in common"
> > warning, which is not showing up when 8443 port is used, I could go
> > around by redirect 443 to 8443 at iptables level)
> > files are being delivered back to browser (client). This is a major
> > showstopper.
>
> > URL called a different page
> > 2010-08-14 00:54:54.629:WARN::/index2.php?option=...
> > java.lang.NumberFormatException: 8080index2.php?option=...
>
> "8080" is attached to the path "index2.php"
> What have you specified as ProxyTo and Prefix ? You must be missing a slash.
<servlet-name>proxy</servlet-name>
<servlet-class>org.mortbay.proxy.AsyncProxyServlet
$Transparent</servlet-class>
<init-param>
<param-name>ProxyTo</param-name>
<param-value>http://127.0.0.1:8080</param-value>
<init-param>
<param-name>Prefix</param-name>
<param-value>/</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
But then why would it load page now at all?
Simone Bordet
On Sat, Aug 14, 2010 at 19:59, BlastChat <blas...@gmail.com> wrote:
> btw, I think 8443 and 443 makes no difference, difference is only that
> I never did hit 8443 in my original configuration, so I was not seeing
> this warning at all. There must be problem with something somewhere,
> not sure what
>
> WARN::javax.net.ssl.SSLHandshakeException: no cipher suites in common
I think you have a problem either with the certificate or with the way
it is imported to the keystore via the keytool command.
You should have generated a key pair (RSA or DSA ?), extracted the
certificate signing request, sent it to a root certificate authority,
got it signed and received it back.
What you get back from the root CA is what you should import.
If you did so, what does:
keytool -list -keystore keystore -v
prints ?
Are you sure that the root certificate authority you used is
recognized by the JDK ?
BlastChat
http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
2. I followed this http://docs.codehaus.org/display/JETTY/SSL+Cipher+Suites
to add cipher suites to my jetty.xml file (how I figure which ciphers
to include? openssl ciphers -v 'my apache CipherSuites definition', it
printed out something like:
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256)
Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256)
Mac=SHA1
etc.
I believe step 1 and 2 might fix the "no cipher suites" error and I
will try it out tonight
3. Seems like last thing to resolve is the:
java.lang.NumberFormatException: 8080index2.php?option=...
Any clues?
Simone Bordet
BlastChat
is incorrect and / should be there too?
<param-name>ProxyTo</param-name><param-value>http://www.google.com</
param-value>
should be
<param-name>ProxyTo</param-name><param-value>http://www.google.com/</
param-value>
> > Do you thinkhttp://127.0.0.1:8080should behttp://127.0.0.1:8080/?
>
> Correct.
>
> Simon
> --http://bordet.blogspot.com
Simone Bordet
On Sat, Aug 14, 2010 at 22:11, BlastChat <blas...@gmail.com> wrote:
> Does that mean then that example at http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet
> is incorrect and / should be there too?
> <param-name>ProxyTo</param-name><param-value>http://www.google.com</
> param-value>
> should be
> <param-name>ProxyTo</param-name><param-value>http://www.google.com/</
> param-value>
Seems that the documentation is wrong, perhaps only in the case of the
root context.
I just tried with http://localhost:8080/ and works for me.
Simon
--
BlastChat
1. Jetty starts in 3-5 minutes still (will get back to it some other
time)
2. adding "cipher suites" to my jetty.xml generated following errors:
[root@blastchat etc]# 2010-08-14 22:14:36.854:WARN::Config error at
<Set name="IncludeCipherSuites">| <Array
type="java.lang.String"><Item>DHE-RSA-AES256-SHA</Item>...</
Array>| </Set> java.lang.NoSuchMethodException: class
org.mortbay.jetty.security.SslSelectChannelConnector.setIncludeCipherSuites(class
[Ljava.lang.String;)
2010-08-14 22:14:36.854:WARN::Config error at <Call
name="addConnector"><Arg>| <New
class="org.mortbay.jetty.security.SslSelectChannelConnector"><Set
name="Port">443</Set><Set name="maxIdleTime">30000</Set>...</New>|
</Arg></Call> java.lang.NoSuchMethodException: class
org.mortbay.jetty.security.SslSelectChannelConnector.setIncludeCipherSuites(class
[Ljava.lang.String;)
2010-08-14 22:14:36.855:WARN::EXCEPTION
java.lang.NoSuchMethodException: class
org.mortbay.jetty.security.SslSelectChannelConnector.setIncludeCipherSuites(class
[Ljava.lang.String;)
at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:
424)
at
org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:248)
at
org.mortbay.xml.XmlConfiguration.newObj(XmlConfiguration.java:626)
at
org.mortbay.xml.XmlConfiguration.itemValue(XmlConfiguration.java:915)
at
org.mortbay.xml.XmlConfiguration.value(XmlConfiguration.java:837)
at org.mortbay.xml.XmlConfiguration.call(XmlConfiguration.java:
523)
at
org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:252)
at
org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:214)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:
974)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
Removing from jetty.xml
<Set name="IncludeCipherSuites">
<Array type="java.lang.String">
<Item>DHE-RSA-AES256-SHA</Item>
resolved the issue.
3. So it started up, and is actually working, but now I see following
errors in jetty error log
2010-08-14 22:23:08.461:WARN::EXCEPTION on
org.mortbay.proxy.AsyncProxyServlet$1@1454609693=GET//127.0.0.1:8080/
components/com_bc/js/bc/dojo/dojo.js?v=200902112385#9
org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
787)
at org.mortbay.jetty.AbstractGenerator
$Output.blockForOutput(AbstractGenerator.java:550)
at org.mortbay.jetty.AbstractGenerator
$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection
$Output.flush(HttpConnection.java:1005)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:579)
at org.mortbay.proxy.AsyncProxyServlet
$1.onResponseContent(AsyncProxyServlet.java:183)
at org.mortbay.jetty.client.HttpExchange
$Listener.onResponseContent(HttpExchange.java:717)
at org.mortbay.jetty.client.HttpConnection
$Handler.content(HttpConnection.java:500)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at
org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:
236)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
org.mortbay.proxy.AsyncProxyServlet$1@671272803=GET//127.0.0.1:8080/
components/com_bc/js/bc/blastchat/room.js?v=200902117603#9
org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
787)
at org.mortbay.jetty.AbstractGenerator
$Output.blockForOutput(AbstractGenerator.java:550)
at org.mortbay.jetty.AbstractGenerator
$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection
$Output.flush(HttpConnection.java:1005)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:579)
at org.mortbay.proxy.AsyncProxyServlet
$1.onResponseContent(AsyncProxyServlet.java:183)
at org.mortbay.jetty.client.HttpExchange
$Listener.onResponseContent(HttpExchange.java:717)
at org.mortbay.jetty.client.HttpConnection
$Handler.content(HttpConnection.java:500)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at
org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:
236)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
org.mortbay.proxy.AsyncProxyServlet$1@1350402330=GET//127.0.0.1:8080/
components/com_bc/js/bc/blastchat/roomUtils.js?v=200902117616#9
org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
787)
at org.mortbay.jetty.AbstractGenerator
$Output.blockForOutput(AbstractGenerator.java:550)
at org.mortbay.jetty.AbstractGenerator
$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection
$Output.flush(HttpConnection.java:1005)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:579)
at org.mortbay.proxy.AsyncProxyServlet
$1.onResponseContent(AsyncProxyServlet.java:183)
at org.mortbay.jetty.client.HttpExchange
$Listener.onResponseContent(HttpExchange.java:717)
at org.mortbay.jetty.client.HttpConnection
$Handler.content(HttpConnection.java:500)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at
org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:
236)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
org.mortbay.proxy.AsyncProxyServlet$1@1270404225=GET//127.0.0.1:8080/
components/com_bc/js/bc/dijit/themes/blastchat/Main.css?
v=200902112385#9
org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
787)
at org.mortbay.jetty.AbstractGenerator
$Output.blockForOutput(AbstractGenerator.java:550)
at org.mortbay.jetty.AbstractGenerator
$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection
$Output.flush(HttpConnection.java:1005)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:579)
at org.mortbay.proxy.AsyncProxyServlet
$1.onResponseContent(AsyncProxyServlet.java:183)
at org.mortbay.jetty.client.HttpExchange
$Listener.onResponseContent(HttpExchange.java:717)
at org.mortbay.jetty.client.HttpConnection
$Handler.content(HttpConnection.java:500)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at
org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:
236)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
fatal alert: unknown_ca
2010-08-14 22:25:41.290:WARN::javax.net.ssl.SSLException: Received
fatal alert: unknown_ca
2010-08-14 22:26:06.627:WARN::EXCEPTION on
org.mortbay.proxy.AsyncProxyServlet$1@277551759=GET//127.0.0.1:8080/
component
s/com_bc/js/bc/blastchat/chatUtils.js?v=200902117603#9
org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
787)
at org.mortbay.jetty.AbstractGenerator
$Output.blockForOutput(AbstractGenerator.java:550)
at org.mortbay.jetty.AbstractGenerator
$Output.flush(AbstractGenerator.java:571)
at org.mortbay.jetty.HttpConnection
$Output.flush(HttpConnection.java:1005)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:648)
at org.mortbay.jetty.AbstractGenerator
$Output.write(AbstractGenerator.java:579)
at org.mortbay.proxy.AsyncProxyServlet
$1.onResponseContent(AsyncProxyServlet.java:183)
at org.mortbay.jetty.client.HttpExchange
$Listener.onResponseContent(HttpExchange.java:717)
at org.mortbay.jetty.client.HttpConnection
$Handler.content(HttpConnection.java:500)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:
212)
at
org.mortbay.jetty.client.HttpConnection.handle(HttpConnection.java:
236)
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
409)
at org.mortbay.thread.QueuedThreadPool
$PoolThread.run(QueuedThreadPool.java:582)
BlastChat
2010-08-14 22:38:06.050:WARN::EXCEPTION on
org.mortbay.proxy.AsyncProxyServlet$1@1343693045=GET//127.0.0.1:8080/
downloads?task=finish&cid=66&catid=5#9
java.lang.IllegalStateException: State==HEADER
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
683)
java.lang.IllegalStateException: State==HEADER
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
683)
java.nio.channels.SocketChannel[connected local=/webservip:443 remote=/
clientip:3744]
Simone Bordet
On Sun, Aug 15, 2010 at 07:30, BlastChat <blas...@gmail.com> wrote:
> 3. So it started up, and is actually working, but now I see following
> errors in jetty error log
>
> 2010-08-14 22:23:08.461:WARN::EXCEPTION on
> org.mortbay.proxy.AsyncProxyServlet$1@1454609693=GET//127.0.0.1:8080/
> components/com_bc/js/bc/dojo/dojo.js?v=200902112385#9
> org.mortbay.jetty.EofException
> at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
> 787)
> at org.mortbay.jetty.AbstractGenerator
> $Output.blockForOutput(AbstractGenerator.java:550)
Jetty was trying to write more data to a slow connection, but the
client closed it.
Ignorable.
> 2010-08-14 22:24:59.264:WARN::javax.net.ssl.SSLException: Received
> fatal alert: unknown_ca
> 2010-08-14 22:25:41.290:WARN::javax.net.ssl.SSLException: Received
> fatal alert: unknown_ca
No idea, but seems a problem with the client's certificate chain...
Perhaps an attack ?
> java.lang.IllegalStateException: State==HEADER
> at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
I think this was fixed. Remind me what version of Jetty are you using ?
Any reason for you to stay on Jetty 6 and not switch to Jetty 7 ?
> 2010-08-14 22:39:27.977:WARN::SSL renegotiate denied:
> java.nio.channels.SocketChannel[connected local=/webservip:443 remote=/
> clientip:3744]
SSL renegotiation are denied to prevent a security risk. This is a
known bug in the JDK.
BlastChat
> > 3. So it started up, and is actually working, but now I see following
> > errors in jetty error log
>
> > 2010-08-14 22:23:08.461:WARN::EXCEPTION on
> > org.mortbay.proxy.AsyncProxyServlet$1@1454609693=GET//127.0.0.1:8080/
> > components/com_bc/js/bc/dojo/dojo.js?v=200902112385#9
> > org.mortbay.jetty.EofException
> > at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
> > 787)
> > at org.mortbay.jetty.AbstractGenerator
> > $Output.blockForOutput(AbstractGenerator.java:550)
>
> Jetty was trying to write more data to a slow connection, but the
> client closed it.
> Ignorable.
files (icons).
>
> > 2010-08-14 22:24:59.264:WARN::javax.net.ssl.SSLException: Received
> > fatal alert: unknown_ca
> > 2010-08-14 22:25:41.290:WARN::javax.net.ssl.SSLException: Received
> > fatal alert: unknown_ca
>
> No idea, but seems a problem with the client's certificate chain...
> Perhaps an attack ?
so.hm...
>
> > java.lang.IllegalStateException: State==HEADER
> > at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:
>
> I think this was fixed. Remind me what version of Jetty are you using ?
> Any reason for you to stay on Jetty 6 and not switch to Jetty 7 ?
whole application to Jetty 7 at this time (instructions are there, but
not detailed enough for me, will take me longer time to do so)
>
> > 2010-08-14 22:39:27.977:WARN::SSL renegotiate denied:
> > java.nio.channels.SocketChannel[connected local=/webservip:443 remote=/
> > clientip:3744]
>
> SSL renegotiation are denied to prevent a security risk. This is a
> known bug in the JDK.
Trygve Lie
Hope I'm not causing any confusion here but I had some problems with the
same Proxy a while ago and this is my experience.
> Does that mean then that example at http://docs.codehaus.org/display/JETTY/Asynchronous+Proxy+Servlet
> is incorrect and / should be there too?
The example is correct.
What I did struggle with was double // sent to the destination server
after the proxy servlet had done it's job. Note that there is no
trailing / at the ProxyTo and a prefix / at the Prefix. If you have a
trailing / at the ProxyTo also you will get a // which will make the
request against the destination server fail.
Kind regards
Trygve Lie
http://www.trygve-lie.com/
BlastChat
problem. It seems that it makes a difference if you specify port or
not, hm?
Mentioned example points to http://www.google.com , but I was pointing
it to http://127.0.0.1:80 and it did not work, http://127.0.0.1:80/ is
working with no problems (of course generally speaking, mentioned
problems are still there, but very large portion of them are 'just'
warnings)
P.
On Aug 16, 1:22 am, Trygve Lie <p...@trygve-lie.com> wrote:
> Hi
>
> Hope I'm not causing any confusion here but I had some problems with the
> same Proxy a while ago and this is my experience.
>
BlastChat Support
I ran into serious problem today with the proxy, it stopped to forward
requests completely till I restarted jetty.
I am attaching log file for you to examine and hopefully be able to
tell me something about it or even better to find a solution I do not
see attach option.
Most of those errors are always present, but this time they somehow
spun into a more serious situation.
thank you for any comments or recommendations.
P.
BlastChat
problem is that http requests which are forwarded to apache make
apache see them as coming from 127.0.0.1, so proxy is not forwarding
original IP address of requester.
Is there a way for apache to see original IP and log it into its logs
when jetty proxy is in front of it?
thank you
Peter
> 70KViewDownload
Greg Wilkins
There are a bunch of headers that can be set in a proxy to tell the server where the original request came from:
private String _forwardedHostHeader = "X-Forwarded-Host";
private String _forwardedServerHeader = "X-Forwarded-Server";
private String _forwardedForHeader = "X-Forwarded-For";
private String _forwardedProtoHeader = "X-Forwarded-Proto";
Hmmm the Jetty proxy does not appear to set those fields!!! ooops.
If you raise a bugzilla and I'll fix it!
cheers
--
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To post to this group, send email to cometd...@googlegroups.com
To unsubscribe from this group, send email to cometd-users...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cometd-users
Visit the CometD website at http://www.cometd.org
BlastChat
1. can you please provide link where to submit bug?
2. could you please take a look at attached logfile (previous post)
and observe errors that jetty proxy is printing out? bunch of EOF
error of some sort. If that needs bug submission I'll do it too...
P.
On Oct 11, 11:41 pm, Greg Wilkins <gr...@intalio.com> wrote:
> There are a bunch of headers that can be set in a proxy to tell the server
> where the original request came from:
>
> private String _forwardedHostHeader = "X-Forwarded-Host";
> private String _forwardedServerHeader = "X-Forwarded-Server";
> private String _forwardedForHeader = "X-Forwarded-For";
> private String _forwardedProtoHeader = "X-Forwarded-Proto";
>
> Hmmm the Jetty proxy does not appear to set those fields!!! ooops.
>
> If you raise a bugzilla and I'll fix it!
>
> cheers
>
BlastChat
there...or should I place it under project Cometd -> "No component"?
What about the #2 issue?
P.
Simone Bordet
On Tue, Oct 12, 2010 at 09:20, BlastChat <blas...@gmail.com> wrote:
> Greg,
>
> 1. can you please provide link where to submit bug?
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty
Simon
--