Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 36295 invoked from network); 12 Oct 2008 21:37:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Oct 2008 21:37:15 -0000 Received: (qmail 50237 invoked by uid 500); 12 Oct 2008 21:37:05 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 49783 invoked by uid 500); 12 Oct 2008 21:37:04 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 49772 invoked by uid 99); 12 Oct 2008 21:37:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Oct 2008 14:37:04 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HS_INDEX_PARAM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bclerico@gmail.com designates 209.85.128.188 as permitted sender) Received: from [209.85.128.188] (HELO fk-out-0910.google.com) (209.85.128.188) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Oct 2008 21:35:56 +0000 Received: by fk-out-0910.google.com with SMTP id 19so1362278fkr.8 for ; Sun, 12 Oct 2008 14:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=k5Lal/sej3Twga/n0+fb3dXd1WtMxKuQWinE57nZFsU=; b=gWaQAjeHX64YSuByKPXflPmy/uO5xzmfsO77Xlm2ICQYFajGTfB8aAqW1JGr7LBkgi CTM+aai9n8qiw1Vkfv9Fb2sEka5P6f7bs+PUBWu7RsZslAabSN/OVwwaMbgoiM9ezkxp W4npHsNjBoTNexGXgWgy95Pb//C0W0tOlGIJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=XSpnt0BdSwnuiwnwzRaMO5DFWzTjBRdz8wODyzsXVZDIPdvQFD3NCtBVCZvgDapWUm +zO7VBAuHz6bMejA7f3dvupyPcrrazLFkVY35cKvPmh2GT7Knv7R0OPIjmDW/GeOurk7 DWYhmDS1RjEqZSCiSHie+xK0Ihr/OuuvlQq8k= Received: by 10.181.58.9 with SMTP id l9mr3951826bkk.46.1223847390546; Sun, 12 Oct 2008 14:36:30 -0700 (PDT) Received: by 10.181.33.12 with HTTP; Sun, 12 Oct 2008 14:36:30 -0700 (PDT) Message-ID: Date: Sun, 12 Oct 2008 17:36:30 -0400 From: "William Clerico" To: users@httpd.apache.org In-Reply-To: <48F26C5D.4060905@ice-sa.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29250_7350098.1223847390505" References: <48F265C5.9050904@ice-sa.com> <48F26AEA.2090202@ice-sa.com> <48F26C5D.4060905@ice-sa.com> X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Saving and passing an initial QueryString parameter ------=_Part_29250_7350098.1223847390505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline That's correct. The portal is a framework that I can't get changed (at leas= t not very easily). On Sun, Oct 12, 2008 at 5:30 PM, Andr=E9 Warnier wrote: > The other solution would be to ask the portal to add the parameter to all > your links, but I guess it can't do that ? > > > Andr=E9 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 fail= s >> 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 contain= s >> 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 we= ll. >> 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 sec= ond >> request it receives is in fact a second one, after a first that containe= d >> the extra parameter. >> Hmm. >> >> What about something like this : >> >> On your server, create 2 Virtual Hosts (and 2 distinct DNS names that bo= th >> resolve to your host). Both hosts run the same application, but one wil= l be >> the one for "direct" requests (not through the portal), and the other wi= ll >> 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 u= se >> 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=E9 Warnier wrote: >>> >>> William Clerico wrote: >>>> >>>> When my webapp is first invoked it may or may not have a QueryString >>>>> parameter included in the URL in order to provide some custom >>>>> navigation >>>>> capabilities. The existing links in my webapp were created prior to >>>>> this >>>>> new >>>>> feature and I do not want to modify every link in the webapp to inclu= de >>>>> the >>>>> new QS parameter. Is there a way to have the webserver save the info >>>>> and >>>>> append it to the future requests? >>>>> >>>>> e.g. >>>>> >>>>> initial request: http://host.com/index.html?PORTAL_NAV >>>>> >>>>> the existence of PORTAL_NAV in the QS tells the navigation components >>>>> of >>>>> the >>>>> 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= , >>>>> but >>>>> I >>>>> 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 >>>>> the >>>>> same browser. >>>>> >>>>> Just to make sure : are you saying that a user, with the same browse= r, >>>>> >>>> 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 for more info. >>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>>> For additional commands, e-mail: users-help@httpd.apache.org >>>> >>>> >>>> >>> >>> >> >> --------------------------------------------------------------------- >> The official User-To-User support forum of the Apache HTTP Server Projec= t. >> See for more info. >> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >> " from the digest: users-digest-unsubscribe@httpd.apache.org >> For additional commands, e-mail: users-help@httpd.apache.org >> >> > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project= . > See for more info. > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org > " from the digest: users-digest-unsubscribe@httpd.apache.org > For additional commands, e-mail: users-help@httpd.apache.org > > --=20 Bill Clerico Lincroft NJ bclerico@gmail.com "Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did so. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." - Mark Twain ------=_Part_29250_7350098.1223847390505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
That's correct. The portal is a framework that I can&#= 39;t get changed (at least not very easily).

On Sun, Oct 12, 2008 at 5:30 PM, Andr=E9 Warnier <= ;aw@ice-sa.com> wrote:
The other solutio= n would be to ask the portal to add the parameter to all your links, but I = guess it can't do that ?


Andr=E9 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 wor= k, and maybe that would give you an idea, even if my imagination fails me.<= br> 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, get= s the response and passes it to your browser.  Unfortunately now, the = response from your site, even though it went back through the portal, now c= ontains 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 port= al, 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 reme= mbered at the server level. So your server has no idea that this second req= uest 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 w= ill be the one for "direct" requests (not through the portal), an= d 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 po= int to "ht= tp://portalsite.company.com", no ?

Does that help ?





On Sun, Oct 12, 2008 at 5:01 PM, Andr=E9 Warnier <aw@ice-sa.com> wrote:

William Clerico wrote:

When my webapp is first invoked it may or may not have a QueryString
parameter included in the URL in order to provide some custom navigation capabilities. The existing links in my webapp were created prior to this new
feature and I do not want to modify every link in the webapp to include
the
new QS parameter.  Is there a way to have the webserver save the info = and
append it to the future requests?

e.g.

initial request: http://host.com/index.html?PORTAL_NAV

the existence of PORTAL_NAV in the QS tells the navigation components of the
app that they need to be "portal sensitive" as opposed to "r= unning
standalone".

the links embedded in the app do not include the PORTAL_NAV parameter, but<= br> I
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 ide= al
since the user could access the app with and without PORTAL_NAV from the same 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.<= br> See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.apa= che.org
For additional commands, e-mail: users-help@httpd.apache.org






---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.<= br> See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.ap= ache.org
For additional commands, e-mail: users-help@httpd.apache.org



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.<= br> See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
 "   from the digest: users-digest-unsubscribe@httpd.ap= ache.org
For additional commands, e-mail: users-help@httpd.apache.org




--
Bill Cleric= o
Lincroft NJ
bclerico@gmail.co= m

"Twenty years from now you will be more disappointed by the th= ings that you didn't do than by the ones you did so. So throw off the bowli= nes. Sail away from the safe harbor. Catch the trade winds in your sails. E= xplore. Dream. Discover."  - Mark Twain
------=_Part_29250_7350098.1223847390505--