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
