Search the web
Sign In
New User? Sign Up
soapbuilders
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Want your group to be featured on the Yahoo! Groups website? Add a group photo to Flickr.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
XML Protocol: Proposals to address SOAPAction header   Message List  
Reply | Forward Message #3687 of 10820 |
The W3C XML Protocol Working Group is attempting to address perceived and
reported problems with the "SOAPAction" mechanism in the HTTP binding ( see
SOAP 1.1 Section 6.1.1 [1] ). As part of this process, the WG wishes to
solicit
comments and guidance on two proposals it has generated, as below.

Comments must go to xmlp-comments@... by 2001-06-18, and should address
the proposals as they sit, and may optionally make general comments on
resolution of issues with SOAPAction. Those representing the positions of
particular groups or organizations are requested to clearly identify
themselves as such. The WG encourages additional discussion on the
xml-dist-app@...
mailing list.

Neither of the following options precludes equivalent functionality
elsewhere.

Proposal A:
Use of SOAPAction is discouraged. SOAPAction is an optional part of XMLP,
supported but not required. Services MAY require SOAPAction and any
software wishing to access those services MUST be able to send it.

Proposal B:
Use of SOAPAction is deprecated. Senders SHOULD NOT send SOAPAction.
Receivers MUST NOT accept or reject messages on the basis of the presence,
absence, or value of the SOAPAction header.

Regards

Martin Gudgin
For the W3C XML Protocol Working Group

[1] http://www.w3.org/TR/SOAP/#_Toc478383528











Thu Jun 7, 2001 2:41 pm

marting@...
Send Email Send Email

Forward
Message #3687 of 10820 |
Expand Messages Author Sort by Date

The W3C XML Protocol Working Group is attempting to address perceived and reported problems with the "SOAPAction" mechanism in the HTTP binding ( see SOAP 1.1...
Martin Gudgin
marting@...
Send Email
Jun 7, 2001
8:34 pm

hi martin, i vote for (B). i doubt that anyone will ever use SOAPAction for filtering, as the original intent seemed to be, and i think there would be too much...
graham glass
graham-glass@...
Send Email
Jun 7, 2001
9:21 pm

Hi Martin, Thanks for the heads up. Here's my take: 1) Frontier relies on the presence of SOAPAction in order to determine that an incoming request is a SOAP...
Jake Savin
jake@...
Send Email
Jun 7, 2001
9:56 pm

is it possible to require that the content type is something like "soap" instead of "text/xml"? this would allow the SOAPAction header to be omitted. ... From:...
graham glass
graham-glass@...
Send Email
Jun 7, 2001
10:50 pm

I think Graham's suggestion of a standard content-type is excellent. It would solve the problem all-around. Also it would solve the ambiguity of the SOAPAction...
Bill Conroy
bconroy@...
Send Email
Jun 7, 2001
11:52 pm

Frontier does look at the value. It's used to marshal the method. -Jake...
Jake Savin
jake@...
Send Email
Jun 8, 2001
12:48 am

SOAPAction is pretty much useless. ( b ) Get rid of it is a sensible choice. Rosimildo. From: Martin Gudgin To: SOAPBuilders Sent: Thursday, June 07, 2001...
Rosimildo da Silva
rosimildo@...
Send Email
Jun 8, 2001
12:28 am

I would have to go with B, ditching it altogether. Proposal A seems like an interop nightmare. Sure it's optional and deprecated, you just can't interop with...
David Crowley
dcrowley@...
Send Email
Jun 8, 2001
12:46 am

<snip> At the same times, specific to the HTTP method, I like the idea of soap/xmlp having it's own content-type. Lots of strange things can happen, and just...
Bill Conroy
bconroy@...
Send Email
Jun 8, 2001
12:52 am

Hi, Bill! Though this idea looks appealing it may or may not work. SOAPAction shows intent regardless of provided content-type (which might be not only...
Paul Kulchenko
paulclinger@...
Send Email
Jun 8, 2001
2:23 am

Note that Martin's note stated that other means of identifying the "intent" are still open (ie. placing a 'target' attribute at the start of the soap-env is...
Doug Davis
dug@...
Send Email
Jun 8, 2001
6:52 pm

I see two problems with this: 1) It requires that the SOAP message be parsed, at least to some extent, before the destination of the message can be determined....
Jake Savin
jake@...
Send Email
Jun 8, 2001
7:04 pm

unless you change the specification to insist that the SOAPAction *always* contains information about the target, you can't achieve (1) using SOAPAction either...
graham glass
graham-glass@...
Send Email
Jun 8, 2001
8:54 pm

I posted this question a earlier, but it seems relevant to this particular thread, so I'm re-posting it: It seems to me that the interoperability problems...
George Arriola
george.arriola@...
Send Email
Jun 8, 2001
9:14 pm

First, Frontier *can't* publish WSDL. It's just not possible. There's no way for us to auto-generate WSDL, since Frontier's scripting language is loosely ...
Jake Savin
jake@...
Send Email
Jun 8, 2001
9:28 pm

I agree that #1 is an issue but I really don't see it being that big of one. Cracking the env just enough to get the first element isn't that big of a thing...
Doug Davis
dug@...
Send Email
Jun 8, 2001
11:38 pm

Hi, Doug! ... It might be more than just cracking the env. Message can be MIME encoded, transport-encoded (zipped or something else), encrypted, etc, and it's...
Paul Kulchenko
paulclinger@...
Send Email
Jun 9, 2001
1:53 am

... That's assuming that the first element in the header is the serialization root, and that's not a safe assumption. You could well have to wade through...
Rich Salz
rsalz@...
Send Email
Jun 9, 2001
1:52 am

In addition to the other postings supporting the preservation of SOAPAction I want to add that there is an existing investment in software and hardware for...
Yann Christensen
yannc@...
Send Email
Jun 9, 2001
2:06 am

when you say "the server can specify", do you mean "the WSDL can specify". remember that the WSDL will often be shared, and not associated with a particular...
graham glass
graham-glass@...
Send Email
Jun 9, 2001
2:09 am

Proposal, only half made in jest: For XMLP, constrain the value of SOAPAction to be the URL (relative or absolute) to the associated WSDL. Like DTD's for XML,...
Sam Ruby
rubys@...
Send Email
Jun 9, 2001
2:39 am

... That was my conclusion also.... Dick Brooks (ebXML liaison to W3C XMLP) http://www.8760.com/ ... From: Sam Ruby [mailto:rubys@...] Sent: Friday,...
Dick Brooks
dick@...
Send Email
Jun 9, 2001
2:32 pm

By first element I mean the very first SOAP Envelope element which is always the Envelope root (ie. the SOAP-ENV:Envelope element). -Dug Rich Salz...
Doug Davis
dug@...
Send Email
Jun 9, 2001
11:34 am

... ah, i read it as first element within the envelope. (and even then i got confused) looking to see if the first tag is soap's envelope element doesn't seem...
Rich Salz
rsalz@...
Send Email
Jun 9, 2001
11:45 am

Ignoring transports for a second, we'll have 2 SOAP processors talking to each other and what they send back and forth will be the SOAP envelope (simple xml)....
Doug Davis
dug@...
Send Email
Jun 9, 2001
1:07 pm

That links SOAP to WSDL which, as of now, isn't there. Even now services can require it to be anything they want, including the URL to the WSDL, but using it...
Doug Davis
dug@...
Send Email
Jun 9, 2001
3:14 pm

Hmmm.... You know, I'm coming into this thread late, and I haven't read all the messages associated with it, but there's one thing I don't understand: why is...
James Snell
jsnell@...
Send Email
Jun 9, 2001
4:42 pm

The last thing we need is YAOT (yet another optional thing), Every additional optional thing you add, makes interop that bit harder. Simon...
Simon Fell
soap@...
Send Email
Jun 9, 2001
4:55 pm

I think the choices re the SOAPAction header are: 1. Keep it. 2. Don't keep it. If it's #2, call the protocol something other than SOAP. Pretty simple. It goes...
Dave Winer
dave@...
Send Email
Jun 9, 2001
5:14 pm
First  | < Prev  |  Last 
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help