Bug #818
closedInternal paths are broken
0%
Description
Hi,
With a current git snapshot, when my application is at "/app.wt", all internal links in the html point to "/app.wtapp.wt/internalpath" instead of "/app.wt/internalpath". When clicking the urls in the browser it works, but when trying to open it in an other tab it fails because the url is wrong. With a version from last week it was "/app.wt/app.wt/internalpath" instead. So a slash got removed, but it's not better.
I think this is only broken when the html5 history api is used. At least I see this behavior with current chrome and firefox.
I can't reproduce this using lynx, but with the latest version it's now showing me: "Alert!: HREF in BASE tag is not an absolute URL.", but otherwise works correctly. I assume that's just because it doesn't have the hostname in it.
I've also created a symlink from app.wt to app. And when accessing it as "/app", the url I get is "/app.wtapp/internalpath". The base href also has "/app.wt" in it when accessed as "/app".
I've tried setting baseURL in the config file, but that doesn't seem to have any affect.
Kurt
Files
Updated by Koen Deforche almost 13 years ago
- Status changed from New to Feedback
Hey Kurt,
We have been changing the behaviour of the baseURL property but didn't update the documentation yet.
First of all, when using internal paths (and the HTML5 history API) due to a combination of unfortunate choices (in HTML) you need to set a base URL property.
Currently, the baseURL property however needs to point to the full URL of the 'folder' that contains the application. Thus, if your application is deployed at /app.wt, then the baseURL property should be 'http://mysite/'. We still need to relax this (by trimming the provided baseURL itself to the last '/') but we cannot get around the requirement to include the hostname (it is related to the warning given by lynx). We have been deploying this development version on www.webtoolkit.eu to see whether that works out well in a (rather complex) scenario with reverse proxies and widgetset mode (the homepage + chat widget).
Regards,
koen
Updated by Koen Deforche almost 13 years ago
- Status changed from Feedback to Resolved
Hey Kurt,
The latest git version should fix all issues that were introduced w.r.t. internal paths.
The use of the baseURL property is optional again.
Koen
Updated by Kurt Roeckx almost 13 years ago
Koen Deforche wrote:
Hey Kurt,
The latest git version should fix all issues that were introduced w.r.t. internal paths.
The use of the baseURL property is optional again.
It doesn't. Sometimes it has "/app/" in it, sometimes it has "/app/app" in it.
I'm also seeing some other weird results like not finding the menu when going directly to the right url of the menu.
I think generated paths are correct when the application starts at some place other than "/app", but wrong when it starts at it.
But those that start at "/app/menu" where "/menu" is the default internal path generated for the menu fail to show the menu contents.
Kurt
Updated by Kurt Roeckx almost 13 years ago
Kurt Roeckx wrote:
I'm also seeing some other weird results like not finding the menu when going directly to the right url of the menu.
[...]
But those that start at "/app/menu" where "/menu" is the default internal path generated for the menu fail to show the menu contents.
This part might be my error instead. It also breaks with 3.1.8.
Updated by Koen Deforche almost 13 years ago
Hey Kurt,
I can't reproduce this. Do you have a small example (or one of Wt's examples) with which I could debug this ?
Regards,
koen
Updated by Kurt Roeckx almost 13 years ago
Koen Deforche wrote:
Hey Kurt,
I can't reproduce this. Do you have a small example (or one of Wt's examples) with which I could debug this ?
I'm trying to create a minimal test case, but don't see the behavior I'm describing with it. So I guess I'll need to extend me test case until I can reproduce the behavior I'm talking about. But the minimal test case (test1.C), does also show unexpected behavior for me.
When going to "/test1.wt", pressing the link I end up at /test1.wt/test1.wt/foo. Pressing the ling again goes to "/test1.wt/foo".
Starting at "/test1.wt/", pressing the link I end up at "/test1.wt/foo".
It's at least very similar broken behavior, and I'd have to guess the same cause.
I will try to create an other test case showing the other problem.
Updated by Kurt Roeckx almost 13 years ago
Kurt Roeckx wrote:
I will try to create an other test case showing the other problem.
Here is the other test case.
If you start at "/test2.wt", then select "bar", you end at "/test2.wt/bar" (as expected). But the link for baz says: "/test2.wt/test2.wt/baz". The same goes for all the menu entries.
If you start at any other url, like "/test2.wt/", "/test2.wt/bar", "/test2.wt/foo", "/test2.wt/baz", "/test2.wt/xxx", things work as expected.
Kurt
Updated by Koen Deforche almost 13 years ago
- Status changed from Resolved to Closed