AD Feature: HTTP header conflicts

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
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/