Re: Don Box: "That simply isn't what SOAP was meant to solve."

Date view Thread view Subject view Author view

From: Kragen Sitaker (
Date: Tue Aug 15 2000 - 12:10:20 PDT

Adam Rifkin quotes Don Box:
> The spec clearly states that SOAP requests MUST use the mime type
> "text/xml" so already you are deviating from 100% pure soap.

This is a requirement of the HTTP transport for SOAP, of course, not
all of SOAP. Unfortunately, this part of SOAP 1.1 is far from clear,
but I think it's apparent that the intent is that you must use this
media type in the HTTP request Content-Type header, not e.g.
base64-encoded as the last bytes of the request body, rot13-encoded and
backwards in an HTTP header called "Flentra", or embedded in the
request body formatted as a multipart part header.

By the way, where can I find the SMTP transport spec?

Adam writes:
> Does this mean we would be completely out of line developing a SOAP
> server that *does* expect form-encoded requests? I would think there
> would be a lot of utility for developers if they had access to such a
> programming platform. (Insert drooling-over-the-concept-of-a-SOAP-router
> rhetoric here...)

Not out of line; we just couldn't claim to be implementing standard
SOAP-over-HTTP. Instead it would be SOAP-over-forms. And that's what
the following is:

> POST /servlet/as2 HTTP/1.1
. . .
> Content-Type: multipart/form-data; boundary=---------------------------7d03201c3e0
. . .
> -----------------------------7d03201c3e0
> Content-Disposition: form-data; name="input-data"; filename="C:\ebxml\CommissionEvents.xml"
> Content-Type: text/xml
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- edited with XML Spy v2.5 - -->
> <HITISMessage xmlns="" Version="1.0">

Note that the content-type of the HTTP message is multipart/form-data,
not text/xml, although the content-type of one of the form components
is text/xml. Which is what Don Box points out:

> > Wow. I didn't know about the <input type='FILE' /> construct in HTML.
> > However, again, the request is not text/xml, but rather a form. I still
> > don't see how making SOAPMethodName optional would help in this case,
> > since a SOAP server must validate the content type as text/xml.
> Dick of course sets him straight:
> > No, it's not a form, it's just a MIME type that is capable of
> > transporting several type of payloads, XML being one type. The best
> > part of all, it's available today in all currently shipping browsers and
> > companies have written agents to perform the same for
> > Business-to-Business commerce!

It seems that Don is right and Dick is missing the point.

Of course, what Don is right about is merely standards compliance.
Adding a "multipart/form-data over HTTP" transport to SOAP seems like
an excellent idea. We just can't claim we're speaking the HTTP
transport for SOAP :) --- and we won't interoperate with people who do,
obviously, SOAPMethodName or no SOAPMethodName. (What is this about
SOAPMethodName, anyway? I thought it was called SOAPAction. And what
kind of illiterate spod would spell multi-word RFC-822 header names
without hyphens, anyway? At least they didn't misspell it.)

So, in a larger sense, Dick is even more right. He just doesn't
understand what Don is right about, and I think he needs to understand
that in order to proceed.

Kai Henningsen is also missing (a) point:

> My $DEITY. And all this butt-ugly stuff just for a *constant* (i.e.,
> file) XML payload?!

You can shove the payload into any form field and transmit it with
multipart/form-data, or x-www-form-urlencoded either. It doesn't have
to be a file.

Maybe I'm missing something important here; says:

  It's usually a big mistake to assume that a number of experts on a
    given subject disagree with you because they don't grasp the true

        -- Chip Salzenberg, in <>
           on perl5-porters, around 1999-10-18.

So what am I missing here, folks?

<>       Kragen Sitaker     <>
Perilous to all of us are the devices of an art deeper than we ourselves
                -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 12:12:59 PDT