From: Kragen Sitaker (email@example.com)
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?
> 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
. . .
> 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 - http://www.xmlspy.com -->
> <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;
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 <19991017171836.C16200@perlsupport.com>
on perl5-porters, around 1999-10-18.
So what am I missing here, folks?
-- <firstname.lastname@example.org> Kragen Sitaker <http://www.pobox.com/~kragen/> Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 12:12:59 PDT