Generic headers support for Messaging

Hi,

as per ACTION-170 and ISSUE-84, I'm making a proposal about the handling of generic headers for Messaging. The proposal is pretty much based on email, since I don't know enough about SMS and would happily live in a world in which email replaced MMS :) I will leave it to others' appreciation as to whether this can (or should) be adapted to the other interfaces.

XMLHttpRequest has three methods that apply to headers:

  - setRequestHeader()
  - getResponseHeader()
  - getAllResponseHeaders()

This isn't the most elegant interface so I don't recommend copying it. For instance, there is no way of iterating all headers other than by parsing getAllResponseHeaders() directly (it returns a single string of all the headers). There is also a dichotomy between request headers and response headers meaning that you can't read request headers and can't write response headers. This is workable for HTTP but I don't think that it translates well to email where an email object might see its headers read and written by a bunch of different pieces of code irrespective of whether it is received or sent mail.

Another aspect that's of interest is how headers set multiple times are handled. If you call setRequestHeader() several times with the same header it will append a header rather than overwrite the existing one. Appending can be done either by adding a new key-value header pair, or by concatenating a comma and the additional value to the already existing header. When retrieving a multi-valued header with getResponseHeader() you always get the comma-concatenated version.

This is at the same time correct and a cop-out. While it makes little sense to have two values for some headers (e.g. Content-Type) it's perfectly common for others (e.g. Received). The issue with reacting differently between cases in which it's sensible to append rather than overwrite and cases in which it isn't is that you need to know about all the headers in order to handle it interoperably. I think that we can live with the same behaviour, especially since it is mitigated by the fact that we can read and write at the same time.

Finally there is the list of forbidden headers that are dropped on the floor if you try to set them. It's long enough that I'll point instead: http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method. On reading, both Set-Cookie and Set-Cookie2 are eliminated. I forget the precise details of why each is verboten, but I will point out that all of those can naturally be faked if you're using your own HTTP client (or even just by typing them in, e.g. with telnet). The reason they are considered problematic is because were they allowed they could induce security issues for the user of the browser directly. As far as I can tell, this is not the case with the API that concerns us. I'd therefore suggest that we set no such limit (unless advised otherwise).

So I think that this points to two potential proposals. One perhaps more classical:

  DOMString[] headerKeys ();
  void setHeader (DOMString name, DOMString value);
  DOMString getHeader (DOMString name);

With multivalue headers concatenated as above. And one perhaps more interesting:

  readonly attribute Object headers;

This is essentially one big key-value object that you can manipulate natively. Multivalue headers are, quite simply, represented as arrays.

WDYT?

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Friday, 30 April 2010 13:33:03 UTC