Bugzilla – Full Text Bug Listing
| Summary: | getServiceHandlerURL() missing entrypoint-path without cookie support (regression due to Bug#406428) | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Hannes Erven <hannes> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | gunnar, ivan, mknauer |
| Version: | 2.3 | ||
| Target Milestone: | 3.0 M2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | sr231 | ||
| Bug Depends on: | |||
| Bug Blocks: | 439099 | ||
|
Description
Hannes Erven
FWIW, we are also affected by this (bug 439099). Based on bug 439099 I believe there is an additional problem with the missing /context/ in the url. Our RAP application is mounted at /admin. But the browser tries to submit to http://localhost:3110/;jsessionid=...?servicehandler=...8&cid=... ... but you can convert the URL to absolute (as before) manually before set it: RWT.getRequest().getRequestURI() + ServiceManager.getServiceHandlerURL() Does it solve your problem? Ivan, thats probably a good (temporary) workaround. Generally speaking, when making the URL absolute is a requirement, why was the framework's behaviour (which was correct!) changed? getServiceHandlerURL() should, in all circumstances, return a valid URL that does not require additional processing before passing on to the client. (In reply to Hannes Erven from comment #3) > Ivan, thats probably a good (temporary) workaround. > > Generally speaking, when making the URL absolute is a requirement, why was > the framework's behaviour (which was correct!) changed? > > getServiceHandlerURL() should, in all circumstances, return a valid URL that > does not require additional processing before passing on to the client. There are usecases (URL rewrites - see 406428 description/comments), where absolute URLs are problematic. But I see that there are usecases (session rewrites, described in this bug), where relative URLs are problematic. We need to find a compromise (solution) for both. Yes, I understand that - although in environments with load balancers etc. one could also argue that the LB layer should (un)rewrite internal URLs. Could one possible solution be to add the ";jsessionid=..." not at the beginning, but at the end of the generated URL? (In reply to Hannes Erven from comment #5) > Yes, I understand that - although in environments with load balancers etc. > one could also argue that the LB layer should (un)rewrite internal URLs. > > Could one possible solution be to add the ";jsessionid=..." not at the > beginning, but at the end of the generated URL? To my knowledge, jsessionid is co called "path" parameter and should be in front. (In reply to Hannes Erven from comment #5) > Yes, I understand that - although in environments with load balancers etc. > one could also argue that the LB layer should (un)rewrite internal URLs. That's not consistent. If the environment setup is like a reverse proxy, then urls are updated/rewritten by the proxy. But if there are several components in between chances are high that a servlet container will never see the original url. It's therefore hard to build absolute urls working for a browser. The typical workaround is to make the public, nice url a configuration setting in the application. (In reply to Ivan Furnadjiev from comment #6) > To my knowledge, jsessionid is co called "path" parameter and should be in > front. The problem in my case (bug 439099) is that the relative url is misinterpreted. This could be a browser issue. But it's consistent on Mac in Chrome as well as Safari, which makes me believe that returning a relative url is incorrect in any case. If every, the uri prefix part should be configurable. (In reply to Ivan Furnadjiev from comment #2) > ... but you can convert the URL to absolute (as before) manually before set > it: > RWT.getRequest().getRequestURI() + ServiceManager.getServiceHandlerURL() > Does it solve your problem? It does, but only if I remove the jsessionid path parameter from both urls. Hi all... we decided to revert the change https://git.eclipse.org/r/#/c/22518/ for both 2.3 maintenance branch (2.3 SR1) and current 3.0 master branch. This will make the URL, returned by ServiceManager.getServiceHandlerURL() absolute again. Sorry for the inconvenience. We didn't decided - we're suggesting that and open the discussion! It seems that it's impossible to use relative URLs in a servlet application that requires URL-based session tracking. HttpServletResponse.encodeURL() does not work with relative URLs and there is no alternative method in the servlet API that would do so. If this holds true, I'd suggest that we 1) revert the change for bug 406428 in the 2.3.1 service release and in master, i.e. go back to absolute URLs 2) introduce a setting to configure the base URL to support environments that rewrite URLs in 3.0 Revert the change for bug 406428 in master with https://git.eclipse.org/r/#/c/33092/. |