Hi, Thomas, I learned a lot from your latest answer. Thanks!
caniuse.com's approach is exactly what I want. Can you give more details on how the redirecting is done for the comment below? "So redirecting from /foo to #foo might be better (caniuse.com does just that: redirect /history to #feat=history) "? -maq On Mon, Sep 5, 2011 at 9:15 AM, Thomas Broyer <[email protected]> wrote: > > > On Monday, September 5, 2011 1:52:37 PM UTC+2, maq wrote: >> >> Thanks Y2i and Thomas. >> >> One of the reason is I wonder if I can redirect a full domain name to a >> internal state of my application. For example , I go to a domain hosting to >> redirect >> http://someotherdomain.com >> to >> >> http://mything.com/#**someotherdomain<http://mything.com/#someotherdomain> >> But the domain hosting service complains about the URL format, it has to >> be without the hash sign. >> >> http://mything.com/**someotherdomain<http://mything.com/someotherdomain> >> >> >> Thomas, is your proposal only applicable to new browsers? > > > See http://caniuse.com/history > > >> I wish a solution applies to old browser as well. >> > > In your entry-point, you could look at the current history token, and if > empty, then look at the path (treating /foo the same as #foo, i.e. a history > token of "foo"). I.e. do it manually, and only at "initialization" time. If > you then navigate into your app, then you'll have > http://example.com/foo#bar URLs, which can be confusing. > So redirecting from /foo to #foo might be better (caniuse.com does just > that: redirect /history to #feat=history). Then, if you want, you could use > replaceState in browsers that support it to redirect once more to /foo, > though on the client-side this time, without request to the server for this > history change. > > As for your redirect issue, request.getrequestDisplatcher() won't help > redirecting the client-side, it will "rewrite" the URL on the server-side, > but the client won't be aware of that: it requests a URL and is sent a > response back. With sendRedirect, a "meta refresh" (as you did), or a JS > location.replace() or location assignment, it requests a URL, and is told > (at different levels: HTTP, HTML, JS) to rather request another one. > You might want to try several alternatives in many browsers though, as > redirecting to a URL containing a "hash part" might not always work as > expected (search the GWT issue tracker, I seem to remember an issue with IE) > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/clDEoUhFlMcJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
