[jira] [Updated] (WICKET-5051) Incorrect URL rendered when using Comet

["Marco Springer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Springer updated WICKET-5051:
-----------------------------------

    Attachment: default
                atmosphere_proxy_problem.zip
    
> 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