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: Fun with Content Negotiation.
Date Mon, 20 Mar 1995 09:20:58 GMT
   Date: Mon, 20 Mar 1995 03:18:03 -0800
   From: "Roy T. Fielding" <fielding@avron.ics.uci.edu>

   Don't worry about it being kosher -- this is the only group to which
   I've mentioned the concept of "meta/http".  Personally, I prefer a
   hierarchical syntax like PRDM (or even a restricted subset of HTML).

Whatever.  There's nothing hard about supporting multiple map file
formats; my main concern with a text/html variant is keeping it easy
to parse (particularly since if it looks like HTML, then J. Random
User is likely to throw all sorts of random HTML stuff in there and
still expect it to work).

(I looked at PRDM, but it seemed to be a bit much to implement in a
weekend.  Perhaps I should look further...).

   > Oh yes, here are the contents of foo.map --- I was trying to break the
   > parser with this; if I were trying to impress anyone with the elegance
   > of the syntax, it would look a little different...
   > 
   >   URI: foo, vary="type,encoding"
	       ^
   should be a ;

Oh, well.  I got it right in the entries for the variants...

   Argh! That's exactly what you don't want to do.  Instead, the qs should
   be identical and both entries should include the Content-Length

My current code attempts to fish Content-Length out of the file
system; I suppose I should use the value in the map file if someone
bothered to type one in.  (NB, this is one of the things which I
haven't thoroughly pounded on yet).

   (after
   all, the only reason foo.gif.Z is better is because it has a smaller length).
   The negotiation algorithm should choose the highest quality image first,
   and then choose from the accepted encodings afterwords.  The encoding should
   only affect the "qs" when it affects the quality of the source.

OK... for next weekend's pass, I'll toss in a preference for smaller
content lengths among otherwise equal alternatives.

   Hmmmm, I think restricting comments to (comments) would be more readable.

I'm not sure it's entirely fair to judge the readability of the format
by an example which was deliberately constructed to be as ugly and
confusing as possible ;-).  (I was trying to break the parser; as I
said up at the top there, if I were trying to make it look elegant, it
would look quite a bit different).  In any case, I do think people
would expect "#comments" to work whether they do or not --- they do it
all the time in other file formats where no comment syntax is defined.

BTW, can "(comments)" appear on lines by themselves?

   ........Roy

rst

Mime
View raw message