To: new-httpd@hyperreal.com
Subject: Re: conneg mods 
In-reply-to: Your message of "Tue, 13 Aug 1996 11:56:44 PDT."
             <Pine.SOL.3.93.960813111933.2771A-100000@acidik.organic.com>
Date: Tue, 13 Aug 1996 19:05:40 -0700
From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
Message-ID: <9608131905.aa03118@paris.ics.uci.edu>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> So how's this: we assume that if a user agent knows what it's doing, it
> will assign at least one of its accept entries a quality value. So we look
> at the Accept: header, and if none of the entries have a q-value, we are
> permitted to modify the wildcards. Otherwise, we leave it alone. Likewise,
> once transparent negotiation is implemented, we would leave it alone if a
> Negotiate: header (or whatever the final form will be) is present.
> 
> I think this is an acceptable solution. What do other people (esp. Roy)
> think?

Fine with me.

> 2. Let's take the Netscape example again, simplified:
> 
> Accept: image/gif, image/jpeg
> 
> Now, we have an image available, conveniently enough, in GIF and JPEG
> form. They're both the same quality value - they look the same to us, and
> as we can see from the Accept: header, Netscape doesn't care which one we
> send - they're both the same to it.
> 
> So how do we decide? Currently, we look at the order in the accept header.
> image/gif comes before image/jpeg, so we send the GIF. This seems
> pointless; if the browser really perferred GIF over JPEG, it would send:
> 
> Accept: image/gif, image/jpeg;q=0.8
> 
> or somesuch. So why do we pick the first one? It seems to me like it would
> make more sense to choose, if there are no other cirteria, the smaller
> file (save bandwidth). Apache does do this, but only if the files are of
> the same type. i.e. if you're negotiating between foo.jpg and foo.jpeg.
> How about moving that check up in precedence, so that if two files have
> the same q-value, the same qs-value, match the same languages, etc, the
> smaller file gets it?

Yep, that certainly was the intention prior to conneg removing the mxb
parameter of Accept.  It will work the way it was meant to work.

> 3. If a user agents sends:
> 
> Accept: image/gif, image/jpeg
> 
> and all we have are a TIFF and a PNG, Apache sends 404 Not Found. This is
> obviously wrong, because the file was found. The proper response code is
> 406 Not Acceptable. It should be trivial to change this, but there is one
> issue:
> 
> However, the spec says "he response SHOULD include an entity containing a
> list of available entity characteristics and location(s)  from which the
> user or user agent can choose the one most appropriate." Spyglass' server
> does this, for example.
> 
> This makes sense. If it's a human-readable request, they might like to be
> able to select the PNG version, and save it to disk.
> 
> However, due to the way Apache handles 'errors', there isn't a good way of
> doing this. So, in the meantime, is it acceptable to just send a 406
> *without* such a list? Just say "The request was located, but a variant
> could not be found which was appropriate for your user agent." or some
> such?

That is a reasonable start -- sending 406 without a list is conditionally
compliant, but sending 404 is not compliant.

> Or should I figure out a way to smuggle the data from mod_negotitation
> into send_error_response()? (becuase that's the only way to do it,
> really)

That should be the goal.  Personally, I would prefer a better error
interface anyway, since we should not be killing persistence simply
because the server doesn't know the size of the error message (and
thus isn't sending content-length).

> Just some random thoughts. The language-tag matching thing also needs
> fixing (en-US has to match en, not just en-US).

Yep.

......Roy