[
Lists Home |
Date Index |
Thread Index
]
Chiusano Joseph wrote:
Joe,
> The biggest question I have is: why are new HTTP headers being
proposed?
> I ask for several reasons:
>
> (1) It seems to me that it might be difficult (logistically,
> politically) to add new headers to the HTTP protocol, although I
may be
> very wrong on this.
Much easier than adding new methods.
Other than that I have some questions about the proposal:
What are the intended semantics where a resource denoted by
http://www.parts-depot.com/parts has a Meta-Location: of
http://www.parts-depot.com/parts and a Meta-About: of
http://www.parts-depot.com/parts?
One might want to declare more than one Meta-Location for a
resource. How would that be handled, or is there a good reason to
disallow a one to many relationship other than the fact that teeing
up Meta-About with Meta-Location works well as long there's only one
each?
How does one determine which Meta-Location is authorative? [I'm
assuming that it will be the one offered by the origin server of the
resource question, but it's not stated anywhere.]
What should an agent do when it only finds one header?
Are the values of the headers restricted to certain schemes, or are
they generic URIs?
> (2) From a technical standpoint, if new HTTP headers are added,
how will
> existing implementations of HTTP servers and clients be affected?
Will
> the new headers be "transparent" to them? Or, will there be adverse
> effects unless the implementations are updated to "recognize"
(even if
> they ignore) these new headers?
That's the advantage of using HTTP headers (a map of well known
keys); it's a data driven approach that makes them extensible in a
way that helps avoid breaking existing clients.
What I don't like about this proposal is the use of pairwise
headers - if thee headers are interdependent modelling them
otherwise strikes me as mildly brittle . I would suggest using a
single header instead along the lines of:
<metadesc> := "Resource-Description:" (<ws>)+ <metakeys>
<metakeys> := "about=" <uri> ("&location=" <uri>)+ ";"
<uri> := ...
<ws> := ..
The proposal should clarify that these headers cannot be used in
HTML markup as a trick to link to metadata about the HTML document
(a representation of the resource and not the resource itself).
That's the first mess I can see people getting into with this.
Btw, there's no support for design goal one in this proposal,
since there's no way specified to share reputations, just raw
descriptions. As it happens that's a good thing - mixing up
reputation management with locating metadata about resources doesn't
seem like a good idea. But I suggest dropping it as a goal nonetheless.
> (3) Adding new HTTP headers means that Web services that are
transported
> over other protocols (UDP, BEEP, TCP/IP, to name a few) will not
benefit
> from this approach.
Not neccessarily. What's important are the use of URIs to identify
all the resources involved, organised as key value pairs; that would
be reapplicable to other protocols.
> (4) I believe the Web services world (partly for the reason in #3
above)
> is moving away from relying on the underlying transport mechanism for
> specific functionality, and is instead specifying this
functionality in
> the Web services specifications themselves.
(Hoping to avoid a permathread) HTTP is not a transport protocol.
The proposal is an extension to the HTTP application semantics. Most
web services are running over the web; it seems reasonable to start
with the core protocol.
> For example, in WS-Routing
>
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp
> - part of the Microsoft Global XML Web Services Architecture
initiative,
> or GXA), the placement of destination addresses for a Web services
> message route is specified in the SOAP header, because HTTP cannot
> provide this level of routing capability. WS-Routing also makes
SOAP
> more protocol-independent by specifying placement of destination
> addresses in the message header to create a route for the message to
> take.
[Slightly OT, message routing is not the same problem as
distributing service descriptions. In any case, hard coding routing
steps is a bust from where I'm standing.]
Bill de hÓra
--
Technical Architect
Propylon
Transforming Business Integration
phone +35314927444; fax +35314927475
http://www.propylon.com
|
