[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