At 09:56 AM 11/25/2002, William A. Rowe, Jr. wrote: >At 08:26 PM 11/19/2002, Andr� Malo wrote: > >>- 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.
Ok. I made a really bogus assumption here. If no Content-Type, how on earth did one get ;charset= into the mix? Answer, they didn't. So that wasn't a problem. >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. Well, as good as this sounds (for a future patch) nothing has changed. The negotation already requires that the .var type-map file has complete headers for mime variables; because if it doesn't, there is no recovering today. Now tommorow, it would be a good patch for all type-map files (body or not), but it didn't affect how cleanly your patch would work. >So I'm working from your patch to also populate the known request_rec >mime type entities when churning the type-map bodies file. And that should be a different patch; never mind me :-) >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. Still yet another good patch for the future. Thoughts anyone? In any case your patch is applied to 2.0 and 2.1, thanks! The only issues I had with your patch; * would you cvs diff from the top level httpd directory? Makes multiple patches much simpler to apply :-) * Were the cpy/dup's really necessary? We won't be dismissing the best->request's pool until we finish the entire request. Bill
