RE: Proposal to set arbitrary HTTP header fields

While I support the feature/properties work, it's unclear to me that it will
be long-term viable.  It might be, and I hope it is, but we just don't know
yet.  As well, while I do tend towards supporting abstractions that cover
all cases, often it just doesn't work out that way and the 80/20 solution is
better.

I think an 80/20 point would be to at least be able to use some of the HTTP
header fields, like username/password.  Your assertion about "better"
asserts the 100/100 solution, and I think the 80/20 should be also looked
at.  So my counter is that if setting header fields work is to be done,
including username/password should be part of that.  How can that be a thing
not to do if you are already doing header fields?  Why exclude some headers?
I would have expected pushback from the complexity of modelling HTTP
challenge MEP in WSDL, but not this part.

Dave

> -----Original Message-----
> From: Philippe Le Hegaret [mailto:plh@w3.org]
> Sent: Thursday, April 10, 2003 11:15 AM
> To: David Orchard
> Cc: 'Jean-Jacques Moreau'; www-ws-desc@w3.org
> Subject: RE: Proposal to set arbitrary HTTP header fields
>
>
> On Thu, 2003-04-10 at 13:36, David Orchard wrote:
> > 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.
>
> While there may a value in expressing message in header
> fields, I'm not
> sure if this example is good enough. We would be better off having an
> abstract feature to define a username/password mechanism that
> can reused
> across than bindings. The username/password should not be included in
> the message parts, but instead controlled using features/properties.
>
> Philippe
>
>
>

Received on Thursday, 10 April 2003 14:29:44 UTC