- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 2 Apr 2009 21:56:06 -0700
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Ian Hickson <ian@hixie.ch>, Shane McCarron <shane@aptest.com>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Apr 2, 2009 at 7:13 PM, Adrien de Croy <adrien@qbik.com> wrote: > the issue of next-level content is not an issue for the HTTP (transport) > layer, it's an issue for the next layer up. It sounds like you recommend option (1) from my previous email. If it's not an HTTP issue, why does the HTTP spec forbid me from implementing a user agent that interoperates with the existing Web? > Now in a browser there is a next-level processor above HTTP. It's the thing > that actually gets the resource. It's free to do whatever it likes with > that content. Except that the HTTP spec forbids me from doing the very thing I need to do! > By all means develop framework and guidelines for how to process (e.g. > sniff) transported data, but it's a layer above HTTP issue. Referring to it > in HTTP would be like referring to TCP in the IP spec, and once you start > that, where do you stop? Following this train of thought to its logical conclusion, we ought to remove Content-Type fro the spec entirely. > For implementors, they need to be able to easily find what they need to do. > It's like there needs to be some higher-level resource which contains a > reference to all the things you should consider when creating an HTTP agent. > If there were such a resource, it would contain a reference to the > transport spec (HTTP) as well as other considerations, and could be expanded > to refer to issues such as sniffing or any other issue that confronted a > browser developer. Again, this appears to recommend option (1), in which a separate document specifies how to process the Content-Type header. Adam
Received on Friday, 3 April 2009 04:56:58 UTC