httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo>
Subject Re: Pending mod_negotiation patches
Date Mon, 25 Nov 2002 21:15:49 GMT
* 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...'s actually refreshing, English and C ;-)

die (eval q-qq[Just Another Perl Hacker
# André Malo, <> #

View raw message