Addition of submission/@headers

Hi everyone,

Continuing the idea of supporting other submission methods, there are a
number of submission use cases that require extra header information to be
present beyond that which is referred to in XForms, such as;

  * WebDAV and SOAP--which build on HTTP--require
    headers to indicate their presence;

  * WebDAV requires headers to indicate some of the
    parameters to its methods, such as COPY;

  * HTTP requires headers for security-related
    features;

  * some 'web services' such as Basecamp require
    additional headers.

And so on.

To allow XForms to interact with the increasing diversity of services on the
web I'd suggest we add an attribute to submission that indicates where to
get header information from. It would be an XPath expression, and would
encode headers in much the same way that 'get' currently encodes name/value
pairs for URLs. (I would think that the behaviour of the attribute would
also honour relevance and validity.)

The general architecture would then be that you end up with two sets of
nodes, one to define the body and the other (optional) to define a header.
Once these have been created (in section 11.1 step 1) then submission
proceeds as normal, except that in step 3 (detailed in section 11.2) we need
to also serialise the header information.

--- STARTS ---

  11.1 The xforms-submit Event

    ...

    1. One or two nodes from the instance data are selected,
       based on attributes on the submission element (one for
       the submission body, and an optional node for the
       header). The indicated node or nodes, and all nodes for
       which they are ancestors ... Etc.

  11.2 Submission Options

    ...

    * headers (XPath expression)

    ...

    The headers attribute is used to indicate instance data
    that will provide one or more headers to be serialized
    for submission. Exactly how the headers are serialized
    is protocol specific. There is no default value.

    The steps for serialization of headers is as follows:

      1. Each element node is visited in document order. Each
         element that has one text node child is selected for
         inclusion. Note that attribute information is not
         preserved.

      2. Element nodes selected for inclusion are encoded in
         a manner specific to the specific protocol. (See
         11.x below).

         Note that contextual path information is not preserved,
         nor are namespaces or namespace prefixes. As a result,
         different elements might serialize to the same name.

           * The encoding of EltName and value are as follows:
             space characters are replaced by +, and then
             non-ASCII and reserved characters (as defined by
             [RFC 2396] as amended by subsequent documents in
             the IETF track) are escaped by replacing the
             character with one or more octets of the UTF-8
             representation of the character, with each octet
             in turn replaced by %HH, where HH represents the
             uppercase hexadecimal notation for the octet value
             and % is a literal character. Line breaks are
             represented as "CR LF" pairs (i.e., %0D%0A). 

      3. All such encodings are concatenated, maintaining document
         order.

  11.x Encoding serialised headers for HTTP

    When serialising headers for use in an HTTP submission,
    element nodes are encoded as EltName: value, where :
    is a literal character, EltName represents the element
    local name, and value represents the contents of the
    text node. The separator character used between pairs
    of encoded name/value pairs is a newline character (\n),
    e.g. EltName1:value1\nEltName2:value2\nEltName3:value3.

    If the same element appears Duplicate headers will be created 

  Example:

  The following shows how to encode a WebDAV request that
  will COPY a collection, and is based on the example at [1]:

  <instance id="inst-copy-headers">
    <headers xmlns="">
      <Destination>
        http://www.foo.bar/othercontainer/
      </Destination>
      <Depth>infinity</Depth>
    </headers>
  </instance>

  <instance id="inst-data">
   <d:propertybehavior xmlns:d="DAV:">
     <d:keepalive>*</d:keepalive>
   </d:propertybehavior>
  </instance>

  <submission
   action="http://www.foo.bar/container/"
   method="copy"
   headers="instance('inst-copy-headers')
   ref="instance('inst-data')
   replace="instance"
  />

This would result in the following request:

  COPY /container/ HTTP/1.1
  Host: www.foo.bar
  Destination: http://www.foo.bar/othercontainer/
  Depth: infinity
  Content-Type: text/xml; charset="utf-8"
  Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <d:propertybehavior xmlns:d="DAV:">
    <d:keepalive>*</d:keepalive>
  </d:propertybehavior>

[1] http://www.webdav.org/specs/rfc2518.html#rfc.section.8.8.8

--- ENDS ---

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Sunday, 2 April 2006 12:59:45 UTC