[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#187] How does POST data reach the Producer
Gil - what I meant is that the portal server that dispatches a request to a
portlet needs to hide request information from the portlets this
information is not directed to. To do this the portal might need to access
the parameters, rendering the input stream inaccessible for the portlet
itself.
The example I tried to make was:
the portal server receives a post request that is dedicated to a single
portlet. In order to fulfill this request it needs to pass the request as
an action to the dedicated portlet but also render all other portlet on the
page to aggregate the full page. The portal might choose to implement each
portlet as a servlet, so it needs to invoke the request dispatcher to
render each portlet. As an input this required a servlet request object. It
makes sense to reuse the "global" request object for this purpose - with
the exception that the post parameters need to be hidden from the portlets
that are not target of the post request.
Does that make sense to you?
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
01/08/2003 10:53 cc
AM
Subject
RE: [wsrp-wsia] [I#187] How does
POST data reach the Producer
Carsten - could you elaborate, in WSRP terms why the Consumer "Without
special handling,
all portlets could do so". From what I understand from the spec, a Portlet
on the page can only access information the Portal chooses to send to it.
Gil
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Wed, January 08, 2003 10:38
To: Eilon Reshef
Cc: wsrp-wsia@lists.oasis-open.org; Stephan Hesmer
Subject: RE: [wsrp-wsia] [I#187] How does POST data reach the Producer
Eilon -
one reason why the portal might want to read the POST payload is the
following:
the post data is dedicated for exactly one portlet on a page. In J2EE every
servlet can access the post data via the servlet request. If a portal - in
a response to a post request - renders all other portlets on a page passing
the initial servlet request, it must ensure that only the destination
portlet can access the post data via the request. Without special handling,
all portlets could do so. One way to implement this is to namespace the
parameters, thus accessing the parameters before the control is passed to
the portlet.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
Eilon Reshef
<eilon.reshef@web
collage.com> To
Carsten Leue/Germany/IBM@IBMDE
01/08/2003 12:24 cc
AM wsrp-wsia@lists.oasis-open.org
Subject
RE: [wsrp-wsia] [I#187] How does
POST data reach the Producer
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:CLEUE@de.ibm.com]
Sent: Tuesday, January 07, 2003 11:30 AM
To: Eilon Reshef
Cc: wsrp-wsia@lists.oasis-open.org
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öblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
Eilon Reshef
<eilon.reshef@web
collage.com>
To
wsrp-wsia@lists.oasis-open.org
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:Gil.Tayar@webcollage.com]
Sent: Sunday, December 15, 2002 1:49 AM
To: wsrp-wsia@lists.oasis-open.org
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>
----------------------------------------------------------------
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