Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

[Rich Thompson <richt2@us.ibm.com>]

My primary question is whether it is
a common enough use case to require the Consumer to provide the field on
every getMarkup message to every portlet. My first thought is that it does
not rise to that level and that it is easy enough for a portlet to provide
such proxying when it wants to. It also is not difficult for a platform
that wants to automatically make such info available to the portlets it
hosts to add and remove an indicator from the navState.

As an aside, should the Primer capture
the issues involved with trying to use a post with a render url? Things
such as submitted forms are likely to be lost as they don't translate into
anywhere on the getMarkup message.

Rich

Subbu Allamaraju <subbu@bea.com>

10/19/2004 01:28 PM

To	Rich Thompson/Watson/IBM@IBMUS
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

That is the work-around with WSRP1.0. Any reason against
adding such a 
field? It would make it easy for web developers.

Subbu

Rich Thompson wrote:
> 
> Do we really need this field? The portlet has to already know this
to 
> have coded the URL to use the right method. It can easily use that
> knowledge (possibly by passing it to itself in navState) if it is
> actually proxying the markup from somewhere else.
> 
> Rich
> 
> 
> *Rich Thompson/Watson/IBM@IBMUS*
> 
> 10/19/2004 09:00 AM
> 
>                  
> To
>                  wsrp@lists.oasis-open.org
> cc
>                  
> Subject
>                  [wsrp]
[CR308] - Add requestMethod field to MarkupParams
> 
> 
>                  
> 
> 
> 
> 
> 
> 
> Document: Spec
> Section: 6.1.9 MarkupParams Type
> Requested by: Subbu Allamaraju
> Old Text:
> New Text:
>   [O] string      requestMethod
> 
>   . requestMethod: This field indicates the type of the HTTP
request 
> used by the client to submit data to the Consumer. The Consumer MUST
> supply a valid HTTP method as specified in Section 5.1.1 of RFC 2616
as 
> a value for this field.
> 
> Reasoning: In most situations, portlets can be programmed to be agnostic
> to how the client submitted a request to the Consumer. However, there
> are situations where a portlet must be aware of the type of the request
> (such as GET, POST etc.) used by the client. For example, a portlet
may 
> be acting as a proxy to fetch resources over HTTP from remote server.
In 
> this case, the portlet must be aware of the request type so that it
can 
> faithfully proxy resources.
> 
> In the current protocol, portlets can dictate the method type used
for a 
> request within the markup (e.g., HTML forms, links, JavaScript etc).
But 
> portlets cannot infer the method used by the client without explicitly
> embedding it in its navigationalState for every URL created. The 
> proposed optional requestMethod field will address this need.
> 
> Errata? no