Mailing List Archive

problem with content negotiation ?
Not sure if this is a bug/feature or what, but here goes

I was trying the multiviews on

http://ooo.lanl.gov/skull

which I though was going to choose from

skull.gif and skull.jpg

but I also had skull.xgif there too (by accident).
Mosaic seemed to force the choice to be skull.xgif, and
tried to display the image as plaintext.
I suspect that the "wrong" content-type was being sent back.

"wrong" in that it wasn't what *I* expected it to be :-)

If this is the case (I'm guessing), then maybe if the multiview code
doesn't recognise the content type, it should give it a lower
preference value.

Apart from that minor hicup (which might not be), the content negotiation
stuff looks great. Good job Rob.


robh
Re: problem with content negotiation ? [ In reply to ]
From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 29 Mar 95 13:29:03 MST

Mosaic seemed to force the choice to be skull.xgif, and
tried to display the image as plaintext.
I suspect that the "wrong" content-type was being sent back.

"wrong" in that it wasn't what *I* expected it to be :-)

The reason it thinks foo.xgif is plaintext is probably because that's
the default type assigned by the code in http_mime.c when it doesn't
recognize the suffix. (This is actually configurable --- there's a
DefaultType directive in srm.conf --- but I suspect most people don't
bother with it).

If this is the case (I'm guessing), then maybe if the multiview code
doesn't recognise the content type, it should give it a lower
preference value.

If you mean "if it doesn't recognize the *suffix*", I'd tend to agree.
There's a bit of a wrinkle in the implementation --- MultiViews is
actually punting to the code in http_mime.c to figure out content type
and encoding from filenames, and that code doesn't leave anything
around to say whether it recognized the suffix or not --- but that can
be fixed. It's probably too late for this week, but I will submit a
patch with this effect for next week's vote (if E24 makes the cut this
time; if not, I guess I'll just fold it in).

(Incidentally, I got rid of a lot of problems I was having along these
lines with emacs backups by having MultiViews punt any file which is
IndexIgnored --- note the call to ignore_entry from http_mime.c.
However, Rob's suggestion here is a more comprehensive way of dealing
with this awkwardness).

Apart from that minor hicup (which might not be),

When people try to do stuff which seems reasonable to them, and it
doesn't work, I tend to consider it a problem ;-).

the content negotiation
stuff looks great. Good job Rob.

Thanks.

rst
Re: problem with content negotiation ? [ In reply to ]
On Wed, 29 Mar 95 16:51:30 EST, Robert S. Thau wrote:
>...
>(Incidentally, I got rid of a lot of problems I was having along these
>lines with emacs backups by having MultiViews punt any file which is
>IndexIgnored --- note the call to ignore_entry from http_mime.c.

I don't like you using any Index config variable for MultiViews.

In fact, for some time I have really disliked the design of httpd in this
area. The generation of an 'index' for a directory that does not contain
an index.html is something that should be completely separate from httpd.
Even if the code for it is actually included with httpd, it should logically
be separate. Specifically:

* Index options should not be read from the standard httpd .htaccess
files, but from separate per-directory .htindex files.
Almost the only use I ever make of .htaccess files is to add comments
to the index. If these comments were read from a .htindex file _only_
in the specified directory, then I could disable the use of .htaccess
files, and so stop httpd searching each directory of the path (for a
.htaccess file).

* It should be simple (and obvious) for httpd to call a CGI script to
generate an index. For example, I might want the index in a busy directory
to be cached. (Rather than having a cron job repeatedly making an index.html
file.)

* All the index options should be settable in the per-directory config files.
Currently you cannot set FancyIndexing on a per-directory basis.

I realise that rewriting this part of httpd would probably be counter-
productive right now. But I mention this now so that you all know where
I would like apache to be heading.

David.