André Warnier wrote:
William Clerico wrote:Exactly. The solution needs to understand the uniqueness between the 2 requests. Thanks!I am not quite sure how a portal works, but I will imagine how it could work, and maybe that would give you an idea, even if my imagination fails me.You call up the portal page, and it shows a link to your application.When you click on that link, what is really sent is a request to the portal, which contains a link to your site (including the extra query parameter). The portal then "proxies" that request to your server, gets the response and passes it to your browser. Unfortunately now, the response from your site, even though it went back through the portal, now contains links that do not have the extra query parameter. So now if you click on a link, even if the call goes again through the portal, the extra parameter isn't there and things start working less well.That was my imagination at work.The problem is that between one request and the next, there is nothing remembered at the server level. So your server has no idea that this second request it receives is in fact a second one, after a first that contained the extra parameter.Hmm. What about something like this :On your server, create 2 Virtual Hosts (and 2 distinct DNS names that both resolve to your host). Both hosts run the same application, but one will be the one for "direct" requests (not through the portal), and the other will be for the requests that go through the portal. In other works, the initial (and subsequent) direct links to your site will be to "http://originalsite.company.com";, and the initial (and subsequent) links from the portal will be to "http://portalsite.company.com";.Now in the VirtualHost dedicated to accesses from the portal, you just use mod_rewrite to add "?parameter" to all the incoming request URIs. If someone starts a session at the portal, all his subsequent links will point to "http://portalsite.company.com";, no ?Does that help ?On Sun, Oct 12, 2008 at 5:01 PM, André Warnier <aw@xxxxxxxxxx> wrote:William Clerico wrote:When my webapp is first invoked it may or may not have a QueryStringparameter included in the URL in order to provide some custom navigation capabilities. The existing links in my webapp were created prior to thisnew feature and I do not want to modify every link in the webapp to include thenew QS parameter. Is there a way to have the webserver save the info andappend it to the future requests? e.g. initial request: http://host.com/index.html?PORTAL_NAVthe existence of PORTAL_NAV in the QS tells the navigation components ofthe app that they need to be "portal sensitive" as opposed to "running standalone".the links embedded in the app do not include the PORTAL_NAV parameter, butI would like it to be implicitly included due to the initial request.I've fooled around with cookies to make this work but its less than ideal since the user could access the app with and without PORTAL_NAV from thesame browser. Just to make sure : are you saying that a user, with the same browser,could decide to acces your host either from within the portal, or else directly without going through the portal, and that in both cases the hostname would be the same ? ---------------------------------------------------------------------The official User-To-User support forum of the Apache HTTP Server Project.See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|