RE: [wsrp-wsia] [I#179] requestParameter semantics unclear

[Andre Kramer <andre.kramer@eu.citrix.com>]

Indeed ASP.NET allows everything covered by our requestParameters (and more)
to be obtained from the Request object (System.Web.HttpRequest) as:

NameValueCollection Params

or, separately, as:

NameValueCollection QueryString - query string from URls (and method=get
forms)
NameValueCollection Form - post forms (application/x-www-form-urlencoded or
multipart/form-data)
[also Server variables, Cookies, Headers]

And also breaks POST request data up into:

NameValueCollection Form - form contents (application/x-www-form-urlencoded
or multipart/form-data)
HttpFileCollection Files - multipart form posts (form is
multipart/form-data). 
	Keyed by strings
	Items HttpPostedFile
		ContentLength
		ContentType - MIME content type
		FileName
		InputStream

And one input stream:

Stream InputStream - incoming http content body.


Now that we allow method GET for forms :-( 
we should change:

<element name="requestParameters" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>

to (allowing for both rather than a union for better future proofing):

<element name="queryParameters" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>
<element name="formParameters" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>


and we should support multiple upload contexts (as has been discussed by the
wsdl testers):

<complexType name="UploadContext">
  <sequence>
     <element name="mimeType"    type="xsd:string"/>
     <element name="uploadData"  type="xsd:base64Binary"/>
     <element name="mimeHeaders" type="types:NamedString" minOccurs="0"
maxOccurs="unbounded"/>
     <element name="extensions"  type="types:Extension"   minOccurs="0"
maxOccurs="unbounded"/>
     <attribute name="asInput" type="xsd:boolean" use="optional"
default="false"/>
  </sequence>
</complexType>
<element name="uploadContext" type="types:UploadContext" minOccurs="0"
maxOccurs="unbounded"/>

The mimeHeaders would not be available (or passed up from consumers) for
ASP.NET, but seem useful for MIME content completeness. Note, the (new)
'asInput' attribute.

I would disallow access to the InputStream for forms for security and
encapsulation reasons but allow one UploadContext for POST urls. The
consumer can set the 'asInput' attribute to true on one and only one of the
UploadContexts.

Also, ASP may differ from ASP.NET but we don't care.

I expect a Servlet based consumer would have to:
1) decide on using queryParameters or formParameters based on form method
type
2) parse the request input to populate formParameters and UploadContext[]

regards,
Andre

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 10 December 2002 19:31
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] [I#179] requestParameter semantics unclear







Current spec language:

  requestParameters: Name/value pairs reflected from the query string of
  the activated URL. These are the query string parameters the Consumer did
  not consume by processing them itself. Other name value pairs (e.g. HTTP
  headers from the client or additional Consumer-supplied data) should be
  placed in the extensions array.

This certainly covers the first 2 (action URLs and method=get both use
query strings). We may want to expand it to include the third as well.

Could not a .Net Producer just supply the same values for both APIs?

Rich Thompson


 

                      Gil Tayar

                      <Gil.Tayar@webcol        To:
wsrp-wsia@lists.oasis-open.org                                  
                      lage.com>                cc:

                                               Subject:  [wsrp-wsia] [I#179]
requestParameter semantics unclear          
                      12/10/2002 03:18

                      AM

 




Issue: 179
Status: Active
Topic: interface
Class: Minor_Editorial
Raised by: Eilon Reshef
Title: requestParameter semantics unclear
Date Added: 10-Dec-2002
Document Section:   v0.85/5.1.6
Description:
"requestParameters: I am not sure what the intent of this variable is.
it can mean three different things:
1. Data items passed as part of the action URL - this seems redundant as
the Producer can easily use navigationalState.
2. Data items passed as <form method=get> submit? Is this indeed the case?
3. Data items passed as <form method-post> submit? Is this indeed the case?
Note that (2) and (3) are accessed using the same API in J2EE but not in
ASP, so if the intent is also for (2) and (3) then we may need to
differentiate."



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>