OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[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


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>
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC