W3C home > Mailing lists > Public > www-validator@w3.org > April 2001

Re: Handling of MIME types for markup?

From: Terje Bless <link@tss.no>
Date: Fri, 20 Apr 2001 11:11:12 +0200
To: Nick Kew <nick@webthing.com>
cc: Liam Quinn <liam@htmlhelp.com>, W3C Validator <www-validator@w3.org>
Message-ID: <20010420113037-b01010701-bdd1de30@>
On 19.04.01 at 20:50, Nick Kew <nick@webthing.com> wrote:

>IIRC, Accept: */* is James Clark's original.  I believe it is wrong

That depends on your POV. If it's intended to be an accurate representation
of the types of data SP can handle then, yes, it's obviously wrong.
However, SP is more of a library with example apps (nsgmls etc.) then an
actual application. In that light it's more appropriate to defer the
desision on what types to accept to the application layer. The simple
solution to that is to accept */*; the more convoluted one is to accept
MIME types as a parameter from the controlling application.

>If we use an Accept header, we need to give further thought to its value.

I agree. We should find someone that knows what's moving in the (SG|X)ML
world with regard to MIME types so we know what are considered the "right"
values. We'd almost certainly need to provide for a way to let
application/octet-stream through, but you could still block out quite a bit
of cruft.

>As a fallback, we should drop it altogether.  In terms of HTTP, this
>is clearly correct:
>  *  Accept: */* says "we accept absolutely everything" - which we most
>     certainly don't.  Accept: */* is appropriate to a browser with a
>     default action (eg save to disc or prompt user), but not to SP.
>  *  If we drop the Accept: altogether, we are saying instead that we 
>     don't support this (optional) aspect of HTTP.  In the absence of
>     a complete solution, this is indeed true.
>Can I suggest we just drop it?

What do servers do in the real world when you don't send Accept? Can we get
away with not sending it or will servers suddenly start returning errors?
Received on Friday, 20 April 2001 05:30:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:29 UTC