[ https://issues.apache.org/jira/browse/WICKET-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597196#comment-13597196 ]
Emond Papegaaij commented on WICKET-5051: ----------------------------------------- I think this issue might be related to WICKET-5084. By the way, it's not a good idea to disable websocket support on the server while leaving it enabled on the client. You should also set eventBus.getParameters().setTransport(...) > Incorrect URL rendered when using Comet > ---------------------------------------- > > Key: WICKET-5051 > URL: https://issues.apache.org/jira/browse/WICKET-5051 > Project: Wicket > Issue Type: Bug > Components: wicket-atmosphere > Affects Versions: 6.5.0, 6.6.0 > Environment: Ubuntu 12.04 using Oracle JAVA 1.7.0_13 > Reporter: Marco Springer > Assignee: Emond Papegaaij > Priority: Minor > Labels: atmosphere, comet, websocket, wicket > Attachments: atmosphere_proxy_problem.zip, default > > > Initially I had a problem using Apache as a proxy in-front of a running Jetty > instance with WebSockets enable, with CometD as fallback. > I used the Apache config as described on > https://github.com/Atmosphere/atmosphere/wiki/How-to-run-Atmosphere-behind-Apache-WebServer. > With the above scenario running I only had problems with re-rendered markup > with link(s) in them. Links that are rendered through the usual client-server > requests are fine, even if they through normal Ajax calls. > As soon as a piece of markup was re-rendered through a push event the link > was bad, trying to open a website one path above the usual link, for example: > The application context path is '/appl/test', the link that comes from the > UrlRenderer was pointing to "/test" instead. > I thought it was a fault in my proxy config because directly accessing the > Jetty server on port 8080 is working fine! > What I seem to have missed was that somehow through the Apache proxy the > Atmosphere Framework was switching back to CometD. > How did I found out? > When I forcefully disabled WebSockets, forcing the CometD way to kick in, I > had the same URL problems again. Even though I'm accessing the Jetty instance > directly again on port 8080. Actually, using CometD the web application is > behaving very incorrect. > Sometimes the function(s) annotated with @Subscribe get called multiple times > without reason, again without the proxy. > If I turn on WebSockets again, all is fine. > The reason why I'm Apache using is because a whole lot of legacy applications > in our company are configured through Apache. I got some really bug-eyed > views when I proposed to migrate to Nginx at this stage. So using lighthttpd > or Nginx is out of the question unfortunately. > To nail things down a bit more, I have debugged back to the UrlRenderer class > in the "renderRelativeUrl" function, some mangling with the URL goes on in > here, prepending the "../" in the URL when the baseUrlSegments consists out > of more than 1 segment. > I don't know the internal reasons for this to be done but I can only see that > in my "push" event, this starts screwing things up a bit when using CometD. > I've attached a quickstart that contains 2 urls. > When "push" is clicked, the other browser instance should display (unhide) > the "aaaaaaaa" link. > In case of WebSockets, this works fine. > In case of CometD... well, meh. Sometimes the link unhides, sometimes it > doesn't. When the link unhides, it can't be clicked properly since it directs > to an incorrect context path. > I've also attached my very basic Apache proxy config, which is, well, the > same as the 1st link describes. > Thanks in advance. > Kind regards, > Marco -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira