[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#115] Proposed Resolution: URL rewriting of GET formactions
How do we plan to implement "leak" scenario? Namely, suppose a Google portlet only includes the search box, and when the user hits the "Search" button the intent is to take the user outside the portal to a Google-only page, or even in a new window. Wouldn't the portlet in this case be allowed to use <form method=get>? If that is the case, an alternative statement would be along the lines of (needs wording) Entities MUST NOT include forms with method=get in conjunction with URL rewriting... -----Original Message----- From: Timothy N. Jones [mailto:tim@crossweave.com] Sent: Wednesday, October 30, 2002 9:52 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#115] Proposed Resolution: URL rewriting of GET form actions I believe Rich is right (see my earlier message about Producer having to parse the Consumer-supplied URL) -- GETs won't work in either rewriting scenario. Tim Quoting Rich Thompson <richt2@us.ibm.com>: > > > > > > In considering this tweak of the proposal, how can the Producer > generate an URL complying with the Consumer's template if portions of > it (the query > string) are buried in the value of a parameter of the URL the browser > dynamically builds from the form submission? I think it is not just for > Consumer URL rewriting that the prohibition applies .... > > > > Gil Tayar > <Gil.Tayar@webcol To: > wsrp-wsia@lists.oasis-open.org > lage.com> cc: > Subject: RE: > [wsrp-wsia] [I#115] Proposed Resolution: URL > 10/30/2002 02:51 rewriting of GET form > actions > AM > > > > > > Because this problem appears only in Consumer URL rewriting, I have a > small change to this resolution: > > "Entities MUST NOT include forms with method=GET when generating > HTML or XHTML markup when relying on Consumer URL rewriting" > > -----Original Message----- > From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] > Sent: Wed, October 30, 2002 09:41 > To: wsrp-wsia@lists.oasis-open.org > Subject: [wsrp-wsia] [I#115] Proposed Resolution: URL rewriting of GET > form actions > > > Resolution Date: 14-Nov-2002 > Proposed by: Rich Thompson > Proposed Resolution: > Entities MUST NOT include forms with method=GET when generating HTML > or XHTML markup. > > -----Original Message----- > From: Timothy N. Jones [mailto:tim@crossweave.com] > Sent: Wed, October 23, 2002 19:56 > To: wsrp-wsia@lists.oasis-open.org > Subject: RE: [wsrp-wsia] [I#115] URL rewriting of GET form actions > > > Sounds good to me -- this was the (b) option I originally proposed. I > am fine with disallowing GET forms, but we have to say so in the spec. > > Tim > > Quoting Rich Thompson <richt2@us.ibm.com>: > > > > > > > > > > > > > I would prefer that we add a conformance statement to the effect > "Entities > > MUST NOT include forms with method=GET when generating HTML or > > XHTML markup." > > > > > > > > Andre Kramer > > <andre.kramer@eu. To: "'Carsten Leue'" > > <CLEUE@de.ibm.com>, > > citrix.com> wsrp-wsia@lists.oasis-open.org > > cc: > > 10/23/2002 05:40 Subject: RE: [wsrp-wsia] > > [I#115] URL rewriting of GET form actions > > AM > > > > > > > > > > > > Stepping back for a second (or 6 days), does anyone actually wish to use > > HTML forms with GET actions? I don't, so should we even attempt to > support > > this (given browser problems and likely impact of asking Portlets to > > include > > a hidden field)? > > > > regards, > > Andre > > > > -----Original Message----- > > From: Carsten Leue [mailto:CLEUE@de.ibm.com] > > Sent: 17 October 2002 15:46 > > To: wsrp-wsia@lists.oasis-open.org > > Subject: RE: [wsrp-wsia] [I#115] URL rewriting of GET form actions > > > > > > Andre - I like that idea. Would you mind to write a more detailed > proposal? > > Is this something that would surface in the spec or that would just be a > > hint? > > > > > > Best regards > > Carsten Leue > > > > ------- > > Dr. Carsten Leue > > Dept.8288, IBM Laboratory Böblingen , Germany > > Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > > > > > > > > > Andre Kramer > > <andre.kramer@eu. > > citrix.com> > To > > wsrp-wsia@lists.oasis-open.org > > 10/17/2002 01:17 > cc > > PM > > > Subject > > RE: [wsrp-wsia] [I#115] URL > > rewriting of GET form actions > > > > > > > > > > > > > > > > > > > > > > How about using just one hidden field with the value set equal to the URL > > (the example form action)? Then we can run the same algorithm (no HTML > > parsing)? > > > > -- Andre > > > > -----Original Message----- > > From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] > > Sent: 17 October 2002 10:35 > > To: wsrp-wsia@lists.oasis-open.org > > Subject: RE: [wsrp-wsia] [I#115] URL rewriting of GET form actions > > > > > > Carsten, > > > > Although I do have an answer, let me note that Timothy Jones raised the > > issue. > > > > My answer is that this concerns the spec regarding Consumer-side URL > > rewriting, as the spec defines Consumer URL rewriting as a > > search-and-replace thing. Now if the wsia:rewrite occurs inside a <form > > method=GET action="wsia:rewrite..." then the Consumer (from what I > > understand, and I may be missing something) must understand the HTML and > > add > > the correct hidden fields to the form, meaning the Consumer MUST parse > the > > HTML to do this. > > > > Then again, I may be missing something, > > Gil > > > > -----Original Message----- > > From: Carsten Leue [mailto:CLEUE@de.ibm.com] > > Sent: Thu, October 17, 2002 10:53 > > To: Gil Tayar > > Cc: wsrp-wsia@lists.oasis-open.org > > Subject: Re: [wsrp-wsia] [I#115] URL rewriting of GET form actions > > > > > > Gil - as this problem is more or less a standard HTML problem I would > have > > assumed that the parameters would have to be encoded as hidden input > > fields, so the resulting request URL contains the correct parameters. Do > > you think that we have to detail this aspect in the spec? > > > > > > Best regards > > Carsten Leue > > > > ------- > > Dr. Carsten Leue > > Dept.8288, IBM Laboratory Böblingen , Germany > > Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > > > > > > > > > Gil Tayar > > <Gil.Tayar@webcol > > lage.com> > To > > wsrp-wsia@lists.oasis-open.org > > 10/17/2002 10:34 > cc > > AM > > > Subject > > [wsrp-wsia] [I#115] URL rewriting > > of GET form actions > > > > > > > > > > > > > > > > > > > > > > Status: Active > > Topic: markup > > Class: Technical > > Title: URL rewriting of GET form actions > > Raised by: Timothy Jones > > Date Added: 17-Oct-2002 > > Document Section: Core Spec v0.7 section 9.2 > > Description: > > Web browsers generally discard query string parameters included in the > > action > > URL of forms that use the "GET" method. In the example below the HTTP > > request > > to the server corresponding to the form submission will contain the > > "param2" > > > > parameter but not the "param1" parameter. > > > > <form method="get" action="http://...?param1=value1";> > > <input name="param2" value="value2" type="hidden"/> > > <input type="submit"/> > > </form> > > > > If the URL rewriting method described in 9.2 implies that "meta" > parameters > > > > will be added to an URL, then this method will not work on GET form > actions > > > > (e.g., consider "param1" in the example above as a meta parameter). > > > > Two solutions come to mind: (a) when rewriting a GET form action URL the > > meta > > parameters could be added as hidden inputs to the form, or (b) the spec > > could > > disallow GET forms in Producer generated markup. > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC