thanks for the detailed answer > * let your server send an HTML page doing a JavaScript redirect to > the HTTPS URL, passing the hash along: I like that idea, but I couldn't find an easy way to teach my tomcat doing this so I do something similar: in the HTML page of my application I insert some java-script logic that will change the protocol and port of window.location if neccessary.
I think that's a quite elegant solution: * now it does not matter, if the user requests the page via http or https - she will always geht the same html page as response * the page itself will then alter the protocol and port (via java- script) if required On Jun 3, 3:02 pm, Thomas Broyer <[email protected]> wrote: > On 3 juin, 14:06, Martin Trummer <[email protected]> wrote: > > > we have some public (plain HTML) pages, that are not ssl encrypted > > these pages have (relative) links to a GWT application > > some of those links in the public area use history tokens, to open > > certain views of the GWT application: so you click the link, > > thenhttp://..../secure/GWTApp.html#sometokeniscalled > > the webserver notices that this resource is secured an sends a > > redirect to https > > then the browser requestshttps://..../secure/GWTApp.html#sometoken > > > that works fine in all browsers, except... > > you'll never guess it > > ...here it comes: > > Internet Explorer (tested in IE6 and IE7) > > Well, I don't find it that weird that it doesn't work (actually, I > find it a bit weird that it *does* work in the other browsers you > tested): the browser doesn't send the hash (history token) to the > server, so the server cannot redirect to the https URL *with the > hash*; and IE just follows what the server says. It seems other > browsers keep track of the hash and use it on the final (i.e. after > all redirections at the lower, HTTP, level have taken place) resource > (in case it's the very same resource that were at the original URL and > was jut moved around), while IE considers the hash part of the URL. > It'd be interesting to see how each browser react to a redirect whose > URL contains a hash, particularly when the originally asked URL had a > hash too: do they use the original hash or the new one provided by the > server? > > > the only workarounds I can think of: > > * use absolute URLs in the public pages: > > <a href="https://my.domain.com/.../secure/GWTApp.html#sometoken> > > I don't like that, because the domain is different for the > > development/test/productiontest servers > > Theory says you could use https:/.../secure/GWTApp.html#sometoken > (i.e. use protocol: and the absolute path and just throw the // > servername off); I don't know how it works in practice though. > > > * I could use a special URL parameters to wrap the historytoken > > <a href="./secure/GWTApp.html?historyToken=sometoken> > > and when the application starts I could implement some magic to > > update the history > > > maybe anyone knows a more elegant way to solve this? > > * let your server send an HTML page doing a JavaScript redirect to > the HTTPS URL, passing the hash along: > > window.location.protocol = "https"; > > or > > window.location = window.location.replace(/^http:/i, "https:"); > > Eventually, this could be done by your GWT app too in its > onModuleLoad, if it simplifies your server's configuration... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
