- From: David Orchard <dorchard@bea.com>
- Date: Thu, 10 Apr 2003 10:36:57 -0700
- To: "'Jean-Jacques Moreau'" <jean-jacques.moreau@crf.canon.fr>, "'Philippe Le Hegaret'" <plh@w3.org>
- Cc: <www-ws-desc@w3.org>
I really support this kind of work. Would it be possible to express message parts in header fields? Imagine a use case where travel agent web services is doing a query for flights, and the query requires an XQuery and HTTP is used (so HTTP POST is required). There would be a username/password, conversationID, and the xml content. Each of these parts can be bound to different places in the message stream. The username/password is bound to the HTTP mechanisms, the conversationID into the URI, and the XQuery into the SOAP body. Cheers, Dave > -----Original Message----- > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On > Behalf Of Jean-Jacques Moreau > Sent: Thursday, April 10, 2003 9:16 AM > To: Philippe Le Hegaret > Cc: www-ws-desc@w3.org > Subject: Proposal to set arbitrary HTTP header fields > > > > There was earlier a desire from some members of the WG to be able > to set arbitrary HTTP header fields. This proposal replaces my > earlier proposal at [1], which we had postponed until we work on > features had started. > > HTTP binding: > feature > http://www.example.org/2003/03/http/header-field > property > name: > http://www.example.org/2003/03/http/header-field/name-value-pair > type: xsd:array > > Jean-Jacques. > > [1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html > > > Philippe Le Hegaret wrote: > > issue: and what about the HTTP headers? > > > > How useful would it be? The accept, accept-ranges, content-type, > > authorization, cache-control, connection and content-length > are already > > fixed by other means (security, authorization features). > accept-language > > has nothing to do in the WSDL. Do we have an example of an > header that > > needs to be fixed and should not be represented in a more > abstract way? > >
Received on Thursday, 10 April 2003 13:36:58 UTC