Subject: HTTP header/content precedence

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 17:14:34 -0700

I'm quoting a message, but modifying this to a new issue.

--On Friday, July 9, 2004 10:06 PM -0400 Mark Pilgrim <[email-masked]> wrote:
>
> Also note that the XML specification does specifically state that
> xml:lang (if present) overrides the external language identification.
> This is notable in that it is different in some cases from the
> precedence rules for character encoding (RFC 3023), of which we are
> all now painfully aware.

We have hit a few situations where Atom needs to resolve conflicts
between HTTP headers, content, and even the XML spec. It would be
nice to resolve all of these the same way, but that might not be
possible. Regardless, we should list them all in the spec. Here is
what I have so far.

Language: xml:lang overrides HTTP content-language

Media type and character encoding: use application/atom+xml so we
can let the XML spec rules handle it and bypass HTTP rules (override
within the rules)

Expires/refresh-rate: no decision, need to resolve HTTP caching
mechanism and historical rate-oriented RSS hints

Did I miss any? In general, it looks like content overrides
headers, which is opposite to the HTTP transmogrifying gateway
assumption. HTTP is designed for gateways which can transform
content on the fly and modify the headers to mark that decision.
These seem to be quite rare in practice, probably because they
mess with the end-to-end design principle which underlies much
of the internet design [1].

wunder

[1] <http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf>
--
Walter Underwood
Principal Architect, Verity

---

From: Martin Duerst <[email-masked]>
Date: Mon, 12 Jul 2004 13:49:19 +0900

At 17:14 04/07/11 -0700, Walter Underwood wrote:

>possible.

Yes, it would be nice. But the situation may be very different in
each case.

>Regardless, we should list them all in the spec. Here is
>what I have so far.
>

It's very clear that this has to work that way, because
any xml:lang on any child element can overwrite the
information on an ancestor element. If Content-Language
would then overwrite xml:lang, we would get a real mess.
The core reason for doing it that way is that language
doesn't have to be the same for the whole document.
Also, there are no simple transformations that change
language.

>can let the XML spec rules handle it and bypass HTTP rules (override

For charset, HTTP overwrites what's in the document because:
- There is only one charset per external entity
- Ideally, the charset is known before looking at the document,
   to be able to start parsing quickly.
- There are scripting solutions and there is transcoding,
   both don't look inside the document.
- It is relatively easy to change the charset of an external
   entity without.

Regards,    Martin.