Re: (ACCEPT*) Draft text for Accept headers

Maurizio Codogno:
>
>Koen wrote:
>
>% If you have comments on this text, now is the time to comment.  I
>% intend to close this issue at the end of the week.  This means that I
>% will send a last call for disagreement with perceived consensus,
>% together with a possibly improved version of the text below, in a few
>% days.
>
>%    If no Accept header is present, then it is assumed that the client
>% |  accepts all media types.  If Accept headers are present, and if the
>% |  resource cannot send a response which is acceptable according to
>% |  the Accept headers, then the server should send an error response
>% |  with the 413 (not acceptable) status code, though the sending of an
>% |  un-acceptable response is also allowed.
>
>I don't agree with this: let's suppose I want an audio file, but I can
>read only .wav and no .au . Should I get the whole .au file and then
>notice that it is unreadable for me?

No, of course not.  The server _should_ send an 413 response if it
only has data you cannot accept, but it is not _required_ to.  We
expect all major HTTP/1.1 servers to implement checking of Accept
headers, so that you won't get an .au you can't handle if you contact
an average web site.  We do not expect major servers to take the easy
way out and ignore the `should send an error response' above.

Note that most existing major HTTP/1.0 servers _do_ take the easy way
out, they do not check the Accept headers to see if you can handle the
data.  This lack of checking is of course also inspired by some
HTTP/1.0 user agents sending out incorrect Accept headers.

The text `though the sending of an un-acceptable response is also
allowed' above is meant for the authors of minimal, specialized
HTTP/1.1 server programs which are meant to only serve text/html or
similar types that are always acceptable.  We agreed in the content
negotiation subgroup that we would not want the spec to require such
authors to add Accept header checking code.

If such a minimal HTTP/1.1 server (or an existing HTTP/1.0 server) is
rude enough to send you an .au file you cannot handle, you should not
get the whole .au file and then notice it is unreadable.  Your
HTTP/1.1 user agent is encouraged to check the Content-Type header of
the response, and to abort the transfer if that header indicates that
the response is .au (audio/basic) data you can't handle.  This is
covered in the text about the 413 status code.

> It does not seem sensitive, especially
>since there is already a default to get any type (namely, no Accept line
>at all)

The default if an accept header is present is _not_ that you can send
any type, the default is that you should only send the types that are
accepted.  But minimal servers are not required to use this default if
an accept header is present.

>Is it possible at least to state things in such a way that in 1.2 the
>situation will change (I don't know, maybe adding an Accept-Only
>header if people believe that my view is stupid)?

The language in the 1.1 accept header text already allows for a
strengthening of the requirements in 1.2,  there is nothing in there
that would block it.

> After all, we have
>already a SHOULD, so it should not be that difficult to promote it to
>a MUST in the next version...

Yes, you are right.  If it turns out that almost all future HTTP/1.1
servers indeed check the Accept headers, as they should, it is
definitely possible that we can strengthen the `should check' to a
`must check' in HTTP/1.2.  But with even major HTTP/1.0 servers not
doing any checking, it is too soon to go for an `all servers must
check' in 1.1.

>.mau.

Koen.

Received on Friday, 5 April 1996 06:01:33 UTC