httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Content-type negotiation: thoughts and code
Date Thu, 16 Mar 1995 11:45:06 GMT
   Date: Thu, 16 Mar 1995 07:13:30 -0800
   From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>

   I'd recommend not looking at the CERN code and just use the latest
   HTTP/1.0 as a reference. If you find parts that don't make sense in the
   spec, please take notes and forward them to me -- you will probably
   be the first to implement it right.

Well, perhaps we should go at this off the main list, but one thing
which seems to be missing is any notion of how to treat "level", as in
what is apparently Dan Connolly's semi-official suggestion for
discriminating levels of HTML conformance --- "Accept: text/html;
level=3.0".  My current draft code refuses to serve up a particular
variant if it's at a higher level of whatever content-type than the
client claims to accept (as if it exceeded MaxBytes).  This seems
intuitively the right thing.

Unfortunately, you need a KLUDGE to make this actually work as
intended (to serve HTML 2.0 variants to older browsers for
back-compatibility), which is to assume, for HTML only, that the
client meant "level=2.0" unless some other level was explicitly
specified.

Now, there's obviously no fully official sanction for this anyplace,
but some informal guidance would be helpful.

   There is no "Accept-content-encoding" -- only Accept-Encoding.

My mistake.  (Doesn't matter much to the currently released code ---
it ignores this anyway.  The next spin will do better).

   > handle qualities.  (It also doesn't yet return the correct HTTP error
   > codes in all cases --- in particular, it returns 404 Not Found, rather
   > than 406 None Acceptable, when content-type negotiation does find
   > alternate views, of which none are acceptable).

   Well, that's not useful -- that would be a bug.  Lack of 406 is the
   main reason content negotiation has failed in the past.

Is it really?  That strikes me as odd --- most browsers that I've seen
don't do much interesting with error codes anyway; they just throw
the message body they got up to the users, for whatever good it'll do
them.  Regardless, it pretty clearly is a bug.

   >[...]
   > A second interesting thing which comes up is what to do with clients
   > like certain, ahem, colorful browser betas which ship completely bogus
   > Accept: headers (or HTTP/0.9 browsers, which don't ship any).  My code
   > basically pretends the browser did "Accept: text/html" and "Accept:
   > text/plain" whether it actually did or not, to ease this difficulty;
   > is that the right thing?

   Nope, though that is what the old spec said.  The "official" default
   is "*/*" -- HTTP/0.9 clients cannot (and, in general, do not) assume
   that what they are getting is HTML.

Well, then, maybe we won't have to deal with
note_accepts_for_broken_browsers after all...

   That syntax is inherently limiting -- one dimension (media type) only.
   Since we know that more dimensions are on the way, the syntax should prepare
   for them.  The suggestions below are better.

It was a quick hack whose only virtue was that it didn't take a whole
lot of time to write (since the Accept: line parsing code could be
reused in toto).  

   That should be "qs" instead of "q", to match the description in the spec.

Well, it's easy enough to get it to accept "qs" in that
context... unfortunately, if I do it the quick and obvious way, people
who use "q" instead will get better than they deserve.

   Yeah, that's my problem as well.  What you have just reinvented is a
   proposed syntax for URCs (for more info on that, see
   <http://union.ncsa.uiuc.edu/HyperNews/get/www/URCs.html>).
   If you want to see what I consider to be the ideal syntax for a new
   media type for carrying URCs ("meta/prdm"), see 
   <http://www-diglib.stanford.edu/rmr/TR/TR.html#APPENDIXB>.

Neta, but probably too elaborate for Apache 1.0.

   A simpler syntax is what I call "meta/http", which is just a series of
   HTTP headers separated by blank lines:

      URI: foo; vary="type,language"

      URI: foo.jpeg
      Content-length: 3456
      Content-type: image/jpeg; qs=1.0
      Content-language: en

      URI: foo.gif
      Content-type: image/gif; qs=0.7
      Content-length: 123456
      Content-language: en

      ...

   The meta/http format is okay for access redirection, but the PRDM format
   will be much better for eventual handling of URI->URC->URL redirection
   and resource discovery systems.

Hmmm... I kinda prefer my own proposal (I like to avoid giving blank
lines semantic significance), but I could warm up to this.

rst

Mime
View raw message