Re: RFC : XML representation of a HTTP request

[Eric van der Vlist <vdv@xxxxxxxxxxxx>]

Hi Robert,

Robert Hanson wrote:

> I'm not too sure I understand why you chose a structure like that. 

Just because it's the rough adaptation of what is provided by the
request class (and by other server interfaces, beginning with CGI...)
and that everyone is familiar with them.

>                                                                     My feeling
> is that the request method is no more a variable than the host name is... to
> me, both of these are header information.  And for the parameters, you seem to
> be assuming that they are variables of some sort.  What if the parameters are
> a single XML document sent in an HTTP POST like XML-RPC uses?  Although in the
> situation you are talking about, I don't see that this would be a problem.

No, it would be a way to pass the whole document to the stylesheet... I
just have to take care to parse them...
Thanks for the heads-up !
 
> Here is the way I would do it:
> 
>  <request>
>    <standard-headers>
>      <accept-charsets>
>         <accept-charset>iso-8859-1</accept-charset>
>         <accept-charset>UTF-8</accept-charset>
>     </accept-charsets>
>      <accept-language>en</accept-language>
>      <host>xmlbinder</host>
>      <request-method>GET</request-method>
>      <uri>/result-tree/example.xml</uri>
>      <script-name>/xmlbind/XSLServlet</script-name>
> 
>     <cookies>
>         <cookie>
>             <name>Apache</name>
>             <value>192.127.127.3.2835094787032722</value>
>         </cookie>
>     </cookies>
>      .../...
>    </standard-headers>
>    <other-headers>
>         <header>
>             <name>SOAPMethodName</name>
>             <value>Some-Namespace-URI#GetLastTradePrice</value>
>         <header>
>      .../...
>    </other-headers>
>    <parameters>
>      <parameter>
>         <name>x</name>
>         <value>2</value>
>      </parameter>
>      <parameter>
>         <name>y</name>
>         <value>3</value>
>      </parameter>
>    </parameters>
>  </request>
> 
> This would give you the standard HTTP headers in the standard-headers section,
> with the cookies broken down to name value pairs.  Under other-headers,
> non-standard HTTP headers can be put there.
> 
> Parameters can stay the same as long as you are sure that they will always be
> name-value pairs and not some other type of content... although I changed the
> way it is broken down.  The reason I did it that way is because first of all,
> I don't like using tag names to represent variables.  Secondly, I tend to stay
> away from using attributes unless there is a good reason for it, like an ID
> attribute, or using it to hide the data from a browser (like RDF does).
>
> I also broke down the accept-charset so that it separates the different
> sets... I find that I like to have the separate bits of information separated,
> which makes it a little harder to go from HTTP request to XML, but once in XML
> it is easier to identify small pieces of information without have to parse the
> character data in the XML as well.

You've put more intelligence in the binding than I had :=)
It can be both an advantage and a disadvantage (there is always a risk
of loosing information when you transform it...).

I think also we should keep standard and non-standard headers coherent.

The best solution is maybe to provide both the rough, original
information and its interpretation.

It could be then :

<request>
    <header>
      <name>accept-charset</name>
      <value>iso-8859-1,*,utf-8</value>
    </header>
    <header>
      <name>accept-language</name>
      <value>en</value>
    </header>
    <header>
      <name>host</name>
      <value>xmlbinder</value>
    </header>
    <header>
      <name>cookie</name>
      <value>Apache=192.127.127.3.2835094787032722</value>
    </header>
    <header>
      <name>SOAPMethodName</name>
      <value>Some-Namespace-URI#GetLastTradePrice</value>
    </header>
    <variable>
      <name>accept-charset</name>
      <value>iso-8859-1</value>
      <value>UTF-8</value>
    </variable>
    <variable>
      <name>request_method</name>
      <value>get</value>
    </variable>
    <variable>
      <name>request_method</name>
      <value>get</value>
    </variable>
    <variable>
      <name>uri</name>
      <value>/result-tree/example.xml</value>
    </variable>
    <cookie>
        <name>Apache</name>
        <value>192.127.127.3.2835094787032722</value>
     </cookie>
     .../...
     <parameter>
        <name>x</name>
        <value>2</value>
     </parameter>
     <parameter>
        <name>y</name>
        <value>3</value>
     </parameter>
</request>

A header would be the rough data from the network, a variable an
interpretation of this data (or extra information from the web server),
an cookies and parameters would be... cookies and parameters ;)

A variable could be multi-value (accept-charset for instance).

I wonder if there is a benefit in having an extra level in the tree,
grouping all the headers, variables, cookies and parameters in specific
<headers>, <cookies>, <parameters> and <variables> sections...

> I hope this is what you were looking for.

Yes, it helps a lot to exchange ideas.

Thanks

Eric

-- 
------------------------------------------------------------------------
Eric van der Vlist                                              Dyomedea

http://www.dyomedea.com                          http://www.ducotede.com
------------------------------------------------------------------------


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list