WSRP 2.0 issue: Need to foramlize receiving/responding client metadata on in-protocol getResource

[Michael Freedman <michael.freedman@oracle.com>]

Though the WSRP 1.0 specification is mute on the subject (I believe) the expected behavior of consumer based proxied http resources is that client request meta data is propogated to the resource via http request headers and client response meta data is propogated back via http response headers.  I.e. the consumer acts as an http proxy by and large passing thorugh the client request headers and returns in the client response headers those it received in the resource response.

In WSRP 2.0 we added in protocol resource serving.  As the structure of this call is based on the information passed in a regular GetMarkup passing client request and response meta data is more muddled.  The MimeRequest structure contains fields that correspond to the content type, character set and locale of the resource request.  Though unstated these are expected to come from the corresponding client request headers.  In addition the clientData field passed in MimeRequest contains the userAgent, request verb, and ccppHeaders.  Again the expectation is these come from the client request headers.  In MimeResponse there are corresponding fields to carry the content type and locale of the response, caching information and ccpp profile warnings.  Again the expectation is that the consumer ultimately encodes these properly into the client response headers.

In WSRP 2.0 we have said (encouraged) Ajax developers to use our in-protocol getResource to convey the ajax request.  We have been hearing from some Ajax developers (JSF AJax impelmentations) that they rely on encoding information about the partial rendering in the client request headers.  To work these implementations need to be assured that such headers are passed to the producer in a consistent, interoperable way.  Though at the moment these developers haven't indicated a reciprical reliance on the http response headers, its not hard to imagine systems utlizing this mechanism to convey reponse meta data back to itself so its client javascript can properly handle the response.

To support this WSRP 2.0 needs to have a formal definition of how client request meta data not already represented in specific fields in the ResourceParams , MimeRequest, or ClientData structures are passed and likewise how client response meta data not already represented in specific fields in ResourceResponse, ResourceContext, or MimeResponse are returned.

The solution is to define that both these extra request/response meta data is carried in a NamedStringArray.  With the semantic in an http client environment that there is one name/value per http header with the name being the header name and the value being the header value exlcuding those headers that are either overriden by the consumer or reflected directly in the passed request data.  Likewise there is one name/value pair for each additional piece of response meta data (other then what is already reflected in the response data) where the name becomes the http client response name and the value is value.

The primary question/issue is where to represent this NamedString array(s).  There are a variety of options for requests all of which rely on using a NamedStringArray:

• Define a standard extension to be carried in the extension field of the ClientData structure and require its use for getResource()
• Add an additional field in the ClientData called XXX (otherClientAttributes???) and require its use for getResource() (and other operations?)
  
• Define an additional field to ResourceParams called resourceAttributes???
  

Likewise there are a variety of options for responses all of which rely on using a NamedStringArray:

• Define a standard extension to be carried in the extension field of the MimeResponse structure and require its use for getResource()
• Add an additional field in the MimeResponse called XXXX (clientAttributes?) and require its use for getResource() (and other operations?)
• Define an additional field in ResourceResponse called resourceAttributes???
• Define a standard extension to be carried in the extensiuon field of the ResourceResponse.
  

-Mike-