|Summary:||make type-maps usable again, by making them accessible via the (virtual) resource name|
|Product:||Apache httpd-2||Reporter:||Christoph Anton Mitterer <calestyo>|
|Component:||mod_negotiation||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Christoph Anton Mitterer 2013-08-18 23:11:53 UTC
Hi. In it's current status, type-maps seem to work like the following: if I have a type map, named foo.var, then browsers MUST access it as foo.var to get anything done at all (i.e. negotiation). Accessing the resource as just "foo" (as all the documentation here https://httpd.apache.org/docs/current/content-negotiation.html and https://httpd.apache.org/docs/current/mod/mod_negotiation.html seem to imply it would work) seems to cause nothing but 404 errors... but when accessing "foo.var" the negotiation kicks in. This is highly ugly though (and I guess that's one of the tow major reasons, why type-maps aren't used much), since nobody wants to have all his resource URIs (and thus links) ending in ".var". So please make type-maps behave as MultiViews, i.e. if "foo" doesn't exist, but a foo.<something>, for which type-map is the handler, let it kick in. Further, it should be possible to have foo.var used by the server for negotiation, but not served, e.g. I'd like to be able to say something like <Files ?*.var> Deny from all </File> but still having negotiation work when I access foo (for which foo.var, and e.g. foo.svg, foo.png, foo.gif) exist. Cheers, Chris.
Comment 1 Eric Covener 2013-08-19 00:14:12 UTC
> In it's current status, type-maps seem to work like the following: > if I have a type map, named foo.var, then browsers MUST access it as foo.var > to get anything done at all (i.e. negotiation). 1) The browser can access /foo if other apache configuration maps the URI to the .var file (alias, rewrite, multiviews, ...) Changing this PR to an enhancement since this request is the bulk of the issue. This would not seem to be a backportable change in behavior. 2) The doc for type map negotiation under question: "A request for document.html in this directory will result in document.html.var being consulted, and the variant chosen which most closely matches the language preference specified in the user's Accept-Language request header." I think think this is referring to using multiviews to find the .var file, but this only happens by default on 1.3, or in later releases with MultiviewsMatch Any"
Comment 2 Eric Covener 2013-08-19 00:19:41 UTC
> I think think this is referring to using multiviews to find the .var file, > but this only happens by default on 1.3, or in later releases with > MultiviewsMatch Any" "handlers" is sufficient
Comment 3 Christoph Anton Mitterer 2013-08-19 00:30:46 UTC
Hi. Well first... let's keep this as an enhancement as you proposed... The ways you suggested me now, rather seems like workarounds,... since one will always want to get access via foo and not via some other path.... so it seems reasonable that mod_negotiate by itself does already everything necessary. - Alias is IMHO not really a solution if at all, only AliasMatch... as that's the whole point IMHO about the type-maps => not having the need to change the webserver config. - both rewrite and AliasMatch, seem to be rather error prone ways IMHO... - I do not quite understand how it should work with MultiViews... tried that, but it produced ambiguous results... and AFAIU. Perhaps the MultiViewsMatch thingy was missing for that. In prciniple MultiViewsMatch handlers comes close to a real solution of the problem, but: - AFAIU, it will accept all handlers,... which can lead to unexpected side effects - it will still include NegotiatedOnly, so "normal" MutliViews are still in place and again, could lead to side effects. Cheers, Chris.
Comment 4 Eric Covener 2013-08-19 00:33:25 UTC
trunk and 2.4 doc updated http://svn.apache.org/viewvc?view=revision&revision=r1515245 to require multiviews/multiviews match to go from document.html to document.html.var