- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Tue, 13 Jul 2004 10:47:13 -0700
- To: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Cc: Hugo Haas <hugo@w3.org>, www-ws-desc@w3.org
Roberto Chinnici wrote: > > Hugo, > > I don't like either solution much. > > As you correctly pointed out, forcing the names of all HTTP headers > injected via AD to carry a prefix goes against the original goal. > > At the same time, I think that allowing AD-specified (hence > application-specified) data to be silently ignored and overriden > by the HTTP stack will only result in puzzling bugs. > > There are two other alternatives, although I'm not quite ready > to decide between the two. The first one is to say that it is an > error if the HTTP stack finds itself having to override an > AD-specified header. This way we avoid sending a message that > contains data that does not reflect the application's wishes. +1 > > > The other alternative is to provide a header renaming facility > in the HTTP binding, thus allowing the author of the binding > portion of a WSDL document to override the (poor) choice made > by the author of the interface. Naturally, this renaming should > be invisible to the application, i.e. the value of the AD data > property will be the same with or without renaming. This still > leaves out the case of a client forced to use a WSDL that uses > HTTP header names that it can't handle, in which case we should > fall back onto the first alternative (reporting an error, that is). This seems more complicated. > > > Roberto --umit > > > > Hugo Haas wrote: > >> I raised on the call yesterday an issues about binding arbitrary >> elements to HTTP headers using the Application Data feature. >> >> The Application Data Feature defined in [1] specifies how the HTTP >> binding implements the feature, saying that the header name is >> serialized from the element information item local name. >> >> There may be a conflict when the local name is identical to a >> well-known HTTP header which may be set by the HTTP stack — e.g. >> Accept or Content-Length — or set by other ways in the HTTP binding — >> e.g. Content-Type —. >> >> I see two solutions to this problem. >> >> The first one is to prepend a known prefix, say "ADF-", which would >> give us our own namespace and we would be avoiding conflicts. The >> drawback is that we wouldn't be able to set arbitrary HTTP headers >> with the AD feature such as, which I think was what issue 158 was >> about. Also, since the SOAP binding binds each element to a SOAP >> Header, I think it's fair to mimic this behavior for the HTTP binding. >> >> So, on to my second solution, I think that it would make sense to say >> that, in case there is a conflict, the Application Data Feature loses. >> I would therefore propose the following, to be added after "Any >> attributes on data elements are ignored.": >> >> If an HTTP header corresponding to the element information item >> local name is set by a mechanism other than the Application Data >> Feature, such as the HTTP stack or another feature, then the this >> element information item MUST not be serialized. >> >> Comments? >> >> Regards, >> >> Hugo >> >> 1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0225.html > > > -- Umit Yalcinalp Consulting Member of Technical Staff ORACLE Phone: +1 650 607 6154 Email: umit.yalcinalp@oracle.com
Received on Tuesday, 13 July 2004 14:01:11 UTC