httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: Pending mod_negotiation patches
Date Mon, 25 Nov 2002 15:56:34 GMT
At 08:26 PM 11/19/2002, André Malo wrote:
>Sorry, I don't want to harass someone, but there are two pending patches of 
>mod_negotiation.c. This is just a reminder, since the patches seem to 
>become overlooked and/or forgotten.

Not forgotten, but too low on the queue;  sorry :-(

>Short summary of the previous mails:
>
>- env.patch introduces a behaviour similar to mod_deflate and drops all 
>non-identity encoded ressources from the variant list according to the 
>current no-gzip or gzip-only-text/html settings. Useful for statically 
>compressed content.

I like the idea.  I'd like others to comment here too.

>- body.patch sets the appropriate MIME headers, if a type map body is 
>applied (Content-language, Content-type; charset, Content-Encoding)

Ok, digging into your patch, you were missing the charset declaration with
no explicit Content-Type.  Think foo.html.var where nobody bothers to fill
in Content-Type: text/html since it's terribly redundant.

This got me thinking, why aren't we picking up text/html in that case?  It's
actually sort of bogus, since that becomes part of the negotation, but our
read typemap logic isn't picking up the already-present variables.  Again,
take the case of foo.var.en where that file contains all english resources,
but perhaps multiple content-type representations.  All should be tagged
as english, but that never makes it into the var file negotiation since the
variable is sitting out in -our- request_rec but not the explicit .var headers.

So I'm working from your patch to also populate the known request_rec
mime type entities when churning the type-map bodies file.

The final issue I have with type-map bodies is that we have no way of
distinguishing them from one another, sans proper mime request headers.
I was thinking it would be very cool in Mozilla to create a 'doc choices'
sidebar based on the Vary: headers, and allow the user to explicitly
choose one :-)  But it would still be useful to use either path_info or the
query_args to explicitly state one variant, so that the MULTIPLE_CHOICES
response could give the user the ability to make a forced election.

But your patch isn't waiting on the 'final issue', only that first issue I raised.
When we can plug-in the charset (replacing some static default charset
if one exists) when the content-type is the default, then I'll be happy with
the end result of the patch.

Bill


Mime
View raw message