Re: AD Feature: HTTP header conflicts

Hi Roberto.

* Roberto Chinnici <Roberto.Chinnici@Sun.COM> [2004-07-12 12:02-0700]
> 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).

One way to know whether a header has been renamed or not could be to
include an HTTP header giving information about what the AD feature
have done: one header could list the HTTP headers that were added by
the AD feature, and another one could list the headers that were
renamed. I believe that we would have all the information necessary at
this point, but this is starting to be a complex solution: we would
need to register 2 HTTP headers, plus potentially a namespace for the
renamed headers.

Where this issue is tricky is that I don't think one can know in
advance which AD element will cause a problem when serialized as a
header. For example, my HTTP stack may use a User-Agent: header while
yours doesn't; in this case, serializing a User-Agent element may work
for you but not for me.

I agree with you that raising an error in case of conflict is actually
much better than discarding the information if we don't want to create
obscure bugs.

I am leaning towards your first solution, which is simple and should
work in most cases while clearly pointing out problems.

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/