Title: Message
Why would the portal ever want to read the POST payload (beyond the basic
request) versus relaying it directly to the portlet?
(I can certainly see the reporting scenario that was raised earlier, but
to me that is an additional feature that should require additional
implementation such as relay + report on behalf of the portal, but shouldn't be
part of the "basic" scenario).
Eilon
-----Original Message-----
From: Carsten Leue
[mailto:]
Sent: Tuesday, January 07, 2003 11:30
AM
To: Eilon Reshef
Cc:
Subject: RE: [wsrp-wsia] [I#187] How
does POST data reach the Producer
I see the following problem if we direcly transfer (part of)
the body of
the HTTP request:
as the body of the HTTP request is part of the input stream, it cannot
be
accessed from every point in the processing cycle
of the request. Only the
first attempt to access this
part of the stream will be successful. In a
typical
portal scenario however it will typically be a portlet that issues
a WSRP call (proxy portlet). This portlet will be aggregated
into a page
and be not the instance that receives the
initial request. So it is
possible (and likely) that
part of the portal logic that processes the
request
accesses the input stream and thus renders it inaccessible for the
portlet.
If we mandate that the
portlet needs to send over the request body I see
the
following options:
1. limit portal implementations to
not access the HTTP input stream
(unlikely to
impossible)
2. make the portal implementation buffer
the input stream for later use in
the proxy portlet
(huge overhead)
3. make the portal implementation
parse the parameters and reconstruct the
body for WSRP
invocation (ugly)
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
Eilon
Reshef
<eilon.reshef@web
collage.com>
To
12/16/2002
01:27
cc
AM
Subject
RE: [wsrp-wsia] [I#187] How does
POST data reach the Producer
A concrete suggestion follows:
The rationale is that POST data should be opaque to the
Consumer. Hence, I
suggest that we do not require the
Consumer to parse the POST data in any
way. Instead,
the Consumer should pass an argument to the
performInteraction operation (and not to the getMarkup). The argument
may
be called payload. This argument will contain the
body of the HTTP request
that comes from the browser
as-is, excluding the HTTP headers - this should
take
care of all form POST scenarios, including document upload and general
parameters.
With this thread of thought, requestParameters are not needed
for form
POST. They may or may not be needed for form
GET (which is a separate
issue).
Eilon
-----Original Message-----
From: Gil Tayar [mailto:]
Sent: Sunday, December 15,
2002 1:49 AM
To:
Subject: [wsrp-wsia] [I#187] How does
POST data reach the Producer
Issue: 187
Status: Active
Topic: interface
Class: Technical
Raised by: Gil Tayar
Title: How does POST data reach the
Producer
Date Added:
15-Dec-2002
Document
Section: v0.85
Description:
This is not made clear. Two suggestions
I heard - uploadData and
requestParameters. Both have their
problems. Maybe something more
explicit?
Resolution:
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
