[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC