- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Tue, 29 Jan 2002 13:49:17 +0100
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- CC: "Williams Stuart" <skw@hplb.hpl.hp.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, "Christopher Ferris <chris.ferris" <chris.ferris@sun.com>, "marc.hadley" <marc.hadley@sun.com>, xml-dist-app <xml-dist-app@w3.org>, Jean-Jacques Moreau <moreau@crf.canon.fr>
Henrik, I don't think this is quite the kind of change Noah had in mind; it's certainly not how I've read his proposal. My reading of Noah's proposal is less passionate, and does not require any changes to HTTP's semantics (I believe). Here's the scenario for a one-way SOAP exqhange using the extra HTTP header proposed by Noah: 1. The SOAP sender decides to send a one-way message. 2. It crafts the corresponding envelope and selects a One-Way MEP. 3. The MEP crafts an HTTP request and adds the "SOAPMessagePattern: OneWay" HTTP header. 4. The receiving SOAP MEP receives the HTTP request, reads the value of the "SOAPMessagePattern" header, figures out it is a one-way message, and sends back an empty 200 HTTP response (to comply with HTTP's semantics). 5. The SOAP receiver processes the envelope. It DOES NOT return back a SOAP response. Jean-Jacques. Henrik Frystyk Nielsen wrote: > A problem with the proposed solution of introducing a new HTTP header > field is that the 202 Accepted status code which is the status code in > question is an HTTP response and responses are by definition determined > by the server and not by the client. > > There is no mechanism to change that in HTTP and introducing an HTTP > header field with this sort of semantics would be a significant change > to HTTP. I don't think we want to go down this route - it is a *very* > slippery slope. > > Henrik > > >> -----Original Message----- > >> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com] > >> Sent: 17 January 2002 18:55 > >> To: Christopher Ferris <chris.ferris > >> Cc: marc.hadley; skw; xml-dist-app > >> Subject: Re: One-way messaging in SOAP 1.2 > >> > >> > > > ><snip/> > >> Those are options. Why not do it this way: > >> > >> * In the binding framework, state that: "Binding > >specifications that > >> support more than one MEP MUST specify the means by which the > >> recipient of a message can determine the MEP being used. > > > >+1 > > > > > > > >> * In the HTTP binding state: "This binding specification > >provides the > >> following means for distinguishing use of the one way MEP > >> from requests > >> send using the Request/Response MEP: > >> - A SOAPMessagePattern: HTTP header is defined with the > >> values 'OneWay' or > >> 'RequestResponse' (perhaps these should be URI's for extensibility?) > > > >Yes... in fact we are naming our MEPs with URI's and this > >would be a good > >use for such URI names. I feel somewhat reticient about > >defining another > >HTTP header... but if thats what we have to do... its more > >extensible in the > >long run than using different HTTP method (say PUT... if > >that's viable for > >use with SOAP). > > > >> - The MEP MAY be implicit in the URI used to deliver the message > > > >Not keen on this one as it overloads (conflates?) > >identification the next > >recipient with of an immediate destination (of a hop) with > >denotation of the > >MEP in use. > > > >> - In situations where more than one MEP is used in conjunction with a > >> single destination address, the SOAPMessagePattern HTTP > >header MUST be > >used > >> to identify the MEP. > >> We could instead go with your suggestion that HTTP depend on > >a header in > >> the envelope. I'm nervous that you don't really want to > >parse the XML > >> before making the determination. I'm also a bit nervous > >about more HTTP > >> headers, but on balance I think we need something outside the > >> envelope. > > > >If we're going to mark the difference (which I think we should > >if a binding > >supports multiple MEPs) then yes, I think it needs to be outside the > >envelope too. > > > >> In any case, I really do think the framework should make it the > >> responsibility of the binding to convey the MEP in use (explicitly or > >> implictly -- for example, if a binding only supports one MEP, > >> then there is no need to send anything with the message). > >What do you > >> think about this approach? > > > >+1 > > > >> > >> ------------------------------------------------------------------ > >> Noah Mendelsohn Voice: 1-617-693-4036 > >> IBM Corporation Fax: 1-617-693-8676 > >> One Rogers Street > >> Cambridge, MA 02142 > >> ------------------------------------------------------------------ > >> > > > >regards > > > > > >Stuart > > > >
Received on Tuesday, 29 January 2002 07:52:04 UTC