* William A. Rowe, Jr. wrote: > 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.
hehe, at first you confused me ;-) but right. (hmm, what happens with Content-type: ;charset=utf-8 ? 500? didn't try it. >>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. hmm, not sure, that I'm understanding you right. just trying to cripple it out ;-): a given file, say foo.html.var.en.gz, will be accociated by mod_mime with: text/html, type-map, en and gzip (type, handler, lang, coding) right? And that's what already happens, isn't it? in the file is some stuff like content-encoding: identity content-type: application/xhtml+xml where is the priority? What overrides what, resp. what *should* override what? IMHO the type-map content should be always used instead of general mod_mime associations. hmmm... I believe, I'm missing something. *confused again* >>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. I'd have to dig into rfc 2616 or somewhat, but isn't that what TCN is for? > Still yet another good patch for the future. Thoughts anyone? In any case > your patch is applied to 2.0 and 2.1, thanks! Thank you. > * would you cvs diff from the top level httpd directory? > Makes multiple patches much simpler to apply :-) ok, next time ;-) I had more stuff changed in repos and I didn't want to type all the long pathes and names into my dos box ;-) > * Were the cpy/dup's really necessary? We won't be dismissing > the best->request's pool until we finish the entire request. telling the truth... I don't know. I mainly followed the mod_mime copy, and was (and am) actually unsure about the scope of the neg(?) pool. I'm still in the learning phase... ...it's actually refreshing, English and C ;-) nd -- die (eval q-qq[Just Another Perl Hacker ] ;-) # Andr� Malo, <http://www.perlig.de/> #
