Serving documents as application/xhtml+xml without content negotiation
This week on Tuesday I read an article entitled Beware of XHTML. After this article I started to play with sending extreme content-types to browsers to see how they react. Of course my goal was what I wrote in the title of this article:
Sending documents as application/xhtml+xml without content negotiation, of course in a standard way. After several hours of trying and googling I found something ensuring about multiple line headers.
Quotation from rfc2616 (HTTP/1.1)
2.2 Basic Rules:
“HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.”
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html
Here are my test results:
| FF1.5 | O9 | IE6/7 beta | W3C Validator | |
|---|---|---|---|---|
| normal | XML | XML | want you to download | XML |
| with \r | HTML (why?) | XML | HTML | XML |
| with \n | XML | XML | HTML | refuse content-type |
So I found that sending content-type as above works like a charm! :)
header("Content-Type:\n application/xhtml+xml");
As the table shows it seems that the Internet Explorer doesn’t recognize multiple headers, although it’s fully standard compatible. Nevertheless in this case it’s good for us. (I tested under IE5.5 and IE5.0 too and interestingly these want to download it… Oh my God!)
The only flaw was what W3C Validator said: “Invalid content-type…” I thought that if \r is accepted there are no reasons to refuse \n. (It’s another story that Firefox thinks the opposite. Who understands this? This should also be reported…)
I reported it to W3C and three days later they accepted and fixed it in cvs! Great! :)
I can’t tell you know how can we use this “feature” in practice, can we use at all, but it seems to work…
Comments are welcome!
September 3rd, 2006 at 11:50 am
You misread the RFC. To quote:
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.
CRLF = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT )
A single \r or \n is not sufficient. The line terminate must be a \r\n.