wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 19 Oct 2004 12:51:21 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]