Community
Participate
Working Groups
Build Identifier: Version: 3.6.0.v20100427-9KAjFKvFs-Uz-4QX1m0EdXVS Build id: I20100513-1500 On startup RAP only displays a white page although the full http source has arrived on the client browser. I have encountered this problem on two occations so far: The first time when I did secure the url of to the rap application behind sping security filter. In that case Spring takes me to the login form and after successfull authentication Spring takes me to the originally entered webaddress of my rap application. But instead the rap application I see the white page. The second time was when I installed a proxy servlet that handled all calls to <ipaddress>:80/rap/examples and gave back the contents it got from calling <ipaddress>:8081/rap/example . We wanted to do this because of the cross site scripting problem. In this case I get a white page too. As far as I understand RAP is sending an initial page to the client to find out if it is capable of displaying RAP and initiating the data communication with the RAP server. This seems only to work with the original request to display RAP. It seems not to work, if there is some processing between. Reproducible: Always Steps to Reproduce: 1. Go to http://dev.mixendo.com/wiki/Mixendo_XHR/ 2. Enter 'http://rap.eclipsesource.com/rapdemo/examples' in the URL text field 3. Uncheck 'enable XHR' 4. Press 'Recreate iframe' Result: an empty page is displayed in the tab 'render response' but the full code is in the tab 'raw response' Note: you can also reproduce this when redirecting with a proxy servlet.
The reason for the blank page is the invalid session cookie, which lead to always return initial RAP page (index.htm) from JSLibraryServiceHandler. Using URL rewrite instead of session cookie should do the trick. I think that this bug depends on bug 333292.
(In reply to comment #1) > The reason for the blank page is the invalid session cookie, which lead to > always return initial RAP page (index.htm) from JSLibraryServiceHandler. Using > URL rewrite instead of session cookie should do the trick. I think that this > bug depends on bug 333292. I guess this was supposed to mean bug 335545, which is also set as a dependency. Since bug 335545 has been closed, could you please try again if this issue is still reproducible with the latest nightly build?
Now JS libraries are registered as a static resources (bug 345120). I will close this bug as fixed. Please reopen if the issue persists.