RE: Determining when an HTTP Post is a SOAP request.

Mark,

Your assumption regarding my use of "NAME/VALUE sequence" was correct.

My intention was to use the SOAPAction header to identify an incoming
request as a SOAP request prior to actually parsing the body.  This was
especially handy since the header was required as of SOAP 1.1 for all HTTP
clients.  Given that the future of the SOAPAction header is somewhat
questionable in 1.2, I hesitate to use it.  Is optional really enough for
this purpose?

I was also thinking that the Content-Type header would be appropriate.  The
current Content-Type for SOAP requests is text/xml which seems a little
ambiguous and doesn't seem sufficient enough to categorically deem the
incoming request a SOAP request.  Does it?

I also think that a firewall should be able to block incoming SOAP requests.

Brian

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, October 02, 2001 4:42 PM
To: Rickabaugh, Brian (GEA, 094855)
Cc: xml-dist-app@w3.org
Subject: Re: Determining when an HTTP Post is a SOAP request.


Brian,

> Hello All:
> 
> Suppose a component is going to receive an HTTP POST and needs to
determine
> if the stream of data that it is receiving is an incoming SOAP message.
If
> the incoming data is not a SOAP message, it needs to parse the incoming
data
> as a normal NAME/VALUE sequence.

I assume by "name/value sequence" that you mean an
application/x-www-form-urlencoded body.  POST can carry arbitrary types
of bodies, so it's probably not a good idea to assume that it's either SOAP
or that.  Check the Content-Type header.

> Does the SOAP spec. provide a mechanism for handling this determination?

SOAP 1.1 provides the SOAPAction header for this purpose.  SOAP 1.2 mucks
around with how SOAPAction is used[1], as it allows a receiver to notify the
sender that it will only accept messages that include the header.  But IMO,
this will end up meaning exactly the same thing as it does in 1.1, and
everybody will send it to avoid the additional roundtrip for negotiation.
i.e. a long winded way of maintaining the status quo (which is ok with me).

> Should it?

Absolutely.  Since SOAP can be used to create new & potentially insecure
protocols, a firewall administrator should be able to block it.

 [1] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/#N400838

MB (not a member of the WG, just a contributor from the cheap seats)