Re: AD Feature: HTTP header conflicts


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


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.

Received on Monday, 12 July 2004 15:00:24 UTC