Re: SOAP headers & HTTP extensions

This message is archived in www-archive@w3.org [1].

On Tue, Sep 11, 2001 at 10:47:50PM -0400, Mark Baker wrote:
> > Hmmm... I don't know how you found out about that. I guess Eric
> > advertized it somewhere. :-)
> 
> Yup.  He passed it along to Brian Behlendorf who passed it along to
> members@apache.org.

Hmm, hadn't meant to advertise it in using it to share context with
the apache folks. I don't mind, it's just funny how urls get around.

> > I wonder if we should polute xml-dist-app with something so "drafty"
> > (there might be a real word for that that I don't know).
> 
> Up to you.  It could use some polishing, but there is a coherent
> message there.

"Drafty", I like the word.

I can commit to respond to comments and update this document in a
moderate timeframe. I am a bit distracted recently, but should be able
to be attentive to this.

> > I was somewhat worried because we just got rid of HTTP extensions in
> > the SOAP spec.
> 
> If you're referring to SOAPAction, I wouldn't describe it as
> removing an HTTP extension.  I'd describe it as removing an
> HTTP header.  That doesn't mean that the meaning of that
> header can't be communicated with another extension, or to have
> an existing capability reused/extended.
> 
> For example, as Henrik and I discussed, the value of the
> SOAPAction header could be moved to a "namespace" attribute
> on a SOAP-specific media type.

I think the question is whether SOAP agents are expected to identify
the endpoint via some HTTP header so that firewalls can be allerted to
do application specific investigation.

> > Maybe commenting to www-archive (which isn't a real
> > forum, but is publicly archived) would make sense for now.
> 
> While you decide, I'll toss in my first impressions for you to
> mull over.

We appreciate that.

> >From what I see, this paper proposes two things;
> 
> 1.  That SOAP headers can be transformed to HTTP extensions
> 2.  That RPC invocations can be transferred over HTTP POST
> while remaining consistent with the principles of Web
> architecture
> 
> #1 I agree with completely.  I alluded to it in a discussion with
> you, Hugo.  I also talked with Henrik about it privately.  It's a
> good idea.  At some point I'll have a more detailed look at
> the detail of the mapping.

There aren't a lot of automatic mapping details yet. This is an area
that needs some work. In the mean time, individual applications may
implement their own mappings to HTTP Extensions.

> #2 I disagree with.  It's not as obvious or as extreme an
> architectural disconnect as with GET-over-POST, but it's still
> important.  Basically, with POST, behaviour is implicit, based
> on the interaction of the POSTed resource representation, with
> the resource being POSTed too.  With RPC, it's explicit, based
				       GET?
> on the method name and the resource only.

If you are referring to "Looking Past the MIME Header", I propose this
alternative to make it clear what people are implying when saying that
SOAP headers can be used to communicate the semantics which we
customarily get from the HTTP method.

> Forward or archive as you like.
tx, I sent this to www-archive in case someone wished to reference it.

[1] http://lists.w3.org/Archives/Public/www-archive/
[2] http://www.w3.org/2001/09/04-SOAP-vs-HTTPExt#MIME_header
-- 
-eric

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 12 September 2001 14:32:22 UTC