Re: AD Feature: HTTP header conflicts

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. 


> 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 


> 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.

Umit Yalcinalp                                  
Consulting Member of Technical Staff
Phone: +1 650 607 6154                          

Received on Tuesday, 13 July 2004 14:01:11 UTC