Re: Which usual media types can a server send

Owen Rees said in <>:

> In section 5.4.1 of draft-ietf-http-v10-spec-00, it says that "*/*" means all 
> media types but then goes on to imply that this excludes "unusual" media 
> types. It then goes on to suggest that the definition of unusual should be a 
> configurable aspect of the user agent.
> Since the server can have no way of knowing what the client/user agent has 
> been configured to consider "unusual", it is forced to treat "*/*" not as 
> "all" but as "don't know". The server must therefore use its own definition of
> "unusual" in determining whether or not a media type is acceptable. This seems
> to be undermining the whole purpose of the Accept header.

Yes, it is clear that I cut one too many corners in trying to finesse this.
The notion of "unusual" will have to go.

> Having "*/*" really mean "all", and this being the default, does create the 
> problem that a server can send an x-perimental/bizzare entity without a 
> content-length on the grounds that it is self-describing. If the server keeps 
> the connection open waiting for the next request, and the client does not 
> recognise that it has all of the entity then we have a deadlock.

Hmmmm, this is a second issue; it means we will also have to give up any
notion of having the end-of-entity indicated by media type. *sigh*

> I do not like having */* potentially mean different things to each individual 
> client and server. Here are some other options to consider:
> 1) */* does not mean all, it means some specified set of media types
> 2) */* is not the default; some specified set of media types is the default
> 3) */* is the default and really means all - live with the possible deadlock
> I am not particularly happy with any of these, but I think that the 
> uncertainty about the meaning of */* is worse.

The answer is (3), and we will remove the possibility of deadlock.

Mark Hedlund added in

> Some examples:
>     * It is neither configurable nor unusual for Netscape 1.1 to 
> accept tables -- every copy of 1.1 does, and if you don't like it, stick 
> to 1.0 or another browser.  Do tables constitute an 'unusual' media type 
> because not every server uses them?  If so, why is 'unusual' determined 
> on the browser's side?  Should Netscape 1.1 be sending 'Accept: */*; 
> q=0.5, text/x-html-with-tables'?  If so, should other browsers be forced to 
> save text/x-html-with-tables to a file?

That was the original intention, yes.

>     * It is not currently unusual for Lynx 2.3.8 to accept HTML 
> without tables or math.  A year from now (or five) when HTML 3.0 has been 
> released, should Lynx 2.3.8 start considering its requests for HTML, by 
> which it means HTML 2.0, 'unusual'?  If the user hasn't the sense to 
> upgrade, will the user nonetheless be expected to run Lynx in 
> 'anachronistic mode'?

No -- unusual would only apply to "new" or experimental types
(which causes a later problem, but hey -- one at a time ;-).

>     * I prefer HTML to PostScript, and let's pretend my browser knows that.
> When downloading the HTML/1.0 draft to print out, however, I prefer 
> PostScript to HTML.  Should I open my preferences, reset my quality 
> values, make the request, and then return my quality values to their 
> standard settings?

Yes, if what you want is to receive that content by default when requesting
a negotiated URL.  However, what most people will do is get the HTML
first (or some higher level document), and select from it a link to
the PostScript-specific version.  In other words, content negotiation
cannot obviate the need for content-specific pointers.

> Some suggestions:
>     * 'Unusual' should be defined more strictly.  One possibility 
> would be in reference to IANA registered media types.


>     * As new browsers implement wider acceptance of _usual_ media types 
> (i.e., HTML 3.0, image/jpeg, whatever), they should be encouraged to 
> explicitly list these media types in their accept headers.  This will 
> allow server maintainers to avoid "saving to file" whenever possible 
> (i.e., send gif unless they _say_ send jpeg).

No.  The only valid reason for preemptive content negotiation is the *hope*
that it will save additional network transfers and bandwidth by getting the
user what they want the first time.  If, as is often the case, every
client spits out 1k worth of Accept types on every request (even though
less than 1% of the Web is ever negotiable), preemptive content negotiation
has failed its purpose.

>     * The Content Negotiation section could remove its language about 
> choosing from several acceptable media types "possibly at random," and 
> instead suggest that when different versions of an entity exist, the 
> default should be the version most likely directly viewable by the oldest 
> browsers (text/html, text/plain, image/gif).

That is one alternative, but should be decided by the server.  After all,
HTTP may be used by non-WWW applications.

>     * The browser should be able to indicate that it will accept */*, 
> but if different versions exist, it specifically _wants_ a "300 Multiple 
> Choices" response (if you have more than one version, let me see what 
> you have).

Hmmmm, that would be nice -- maybe as part of the feature extensions 
thingy in HTTP/1.1 (not yet defined, but analogous to Dave Kristol's

>     * Similarly, browser authors should be encouraged to allow 
> changes to the Accept quality values on a per-request basis.
>     * A browser should be allowed to specify a preference for certain 
> "usual" media types without the user configuring it to do so!  The 
> language I quoted above doesn't seem to allow for that.

Well, it should.  I'll check that and be sure it does next time.


and Jim Seidman furthered in <>:

> I'd also like to quibble over the statement "If at least one Accept header
> is present, a quality factor of 0 is equivalent to not sending an Accept
> header field containing that media-type or set of media-types."  Does this
> mean that these lines are identical?
> Accept: application/octet-stream; q=0, application/* 
> Accept: application/*
> It seems like it would be more useful if q=0 could be used to explicitly
> disallow a certain type.  Comments?

I guess that is reasonable -- I'll try to work it into the algorithm.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA

Received on Thursday, 23 March 1995 18:11:17 UTC